so I load large amounts of data from services. I just updated our project to the latest 4.7 FB with Flex 4.9 SDK and AIR 3.4. Implemented workers. They seem to work great for one-off tasks EXCEPT when it comes to internet data loading. I haven't found the magic limit yet, but it seems as though if you load an internet request (Loader, URLLoader, HttpService... whatever) that is receiving a large replay, the worker just locks up and quits. The main thread can do this just fine in all cases (but with UI being unresponsive until the load is done). This is why I was so excited about workers is to offload the sometimes large data loads to the background workers.
Has anyone else run into this? I saw comments on the Worker class docs online where a few other people have seen similar problems and suggest putting data loading from the internet back on the main thread. Seems like "what's the point of a worker then"?
Can they only do local calculations? Math is cool... but HTTP Gets are not?
I tried giving the worker app privileges.. no help there. Is there a magic worker.canloadlargefiles = true? (rhetorical).
Any direction or help here would be greatly appreciated.
Well not a solution, but a workaround. Instead of digging internals of VM, use KISS (Keep It Simple and Stupid) principle, divide your data into managable chunks. You do not need to divide the files or data but can tell the server do it by a request format so it sends you manageable portions of data that will not timeout the VM. Retrieve and join the chunks on the client side to form the big file back.
Thats my two cents.
Related
I have been looking everywhere for a solution to this problem.
At my work, we are trying to integrate Maximo with another system via the other systems REST API (which returns JSON responses). I am able to make this integration work on a small scale, however this API is taking upwards of 5 seconds to respond per request. Currently, I have defined this system as a JSON Resource, and I copy daily "snapshots" of the non-persistent data to a persistent attribute using an automation script. The requests all run in a sequence - which works slowly for 5 assets in testing, and will definitely not scale to 1000's of calls a day.
Assume that the API of the external system cannot be modified in any way... Is there a way to query this API in a non-blocking way? I'd imagine that if I could send a request, and send the next, etc. without needing to wait for a reply to proceed, this would solve the problem.
I looked into Invocation and Publishing Channels, and also Enterprise Services, and it seems like Enterprise Services along with JMS Queues might be what I need, however documentation says that these only support queuing incoming data... and I can't see how this solves my problem.
Any help? I am completely stuck on this.
Thank you!
I had to do something that sounds similar, once. I tried JSON Resources, but they didn't work for me. I ended up using the examples in Maximo 7.6 Scripting Features to do it. The first code sample in that document is a library script for making HTTP/S calls using out-of-the-Maximo-box libraries, and other examples in that document use IBM's JSONObject and JSONArray classes (also available out of the Maximo box) to parse responses.
To get things going concurrently / multithreaded, you could configure a cron task to call your automation script, and configure multiple instances on various schedules to call the same one and use the args or some other mechanism to prevent collisions.
Adding BackgroundTransferRequest's to the BackgroundTransferService once the app is in the background is successful, but the new requests don't actually run until the app comes back to the foreground. Not so great for my scenario of downloading lots of small files that may take a fair amount of time to complete.
I imagine Microsoft has probably implemented this behavior by design(?), but does anyone know a way around this or an alternative approach?
A bit of background to the problem:
I'm developing a Windows Phone 8 map app that allows sections of maps to be downloaded and cached for offline use. This process can lead to 1,000's of map tiles needing to be downloaded.
I've created a process that spawns the full limit of 25 BackgroundTransferRequest's, then adds more to the BackgroundTransferService as requests complete. This all works fine until the app actually goes in to the background.
I have considered doing some web server side processing to allow tiles to be bundled in to a zip and downloaded as a single request, but this is extra complication and will result in twice the space being required on the phone to complete the download and then extract the files before deleting the original package. But, ideally I'd like to find a way to force new BackgroundTransferRequest's to start running in the background.
It's not clear what your actual question is but I'd definitely recommend bundling them into a zip file and then downloading that. It's almost always easier to work with a single file than thousands.
If disk space is really a genuine issue (not just a theoretical one - I've put thousands of map tiles in under 20mb before, but it will depend on image complexity & quality) then you could make a few zip files. then you'd avoid the BTR issue and not take up as much disk space (even temporarily).
Suppose I've got the following parts in my system: Storage (S) and a number of Clients (C). The clients are separate Web Workers and I'm actually trying to emulate something like shared memory for them.
Right now I've got just one Client and it's communicating with the Storage pretty intensively. For the sake of testing it is spinning in a for-loop, requesting some information from the Storage and processing it (processing is really cheap).
It turns out that this is slow. I've checked the process list and noticed chrome --type=renderer eating lots of CPU, so I thought that it might be redrawing the page or doing some kind of DOM processing after each message, since the Storage is running in the page context. Ok, I've decided to try to move the Storage to a separate Worker so that the page is totally idle now and… ended up getting even worse performance—exactly twice slower (I've tried a Shared Worker and a Dedicated Worker with explicit MessageChannels with the same results).
So, here is my question: why sending a message from a Worker to another Worker is exactly twice slower than sending a message from a Worker to the page? Are they sending messages through the page? Is it “by design” or a bug? I was going to check the source code, but I'm afraid it's a bit too complex and, probably, someone is already familiar with this part of Chromium internals…
P.S. I'm testing in Chrome 27.0.1453.93 on Linux and Chrome 28.0.1500.20 on Windows.
I successfully created an application where i can record microphone sound using flash and then save that stream to a server called "Red5" .
But lately i came across a strange requirement of capturing the output volume from machine and then saving that stream to red5 server.Like if i listen to a song or a skype call or listening to any other sound.I just want to capture those sounds.
I searched for this sort of situation just to get an headstart but i havent found any solution so that i can proceed with it.
Can anyone here provide a start up solution for this.
Can this be done through flash?Or any other way ?
Any help will be appreciated.Please provide suggestions
Thanks
Certainly there are ways to get this done, however using Flash as is I don't see it being possible (most likely a security concern, don't want ads arbitrarily recording peoples conversations).
Programs like Audacity are capable of recording off of the StereoMix output of a computer which is essentially what you're asking about. You could potentially build an AIR app that includes an ANE that packages the functionality from Audacity, but would require quite a bit of porting and... well time.
As far as I know, at the current moment, late 2011 the max-connections-per-server limit remains 6. Please correct me if I am wrong. This is bad that we cannot fix this easily as in Firefox. As far as I know this value is hardcoded.
One of the solutions is to download the Chromium's sources and rebuild them. Is there a more easy solution?
Is there any tricky way to hack this without creating a dozen of mirror-domains?
Why I'm asking the question: My task is to create a html-javascript slideshow that will run inside a fullscreened browser, and a huge monitor is hanging on the wall. The javascript is really complicated, it preloads photos and makes a lot of ajax calls to my web services. If WIFI connection is slow, if 6 photos are loading, the AJAX calls fail, the application runs bad. I want a fast solution based, on http or browser or ubuntu tweak something else, because rebuilding the javascript app will take days.
Offtopic: do you know any other things that can be tweaked in my concrete situation?
IE is even worse with 2 connection per domain limit. But I wouldn't rely on fixing client browsers. Even if you have control over them, browsers like chrome will auto update and a future release might behave differently than you expect. I'd focus on solving the problem within your system design.
Your choices are to:
Load the images in sequence so that only 1 or 2 XHR calls are active at a time (use the success event from the previous image to check if there are more images to download and start the next request).
Use sub-domains like serverA.myphotoserver.com and serverB.myphotoserver.com. Each sub domain will have its own pool for connection limits. This means you could have 2 requests going to 5 different sub-domains if you wanted to. The downfall is that the photos will be cached according to these sub-domains. BTW, these don't need to be "mirror" domains, you can just make additional DNS pointers to the exact same website/server. This means you don't have the headache of administrating many servers, just one server with many DNS records.
I don't know that you can do it in Chrome outside of Windows -- some Googling shows that Chrome (and therefore possibly Chromium) might respond well to a certain registry hack.
However, if you're just looking for a simple solution without modifying your code base, have you considered Firefox? In the about:config you can search for "network.http.max" and there are a few values in there that are definitely worth looking at.
Also, for a device that will not be moving (i.e. it is mounted in a fixed location) you should consider not using Wi-Fi (even a Home-Plug would be a step up as far as latency / stability / dropped connections go).
BTW, HTTP 1/1 specification (RFC2616) suggests no more than 2 connections per server.
Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines are intended to improve HTTP response times and avoid congestion.
There doesn't appear to be an external way to hack the behaviour of the executables.
You could modify the Chrome(ium) executables as this information is obviously compiled in. That approach brings a lot of problems with support and automatic upgrades so you probably want to avoid doing that. You also need to understand how to make the changes to the binaries which is not something most people can pick up in a few days.
If you compile your own browser you are creating a support issue for yourself as you are stuck with a specific revision. If you want to get new features and bug fixes you will have to recompile. All of this involves tracking Chrome development for bugs and build breakages - not something that a web developer should have to do.
I'd follow #BenSwayne's advice for now, but it might be worth thinking about doing some of the work outside of the client (the web browser) and putting it in a background process running on the same or different machines. This process can handle many more connections and you are just responsible for getting the data back from it. Since it is local(ish) you'll get results back quickly even with minimal connections.