jclouds-notifications mailing list archives

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

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

Andrew Gaul commented on JCLOUDS-905:

{quote}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

jclouds 2.0 supports Softlayer; you must set the provider to "openstack-swift", endpoint to
"https://sjc01.objectstorage.softlayer.net/auth/v1.0/" (or correct geo), and add "jclouds.keystone.credential-type"="tempAuthCredentials"
to overrides.

> 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