Svetoslav Neykov created JCLOUDS-905:
----------------------------------------
Summary: Expect: 100-Continue + SSL = timeout
Key: JCLOUDS-905
URL: https://issues.apache.org/jira/browse/JCLOUDS-905
Project: jclouds
Issue Type: Bug
Components: jclouds-blobstore
Affects Versions: 1.9.0, 2.0.0
Reporter: Svetoslav Neykov
A bug in the state logic of HttpsUrlConnection used by the default http driver
will cause it to block and wait for headers at the wrong time when used with
"Expect: 100-Continue" header. When triggered the soTimeout value is not
applied on the socket which leads to indefinite block on a read call, only to
be cancelled by a server timeout.
The bug is triggered when using
* Expect: 100-Continue
* on Java 7 or Java 8
* on SSL connection
* connection reuse is enabled (by default)
* the stream returned by the call is not closed by the caller
* but instead is closed by the GC
Closing the socket by GC trips the state logic of the "Expect: 100-Continue"
feature, eventually leading to failure to parse the http stream coming from the
server.
The problem is not specific to objectstore or even jclouds, but is triggered
here because of the use of "Expect: 100-Continue". Seems like using it in
combination with SSL connections will inevitably lead to failed requests.
A jclouds test case which reproduces the behaviour can be found at
https://github.com/apache/incubator-brooklyn/blob/master/locations/jclouds/src/test/java/brooklyn/entity/rebind/persister/jclouds/JcloudsExpect100ContinueTest.java
Note that if wire logging is enabled the problem can't be reproduced (closing
streams explicitly?)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)