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 Tue, 22 Nov 2016 08:09:58 GMT

    [ https://issues.apache.org/jira/browse/JCLOUDS-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15686025#comment-15686025
] 

Svetoslav Neykov commented on JCLOUDS-905:
------------------------------------------

I stand corrected. [{{jclouds.strip-expect-header}}|https://github.com/apache/brooklyn-server/blob/master/locations/jclouds/src/main/java/org/apache/brooklyn/location/jclouds/JcloudsUtil.java#L275-L283]
was the fixed I used as well.
With {{strip-expect-headers}} enabled it still block for 5 seconds (not sure where the timeout
comes from), then retries in a new connection. This got better from before in that it used
to block indefinitely. Could be fixed in the Java implementation (testing with {{1.7.0_80}}).

Thanks for the tip [~gaul]. I'll give it a try.

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

Mime
View raw message