I am Using webservice For Desktop application(coded in c#.net),I need to transfer 1,00,000 Records through webservice,but while debugging ,It throws an Exception i.e. The Underlying connection was closed.........I need to check the debugging Process int the application & the webservice,Can any one help me..............Thanks in Advance...........
You need to increase your timeouts in both client and server configs, also you may have to increase other values too depending on how big the chunks of data is.
These limits are in place to prevent DOS attacks out of the box.
Related
When I try to send an object with multiple images(converted to string using Base64) as STREAM type, from the onPayloadTransferUpdate() method, I can see "Failure" result and the devices(tested only when 2 devices are connected) automatically disconnect after that. Is Google Nearby connections not the right option to send large bytes?
Nearby Connections should be able to handle that. There's no explicit size limit on STREAM payloads.
I would suggest chunking the bytes (eg. send a couple KB at a time) and seeing if that helps. You can get into weird situations when you send entire files at once because it loads the bytes into memory twice (once inside your app, and once inside the Nearby process) which can cause out of memory errors. Binder, the interprocess communication layer on Android, also has a limited buffer to send data between processes.
You can also save it as a temporary file and send it as a FILE payload, in which case we will handle the chunking for you.
Disclaimer: I work on Nearby Connections.
1) You don't need to Base64-encode the data for the sake of Nearby Connections -- your STREAM can have raw binary data, and that'll work just fine.
2) How big is this data you're sending, and at what byte offset (you can see this in the PayloadTransferUpdate you get with Status.ERROR) does it fail at? It sounds like your devices are just getting disconnected.
3) What Strategy are you using?
4) If you still have discovery ongoing (i.e. you haven't called stopDiscovery()), try stopping that and then sending your Payload -- discovery is a heavyweight operation that can make it hard to reliably maintain connections between devices for long intervals.
I have developed an app that will upload a file to a server. Is there a limit on size uploading file using the cellular provider data. I think Wifi has no limit, but how about the cellular provider data, does OS limit the size of using data? If so, what is the size limit?
Your app will have no problem continuing to spray HTTP Post requests all over the internets as often as you tell it to, or whatever other exotic web magic you're invoking.
If you are referring to particular upload limits of individual cell phone data plans, then I think you'll have to read the fine print of every different contract with every different mobile provider to get an answer, and that answer will be "it varies"
Of course, if you are considering sending particularly large data-sets back to a server, you're probably going to consider breaking it into small pieces and handling dropped packets gracefully anyway, so I'm assuming you're not asking "what's the biggest file I can push through completely intact".
I have a JSON database connection for my app, and it is set to load (refresh) on the app's initial launch. The JSON data is stored on the phone, and retrievable if no internet connection is discovered on relaunching the app--so there's always data in there.
If the user has a slow connection to the internet--as in patchy <3G--the app will hang. I would like to set a timeout that reverts the database to the saved information (as it would if there were no connection at all). Unfortunately, I think that setting the timeout in the wrong function could make the app crash.
I've read there's no publicly available class to determine a connection speed, but can anyone suggest alternatives?
You could set a timeout for the NSURLRequest, if thats what you're using. In the callback that handles the timeout you could fall back to your local copy of the data. Check the following answer provided by another user.
NSURLConnection timeout?
If you wanted to determine the actual connection speed, you could have your app download a piece of arbitrary data of fixed length, and record the time it takes to complete. This has its own flaws though. You would have to decide when to do this, and how frequently. It may also suffer from the problem that you are trying to solve. And, for example, if the user was on a train, their connection may be great one moment, and poor the next. I think that the timeout solution would work ok, it just means that the user has to wait a period of time before the app falls back to the local copy of the data.
I'm setting up a server-client solution with ASP.NET MVC4 and a WCF-service, and was thinking you might have some input to a couple of questions.
The WCF-service get its data from a 3rd-party service which is quite slow. So my plan is the following scenario:
User logs in, setting off a jQuery-ajax-request to the MVC-controller
The Controller requests the WCF-service for data
The Service retrieves a small amount of data from the 3rd-party and before it returns it...
HERE IT COMES: the service spawns a background-thread to download a large amount of data from the 3rd-party
The service returns the small amount of data
The client gets the small amount of data and displays it, but also starts polling the service for the large amount of data
The large amount of data is downloaded to the WCF-service, and put into a cache-database
The Service returns the large amount of data to the client upon next polling-request.
My questions:
Am I not thinking straight about this?
What kind of background-threading mechanism should I use? The WCF-service is hosted in IIS.
Is polling from the client the right way to retrieve the next chunk of data?
Thanks for your time!
I am trying to use RabbitMQ for a distributed system that would work something like:
a producer puts in a queue a JSON-formatted list of order ids
several consumers pull out of that queue, do the business logic with that order ids and the result (JSON formatted) as well is put back into another queue
from the second queue, another consumer will take the data and pass it back to the caller
I am still very new to RabbitMQ and I am wondering if this model is the right approach, given the fact that the data should be back as fast as possible (sometimes in the matter of seconds, max 5) so there are real time requirements.
Also, how large can the message passed to a queue can be? The JSON that the producer will get back will be fairly large, based on what the consumer does.
Thanks for any ideas!
See page 47 in this presentation (InfoQ) for a great comparision between different messaging formats.
There's nothing wrong with the design you suggested.
The slight wrinkle is that enforcing "real time requirements" isn't straightforward. For instance, it's not currently possible to expire messages within a queue, so this would need to be handled by the clients when consuming messages.
The total size of messages in RabbitMQ <=1.8.1 was bounded by the amount of available RAM. As of 2.0.0, it's bounded by the amount of available disk space (i.e. rabbit will page messages to disk if it's running low on memory). Individual message sizes are recorded as 32-bit integers (IIRC), so individual messages cannot be larger than ~4GB; if this is a problem, consider saving the JSONs to network storage and passing some ID to them in the messages. Other than this, there aren't any constraints.