tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <wbar...@wilshire.com>
Subject Re: Rewrite features
Date Thu, 03 Nov 2005 20:38:54 GMT

----- Original Message -----
From: "Remy Maucherat" <remm@apache.org>
To: "Tomcat Developers List" <dev@tomcat.apache.org>
Sent: Thursday, November 03, 2005 12:11 PM
Subject: Re: Rewrite features


>Costin Manolache wrote:
>> On 11/3/05, Bill Barker <wbarker@wilshire.com> 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 :-)
>>
>> 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 ???
>
>There must be a misunderstanding somewhere: the thread is indeed bound
>during the execution of the adapter process method, so TLs should work
>the way I am using them. Using notes is difficult for this because there
>can be "nested" rewrites (one at host level + one at context level, for
>example). I would have preffered using that for performance, of course;
>maybe an array would do it, or something, but TLs are cleaner to
>understand. I do need plenty of TLs anyway, as the regexp engine is per
>thread. For some reason, it took me a long time to figure out a design
>that I liked, worked and met the requirements (I suck).
>

The TomcatResolver instance is holding a reference to the Request instance,
and is in a TL.  As a result (because of the way the ThreadPool works) it
will live very much longer than just during the processing of a given
Request.  This is all fine for all of the current Connectors except Nio/AJP,
since they happen to bind the Request instance to the Thread instance so you
always get the right Request instance.

Adding a setRequest method to TomcatResolver would "fix" this with the
minimal amount of work.



This message is intended only for the use of the person(s) listed above as the intended recipient(s),
and may contain information that is PRIVILEGED and CONFIDENTIAL.  If you are not an intended
recipient, you may not read, copy, or distribute this message or any attachment. If you received
this communication in error, please notify us immediately by e-mail and then delete all copies
of this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet
is not secure. Do not send confidential or sensitive information, such as social security
numbers, account numbers, personal identification numbers and passwords, to us via ordinary
(unencrypted) e-mail.


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


Mime
View raw message