tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: Rewrite features
Date Thu, 03 Nov 2005 20:23:07 GMT
On 11/3/05, Bill Barker <> wrote:
> ----- Original Message -----
> From: "Costin Manolache" <>
> To: "Tomcat Developers List" <>
> Sent: Thursday, November 03, 2005 11:30 AM
> Subject: Re: Rewrite features
> On 11/3/05, Bill Barker <> wrote:
> >> It probably doesn't matter (since nobody uses it :), but using
> ThreadLocal
> >> won't work with the Nio/AJP Connector.  That one doesn't bind a Request
> >> instance to a Thread instance, so a particular Request instance will
> process
> >> on many different Threads during its lifecycle.
> >
> >Does the spec say anything about the thread model when executing a
> >servlet ? ( too lazy to search, I know some people on the list have
> >memorized the spec already :-)
> When an AJP Request comes in, the Connector gets a Thread from the Pool to
> process the Request.  After the Request is done processing, it returns the
> Thread to the Pool.  There is no reason that it should get the same Thread
> instance each time it does this.

Yes, but I tought all the service() method is still running in one
thread from start to finish.
The next AJP Request is a different servlet request - in the past it
was in the same thread only if Keep-Alive was used. If the connection
has expired ( keep alive timeout, or multiple connections from browser
) - it'll go to different thread.

The only case I knew where a service() will lose thread in the middle
is the Jetty continuation, where the thread is released by a sepecial
exception and extrenal event reaquire a random thread to continue.

> >
> >I'm not sure how this happens - I tought that the request is bound to
> >a thread during service() execution, and kept-alive connections are no
> >longer bound. How do we unbind the service() from the thread ???
> >
> We don't unbind the service() from the Thread.  However, in Coyote Request
> instances are very long lived objects that (at least for HTTP/1.1) persist
> over many connections.

But this is not guaranteed - you can't rely on this, there are many
cases where you would get a different thread.

> The APR Connector uses a ThreadLocal to bind the Request instance to a
> single Thread instance.  The next request that it handles may have been
> received on a different Socket than the last, but it is bound to the Thread.
> With the Java HTTP/1.1 Connector, the Request is bound to the Thread via the
> init() method of ThreadPoolRunnable.

I still don't understand the problem.
2 requests from the same browser can be assigned different threads in
both connectors. They get same thread in the old connector more often
- if they happen to use the same socket, but this is not allways the

I suppose I'm missing something trivial here...

> The Nio/AJP Connector binds the Request instance to a Socket connection (via
> the SelectionKey.attachment).


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message