[jira] [Commented] (HTTPCORE-291) Out-of-order responses to pipelined requests

["Geir Harald Hansen (Commented) (JIRA)" <ji...@apache.org>]

    [ 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org