Develop Reference

Okhttp 3.4.1 inconsistent with throwing IOException?

I'm seeing this really bizarre issue with okhttp. I am using okhttp to upload files to the server via post streaming. It's the same code as in okhttp recipes for post streaming:
while ((count = source.read(buffer)) != -1) {
sink.write(buffer, 0, count);
}
This works fine. The loop is inside writeTo method, which is part of the RequestBody - all like in the recipe. The body is wrapped into try/catch block and on IOException I fail my upload task and move on. This worked perfectly with okhttp 3.0.1.
I've now updated to okhttp 3.4.1 and I'm getting a really weird and inconsistent behavior. I'm testing with switching on the airplane mode mid upload and expecting to get IOException to fail the upload, but sometimes I'm getting it and sometimes not. I can't really figure out what this behavior is connected with. Just killing the app and repeating the test case will throw the expected exception once every 5 times or so.
Wondering if anyone else has seen similar behaviour and if there are any workaround apart from downgrading back to 3.0.1?
EDIT:
It looks like there are several exceptions that are all extending IOExceptions but not all of them make it out of the okhttp land.
These two are never reaching my try/catch block:
java.io.IOException: closed
at okhttp3.internal.framed.Http2$Writer.data(Http2.java:482)
at okhttp3.internal.framed.FramedConnection.writeData(FramedConnection.java:332)
at okhttp3.internal.framed.FramedStream$FramedDataSink.emitDataFrame(FramedStream.java:516)
at okhttp3.internal.framed.FramedStream$FramedDataSink.write(FramedStream.java:489)
at okio.RealBufferedSink.emitCompleteSegments(RealBufferedSink.java:176)
at okio.RealBufferedSink.write(RealBufferedSink.java:96)
at okio.RealBufferedSink.write(RealBufferedSink.java:96)
javax.net.ssl.SSLException: Write error: ssl=0x9bad4480: I/O error during system call, Connection timed out
at com.android.org.conscrypt.NativeCrypto.SSL_write(Native Method)
at com.android.org.conscrypt.OpenSSLSocketImpl$SSLOutputStream.write(OpenSSLSocketImpl.java:771)
at okio.Okio$1.write(Okio.java:78)
at okio.AsyncTimeout$1.write(AsyncTimeout.java:180)
at okio.RealBufferedSink.emitCompleteSegments(RealBufferedSink.java:171)
at okio.RealBufferedSink.write(RealBufferedSink.java:41)
at okhttp3.internal.framed.Http2$Writer.dataFrame(Http2.java:494)
at okhttp3.internal.framed.Http2$Writer.data(Http2.java:487)
at okhttp3.internal.framed.FramedConnection.writeData(FramedConnection.java:311)
at okhttp3.internal.framed.FramedStream$FramedDataSink.emitDataFrame(FramedStream.java:515)
at okhttp3.internal.framed.FramedStream$FramedDataSink.write(FramedStream.java:488)
at okio.RealBufferedSink.emitCompleteSegments(RealBufferedSink.java:171)
at okio.RealBufferedSink.write(RealBufferedSink.java:91)
However, this one seems to be getting all the way to my try/catch block:
okhttp3.internal.framed.StreamResetException: stream was reset: CANCEL
at okhttp3.internal.framed.FramedStream.checkOutNotClosed(FramedStream.java:574)
at okhttp3.internal.framed.FramedStream.access$1200(FramedStream.java:34)
at okhttp3.internal.framed.FramedStream$FramedDataSink.emitDataFrame(FramedStream.java:508)
at okhttp3.internal.framed.FramedStream$FramedDataSink.write(FramedStream.java:488)
at okio.RealBufferedSink.emitCompleteSegments(RealBufferedSink.java:171)
at okio.RealBufferedSink.write(RealBufferedSink.java:91)
I have a feeling this might be something to do with my okhttp client being set to retryOnConnectionFailure(true), but if that is the case, why a total loss of connectivity (airplane mode) is considered a recoverable failure?
EDIT 2:
Did some testing with retryOnConnectionFailure(false) and all of the above exceptions are now making it to my try/catch block. Also added an interceptor (network) and set retryOnConnectionFailure(true), repeated the test and noticed that okhttp goes into an endless loop of sending out requests to my server. Bug or a feature and I'm not using it correctly? Really confused with this behaviour..

AWS S3 Java SDK: detect time/clock skew programmatically?

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...

RestSharp & MonoDroid: Error getting response stream (ReadDone2): ReceiveFailure

I have a similiar situation like this: How do I handle/fix "Error getting response stream (ReadDone2): ReceiveFailure" when using MonoTouch? but I'm only GETing a list, not posting anything in the body.
Furthermore, I'm using RestSharp, and it works in almost all the cases, but every once in a while I receive Error getting response stream (ReadDone2): ReceiveFailure.
What can possibly be the problem?
(ps: the exact same code on Wp7 doesn't cause any errors)

There is a bug report (https://bugzilla.xamarin.com/show_bug.cgi?id=19673) which appears to have a reproducible example. So, at the least, you could add yourself to the CC list for it.
(BTW, I get the error (also using restsharp) under Linux (Mint/17, Mono 3.2.8), so it is not specific to Android. It is hard to reproduce: for me it is simply happening after between 1000 and 10,000 web service calls, and it always works when restarting. I am not seeing a CPU or memory problem. It could be some buffer build-up, or might simply be a network failure, or even remote server problem?)

Can't Catch NetworkOnMainThreadException

I know what causes a NetworkOnMainThreadException, as well as how to fix it, but for the purposes of improving the development experience, I'd like to be able to catch the exception and at least log the event or alert the user (who is still the developer at this point)...
Strangely, I'm not having any luck with this code (which sends and receives over my TCP socket):
try
{
toServer.println (msg.trim());
resp = fromServer.readLine();
}
catch (android.os.NetworkOnMainThreadException nex)
{ ... do something here ... }
Eclipse doesn't recognize that exception at all, and I copy-pasta-ed the exception type from the Android Developer website -- I'm pretty sure I spelled it right...
Is there something I don't know about Java (perhaps) that makes this exception uncatchable??
Thanks,
R.

Is there something I don't know about Java (perhaps) that makes this exception uncatchable??
Yes, StrictMode makes it uncatchable. Either way though, you should not catch this exception. Instead, you should implement your code correctly by wrapping your code in an AsyncTask. The reason why this exception is thrown is to prevent you from slowing down your application by blocking the UI thread.
Read my blog post for more info:
Why Ice Cream Sandwich Crashes Your App

Well I just tested this on my version of eclipse, and it works just fine.. I guess I would check which version of the api you are using? looks like to throw that exception you need a minimum api version 11. Otherwise perhaps eclipse is to blame? All I know is that this code is correct and should be executing without any issues.

Are you sure this is the first use of networking in your application?
If you are connecting to a server usually at that time NetworkOnMainThreadException should be thrown. Try adding a log statement before the try and see if it shows up. If it does not the Exception is thrown earlier.

IdleConnectionHandler removing a connection that never existed in my android app

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.