[
https://issues.apache.org/jira/browse/JCLOUDS-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14539775#comment-14539775
]
Ignasi Barrera commented on JCLOUDS-905:
----------------------------------------
Does this only happen with SSL connections? The default driver manages clear
text and SSL connections the same way.
The content stream life cycle in jclouds does not depend on the HTTP driver
being used. When the response is received, we check if it was successful or
failed (or it is a redirect, etc)
[here|https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/internal/BaseHttpCommandExecutorService.java#L100-L107].
That method also takes care of configuring the redirect and handling the
error, and in that case it also [releases the content
stream|https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/internal/BaseHttpCommandExecutorService.java#L134-L136]
because the current request has been completely processed.
However, if the response is succesful (2xx status code), we intentionally don't
close the stream (it might not be repeatable) and [just
return|https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/internal/BaseHttpCommandExecutorService.java#L123]
so the response body can be deserialized into the high level Java objets used
by the provider APIs. The _response parsers_ (the entities in jclouds that
deserialize the responses) take care of closing the stream once they're done
with it.
Looking at the spec of the 100 status code, it looks like the response does not
carry a body that should be deserialized, as the server still expects the
request to be completed, so the current {{statusCode >= 300}} check seems to be
inaccurate.
Should it be safe to always close the content stream on 1xx responses? The HTTP
drivers already close the content stream if the response is a 204, but it looks
like having 1xx response streams closed by defaut in the
{{BaseHttpCommandExecutorService}} is the way to go, since those responses are
unlikely to be used in the higher level provider APIs.
Do you want to try implementing such a change and test if it works?
> 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: 2.0.0, 1.9.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)
