CoreConnectionPNames.STALE_CONNECTION_CHECK
='http.connection.stalecheck':
determines whether stale connection check is to be used. Disabling stale
connection check may result in a noticeable performance improvement (the
check can cause up to 30 millisecond overhead per request) at the risk of
getting an I/O error when executing a request over a connection that has
been closed at the server side. This parameter expects a value of type
java.lang.Boolean
. For performance critical
operations the check should be disabled. If this parameter is not set, the
stale connection check will be performed before each request execution. // Shut down the SSL connection, per se.
try {
if (handshakeStarted) {
BlockGuard.getThreadPolicy().onNetwork();
NativeCrypto.SSL_shutdown(sslNativePointer, fd, this);
}
} catch (IOException ignored) {
/*
* Note that although close() can throw
* IOException, the RI does not throw if there
* is problem sending a "close notify" which
* can happen if the underlying socket is closed.
*/
}
Thanks for reporting the problem. We have not had a chance to investigate this issue yet, so it is unlikely to behave differently with the new version 1.7. Just for clarification, the issue you encountered actually happens on an Android device with FroYo SDK or with a later version?
Yaniv Inbar
Senior Software Engineer
Google Inc.
tl;nr:
the Froyo version performs
try { if (handshakeStarted) nativeclose();} catch (IOException ex) {
pendingException=ex; }
, while in ICS the IOException is ignored. Froyo does the same cleanup
and after that re-throws the pendingException.
BR,
Alex
Attached find the files from Android 2.2_r1 source tree and, for
comparison, from 4.0_r1.tl;nr:
the Froyo version performs
try { if (handshakeStarted) nativeclose();} catch (IOException ex) {
pendingException=ex; }, while in ICS the IOException is ignored. Froyo does the same cleanup
and after that re-throws the pendingException.BR,
Alex
Enjoy