jclouds-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Svetoslav Neykov (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCLOUDS-905) Expect: 100-Continue + SSL = timeout
Date Mon, 21 Nov 2016 11:32:28 GMT

    [ 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

> 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

This message was sent by Atlassian JIRA

View raw message