On 11/3/05, Bill Barker <[EMAIL PROTECTED]> wrote: > > ----- Original Message ----- > From: "Costin Manolache" <[EMAIL PROTECTED]> > To: "Tomcat Developers List" <dev@tomcat.apache.org> > Sent: Thursday, November 03, 2005 11:30 AM > Subject: Re: Rewrite features > > > On 11/3/05, Bill Barker <[EMAIL PROTECTED]> 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 case. I suppose I'm missing something trivial here... > > The Nio/AJP Connector binds the Request instance to a Socket connection (via > the SelectionKey.attachment). Costin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]