hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rae Egli <re...@yahoo.com>
Subject Re: NIO HttpCore - Can requestInput result in two new requests
Date Mon, 18 Aug 2008 17:13:44 GMT

> I am still not sure this is the case. Please take a closer look the
> #connected methods of ListeningHandler and ConnectingHandler. Listening
> protocol handler always creates a new ProxyTask instance on each
> incoming client connection, requests a completely _new_ connection to
> the origin server and passes that ProxyTask instance to the connecting
> protocol handler as an attachment. As a result there is always a
> dedicated connection to the origin server for each and every connection
> to the proxy and the ProxyTask instance is shared by two connections,
> one client (incoming), one origin (outgoing). This is over-simplistic
> but not necessarily flawed.

If you look at the log that I initially submitted, you'll see that this instance would have
immediately caused trouble with the reverse proxy.  You are right that every new connect causes
a new ProxyTask to be established.  

However, browsers try to send multiple requests on the same connection if the destination
host is the same.  Therefore what happened is that the browser sent a second request on 54485
(not a new connection!) as a result "connect" is never executed.  Obviously no new ProxyTask
is created in that instance.  Search for this line in the log to see the evidence (lines marked
with ***** are my annotations of the log):

***** conn: 54485  received new SECOND request on original client connection

As you can see "connected" is not executed in this case but it is executed as a result of
requestInput() giving us the new connection (54487).   After the request by 54487, the Origin
then reuses the original connection to Google:80 which was first established from 54485 and
still has not been completed, i.e in a REQUEST_SENT state instead of IDLE or CLOSED.

If you follow it further you then see the inevitable, i.e. the Illegal target connection state:

> Also consider contributing ;-)

I will, given time and resources. :)


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

View raw message