hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: NIO HttpCore - Can requestInput result in two new requests
Date Mon, 18 Aug 2008 12:47:45 GMT
On Sun, 2008-08-17 at 21:43 -0700, Rae Egli wrote:
> Oleg,
>  
> > I do not think so. I just ran a simple test using Apache Benchmark with 
> > 20 concurrent connections and all looked quite okay to me. I put the 
> > reverse proxy in front of a local Tomcat instance. 
> 
> Thanks for going through the effort.
>  
> I actually figured out the problem.  It can easily be seen in the trace I submitted.
>  
> It occurs if a request (conn1) has not been completed by the Origin and a new input request
is received using a different connection but which goes to the same destination host, in this
case Google.
>  
> Using the connection reuse startegy, the connection of the first request is reused by
the Origin.  Because the context/ProxyTask is associated with a connection, conn2 now gets
the ProxyTask of conn1 which is in a REQUEST_SENT state and therefore the process fails in
the Origin connect process.
>  
> By switching from DefaultConnectionReuseStrategy to NoConnectionReuseStrategy and therefore
forcing a new connection in the Origin, I was able to fix the issue as now a new ProxyTask
is associated with every connection from the Client.  However, this is not necessarily desirable.
>  
> I hope this helps explain the issue.  If you like more detail, please don't hesitate
to ask.
>  
> Rae
> 

Rae,

I chose a reverse proxy as an example primarily due to the fact that a
reverse proxy can get away with a much simpler connection management
logic than a normal caching proxy. 

One needs a significantly more complex logic for managing connections to
origin servers when implementing a production level caching proxy. It is
simply out of scope for HttpCore.

There are plans to start development of connection management components
based on HttpCore NIO similar to those that exist for blocking HttpCore
either as a separate project within HC or as an extension to HttpClient
4.0. Ideally those efforts should be driven by another contributor /
committer. 

Hope that clarifies things a little.

Oleg



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


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


Mime
View raw message