[
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 fine.
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 immediately.
> 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: [email protected]
For additional commands, e-mail: [email protected]
