Develop Reference

Time out issue while sending MAKE_CREDENTIAL(0x01) response

I am developing Android Authenticator. I am getting the following exception while sending MAKE_CREDENTIAL response. I got this issue while debugging with webauthn.io site. Also tried with https://webauthn.me/debugger#
The operation either timed out or was not allowed. See: https://w3c.github.io/webauthn/#sec-assertion-privacy.
But I am using Timer and TimerTask to send kKeepAliveMillis for every 500 milliseconds after receiving MAKE_CREDENTIAL request. I don’t know why I am getting is this issue. Please help me to solve this issue.

Software caused connection abort

I've seen that there is tons of posts like this, but couldn't find one that helps me.
I've read in one of them that this a generic error, and it depends on what you are doing.
In my case, I've created a socket, got its input and output stream and use the output to send some data. The strange thing is that I can send things and the server receives them. But I get this error pretty often. Like, once every 5 minutes.
Don't know if might help, but at first I had the soTimeout of the socket as 10 seconds. After reading some articles, I've increased it to 1 minute.
Don't know if I can add code that helps, because I litterally have the error when I do
output.write(byte[])
but if you think it might be something I could add, feel free to ask
Thanks in advance

java.util.concurrent.TimeoutException: id.finalize() timed out after 10 seconds

Our company's app encountered a crash, but this problem is not necessarily present, I can not reproduce the problem now, we can provide me with the next solution to ideas
id.finalize() id is RandomAccessFile's Subclass .
this STACK_TRACE is :
java.util.concurrent.TimeoutException: id.finalize() timed out after 10 seconds
at libcore.io.Posix.fstat(Native Method)
at libcore.io.ForwardingOs.fstat(ForwardingOs.java:56)
at libcore.io.BlockGuardOs.close(BlockGuardOs.java:60)
at libcore.io.IoUtils.close(IoUtils.java:43)
at java.io.RandomAccessFile.close(RandomAccessFile.java:166)
at java.io.RandomAccessFile.finalize(RandomAccessFile.java:175)
at java.lang.Daemons$FinalizerDaemon.doFinalize(Daemons.java:194)
at java.lang.Daemons$FinalizerDaemon.run(Daemons.java:176)
at java.lang.Thread.run(Thread.java:841)

This sounds like broken memory that caused writes to it to take too long. Happens when you use bad sd cards. You should do a stress test and write many bytes to a file and close it.

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

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?)