My android app keeps logging this warning :
IdleConnectionHandler removing a connection that never existed
What does that mean? Is that a big problem? What should I do to avoid this?
My app makes many http connections in AsyncTask, is that related?
EDIT:
I found that this call was the reason of this message :
httpclient.getConnectionManager().closeIdleConnections(30, TimeUnit.SECONDS);
So maybe it tries to close some connections that don't exist?
It sounds like there is a logic error in your code. You may be able to track down the problems using this Android tool called ARO. You can find out more about it here http://developer.att.com/developer/legalAgreementPage.jsp?passedItemId=9700312
It will help you to understand more about how your application is using the network and how you can improve that part of your application to make it more efficient.
Is there a reason you need to make many http connections at once?
I got that error too, but my app uses internet only for ad loading. Currently I have no permission that my app can use internet, so that is why it says "Removing a connection that never existed". That may be one of the reason for this warning.
Related
What is a correct approach to deal with Internet connection unavailability (that is common on mobile devices)?
Maybe it's a big question (or maybe not), however I didn't find any Codename One tutorial / article / video or API to deal with an unstable Internet connection (that is the normality on mobile) without errors or unexpected behaviors. I've found an app (Protonmail) that has a functionality that I would like to replicate in my apps. Please look at the following two screenshot: the first one is taken when the Internet connection is available, the second one when it's not available.
I noted that the ToastBar appears not only when Internet is explicitly disabled, but every time that the server is not reachable. When the "No connectivity detected" message is shown, the app pauses the Internet activity, so no errors are generated (and the messages written by the user are not lost). When the app server returns to be reachable, the ToastBar disappears automatically (without pressing the "RETRY" button).
What is a correct way to implement a similar functionality in Codename One, in a way that is as most as possible independent from the specific app? Is it possible to suspend the Internet activity of a Codename One app and then restore it?
I'm imagining something like this:
the app tries to do a simple request (like a ping) to a server every few seconds, implementing the performBackgroundFetch method;
if there is no response in a fixed time (i.e. three seconds), the Internet activity is suspended and the ToastBar is shown;
if there is response, the Internet activity is restored, the paused or failed downloads are restarted and the ToastBar disappears;
ideally all of this should works also with a BrowserComponent.
You can detect a networking error in the NetworkManager class by using:
NetworkManager.getInstance().addErrorListener(e -> {
// prevents the error from propagating into the ConnectionRequest class
e.consume();
ToastBar.showMessage("Connectivity error, retry?", FontImage.MATERIAL_ERROR,
ee -> ee.getConnectionRequest().retry());
});
As explained here: https://www.codenameone.com/manual/files-storage-networking.html
The toast bar code just prompts in a similar way and offers a retry on the connection request. Notice that this is the generic global approach.
This will not work for things like browser component which connects on its own without "us". In there you will need to handle errors in the JavaScript side.
I'm coding an app, and I will use retrofit lib to handle network access. My question is about how to handle network connection errors. My app may sometimes be used in zones with no internet access, but the user may be able to interact with the app. So my question is how to handle some kind of queue to repeat requests which are in failure as soon as network connection passes online ? Or is there some kind of library to handle this type of problem ?
Thanks in advance.
A library that may partially do the job for you would be https://github.com/path/android-priority-jobqueue
Check their docs (which are pretty good btw) to see if it helps. Altough it might not be the solution I think it would resolve 80% of your problem !
Hope it helps
My Android app uses the AWS Java SDK for uploading user photos to S3.
Whenever a user's phone's clock is 'skewed', this causes all transfers to fail. This is a well documented aspect of S3:
http://aws.amazon.com/articles/1109?_encoding=UTF8&jiveRedirect=1#04
It appears that the upstream S3 service reports this error quite clearly:
HTTP Status Code: 403 Forbidden
Error Code: RequestTimeToo-Skewed
Description: The difference between the request time and the server's
time is too large.
However when using the Java SDK, it seems as if the informative 403 code is lost ... and I have only an opaque "TransferState.Failed" to go by (which incidentally is the same error if internet connectivity is lost, if it times out, etc...).
As far as I can tell from the docs:
http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/index.html
http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/s3/transfer/TransferProgress.html
http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/s3/transfer/Transfer.TransferState.html
http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/s3/transfer/Upload.html
There is no way to get the additional "RequestTimeToo-Skewed" metadata about a transfer failure.
Am I missing it? Is there any way to get additional error information when an S3 transfer fails using Amazon's Java SDK?
UPDATE #1:
A commenter kindly highlighted that I should clarity two points:
I am actually using the AWS SDK for Android (which seems very similar to the Java SDK, but is nonetheless distinct)
I am using the TransferManager class to perform my upload. Apparently, this is a high-level class that wraps the lower-level AmazonS3Client ... and this lower-level class should expose the error reporting I need, but I am still investigating the exact tradeoffs involved between TransferManager and AmazonS3Client. As far as I can tell, there is no way to get progress information via the (synchronous) AmazonS3Client.putObjectRequest which would be a blocker for me...
UPDATE #2:
My sincere thanks to Jason (of the AWS SDK team) for stopping by and helping me out here. The important information is, indeed, available as properties on an AmazonS3Exception if you use certain methods. The docs had originally confused me and I thought that a manual Thread.sleep() loop was required to poll status (and thus I could not leverage waitForCompletion or waitForException), but if you use ProgressListener on PutObjectRequest you can get full progress callbacks and the error-fidelity of AmazonS3Exception.
these two methods should help you out:
Transfer.waitForCompletion()
Transfer.waitForException()
If you detect that your transfer has failed based on a transfer progress event, you can simply call Transfer.waitForException() to be returned the exception that occurred. That exception will be an AmazonServiceException in this case, with all of the info that you need to see that the real problem was a clock skew issue.
Alternatively, the Transfer.waitForCompletion() method will unwrap the original exception from an ExecutionException and directly throw the original exception, just as if it'd all been happening on one thread. This might be a more convenient approach if you want to use a catch blocks to catch different types of errors cleanly and elegantly.
I disagree that the "catch Exception" block is "brutally broad". The point of that code is to catch any error that happens, mark the transfer as failed and rethrow the error so that the application code can know about it. If it were less broad, then that's exactly the case where exceptions could sneak through and transfer progress wouldn't be updated correctly and would be out of sync with reality.
Give those two methods and shot and let us know if that helps!
Well, I have debugged Amazon's SDK and I'm sorry to say that this information is being swallowed internally. Perhaps I will try to submit a patch.
Details: an AmazonS3Exception is being thrown internally which does in fact accurately report this exact error scenario, but a brutally broad try catch ( Exception e ) consumes it and washes away the specificity.
Here is the guilty try-catch:
https://github.com/aws/aws-sdk-java/blob/master/src/main/java/com/amazonaws/services/s3/transfer/internal/UploadMonitor.java#L145
Here is a screenshot showing that an AmazonS3Exception is correctly thrown with the right info...
I have having problems with a WSDL/SOAP service call in an app I have built in flash builder for mobile. I have connected to the service using flash builders built in data/services functionality.
For the most part, the service call works perfectly but once in a while it will cause the app to crash - on my android device it completely locks up (spinning animation stops) and then Android informs me that the app is not responding and asks if I want to close it.
The crash appears to occur quite frequently but not with any pattern. One time it happened on my third attempt, another time it took approximately 30, a couple of times I could not get it to happen and most times it occurs somewhere in between.
It appears that the crash happens after a service call is made but before any response is received. Neither the success or the fault listeners are ever fired. I am very confident that I am sending exactly the same variables to the service every time.
I have used web service calls in other apps without trouble so I have to assume there is something in this particular build that is causing problems but I can't seem to find anything.
Any thoughts on possible causes, things to test or even a solution would be hugely appreciated.
Thank you,
Jamie
Your question lacks essential details, so now I can suggest you to setup Charles proxy and monitor you requests trough it.
If you send too many requests simultaneously, you shall not be confident in fault/result events as air runtime has limitations (in any case, it is a good practice to handle request timeout).
I've released my second game project on the Android Market this week, and immediately had multiple 1-star reports due to force closes. I tested it on many handsets and many emulators with zero issues. I'm completely at a loss for how to proceed and looking for advice.
I use Thread.setDefaultUncaughtExceptionHandler to intercept and report uncaught exceptions, then close gracefully. The people reporting force closes aren't getting to any of that, even though it is the first thing set in the application's main task constructor, and everything is wrapped in try/catches throughout. They are also reporting that there is no "Send Report" option in the force close popup (providing the Developer Console error reports), so I have absolutely no way of knowing what the problem is.
Uses Android 2.0, with android:minSdkVersion="5". Only Permission required is INTERNET.
(on Android market as 'Fortunes of War FREE' if you want to test)
I'm a bit surprised about the missing "Send report" button. What API level did you build the game with? I usually build the level with your minimum API level to make sure you're not using any API calls beyond that, but then switch back to the highest API level so you can use functionality like "install to SD".
I'm sure there's at least one user who wrote you a mail. Can you ask them to install LogCollector and mail you the log?
Btw, in general, I wouldn't use Thread.setDefaultUncaughtExceptionHandler so there IS the option to send a report. (It's ominously missing in your case, but normally, it should be there.)
Btw btw, the exception handler applies to the current thread. If you have an OpenGL app, maybe the crash happens in the GL thread?
I'm not sure if I understood you correctly, but as far as I know Android only shows that report dialog if you use its default UncaughtExceptionHandler.
Try this:
In your UncaughtExceptionHander's constructor, call Thread.getDefaultUncaughtExceptionHandler and save the returned object in a variable (let's call it defaultHandler). In your Handler's uncaughtException() do the things you want to do, and then call defaultHandler.uncaughtException() afterwards.
Maybe something you should know:
In my experience, your Context isn't functional anymore at uncaughtException(). So, you can't send broadcasts, etc anymore.
By the way, if you really wrapped everything in try/catch, that could be the reason why error reporting doesn't work as expected? :P
Good luck
Tom
Perhaps the force closes are caused by stalls, rather than exceptions. Users may not notice the difference. This kind of problem can occur more often if users have CPU hogging services running at the same time as your application, which explains why you're not seeing the issue in your testing.
Permission Internet sounds a lot like you try to transfer data from the net, which is very fast in your local LAN, but all of a sudden becomes slow (and time consuming) when people try this over their GSM connections.
If you then do the data transfer in the UI thread, this one is blocked and the system detects the block - but then this should end up in a "Did not respond" -- but then I've seen one user report an error with in the market on my app that was such a slow down cause.