hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Harald Hansen (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPCORE-291) Out-of-order responses to pipelined requests
Date Mon, 23 Jan 2012 21:43:44 GMT

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

Geir Harald Hansen commented on HTTPCORE-291:

I just tried SVN revision 1234972. It looks like postponed requests are now always cancelled
if the connection is closed. The issue with pipelining is avoided by detecting the situation
and responding with an error before closing the connection.

About the problem with postponed POST requests with body data, I have to apologize, there
is no bug. I was not aware that my telnet client was sending both linefeed and carriage return
when I hit enter. Adding 1 to the content-length in the testrun.txt example makes it run just

That just leaves support for pipelining of long polling requests.

I'm not sure how I'd expect it to behave. If a first request has its response delayed, should
processing of a second request continue immediately and that second response be queued until
the first response is sent? It could have a performance benefit. But also, it could mean the
data in the second response is out of date and useless by the time it is sent. The connection
could also get closed before the response can be sent which would mean that producing it was
a waste of resources. I think my vote would be on halting all processing on the socket until
either the delayed response is ready or the connection is closed.

I hope browsers don't do pipelining of AJAX requests.

I don't have any preference for BETA1 or BETA2, personally. HttpComponents now does everything
I need in my current projects in the current SVN revision. The next thing I would want is
a stable release with all the new features and bugfixes in it. So do BETA1 and BETA2 as you
prefer, I'll test them along the way.
> Out-of-order responses to pipelined requests
> --------------------------------------------
>                 Key: HTTPCORE-291
>                 URL: https://issues.apache.org/jira/browse/HTTPCORE-291
>             Project: HttpComponents HttpCore
>          Issue Type: Bug
>          Components: HttpCore NIO
>            Reporter: Geir Harald Hansen
>         Attachments: Test.java, testrun.txt
> I am having a problem with the latest HttpCore NIO from the Subversion repository (revision
1234228). I have not tested this on earlier versions.
> I am observing two problems, but they stem from the same underlying issue - that after
a response is delayed, processing of subsequent pipelined requests on the same socket continues
> Problem 1: If the response to your first request is delayed, but not the second, they
are delivered out of order.
> Problem 2: If a request has a body (entity) then right after processing that request
and delaying its response, there is a response on the wire ("400 Bad Request") and the connection
is terminated. When this happens none of the delayed responses are cancelled, that is Cancellable#cancel()
is never called.
> I will attach example source code, and an example of running telnet against the program,
to show what is happening. There is first a request that is delayed and never gets a response.
The second request gets a response immediately, out of order. The third request (a POST with
body) also has its response delayed. But then there is a 400 bad request response and the
connection is severed. The two delayed responses are not cancelled.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message