[
https://issues.apache.org/jira/browse/JCLOUDS-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15683332#comment-15683332
]
Svetoslav Neykov commented on JCLOUDS-905:
------------------------------------------
Long after the fact, just saw your comments [~nacx].
For me the solution was to force {{PROPERTY_CONNECTION_CLOSE_HEADER}}. Can't
test with {{http}} as only {{https}} is available. In my case it was
Softlayer's swift implementation. Unlike JCLOUDS-181 Softlayer supports {{100
Continue}} responses. Something in common - {{PROPERTY_SO_TIMEOUT}} might have
been involved.
It's not a bug in jclouds, more of a problem with Java's interaction between
the wrapping SSL stream and the underlying http stream state machines,
triggered by the GC finalizing them.
As for your suggestion - If I remember correctly the {{100}} status code is not
visible to the caller. The Java stream's internal logic is designed to expect
it and skip it, returning to the user the final response.
Given that Softlayer is not supported in Jclouds 2.0 there's no point in
chasing this up. Sounds like {{jclouds.strip-expect-header}} will work as a fix
as well so I'm happy with the resolution.
> 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, jclouds-core
> 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)
