On 12/13/06, Christopher Schultz <[EMAIL PROTECTED]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chuck,
Slightly off-topic, there was a bug filed against the session manager
where a "session use" counter was being used in a non-threadsafe way
(and /really/ needed to be synchronized). The objection to
synchronization was based solely on performance (and a stubborn TC dev).
not to mention my all-time-favorite tomcat bug :-)
(http://issues.apache.org/bugzilla/show_bug.cgi?id=36541)
It occurs to be that TC could benefit from having a somewhat more
"layerable" configuration for these sorts of things. For instance, if TC
components could be decorated at any point in their initialization, one
would easily write a synchronized wrapper for the Request object and
wrap every request in that (via some configuration facility).
I'm all with you! It would be great if tomcat would expose a plugable
architecture, where factories for each kind of objects needed during
lifecycle (starting with servlet and filter, but also for
session/request/application context (alas its possible to replace the
session object by configuring tomcat to use a custom manager).
Unfortunately I see no chances it will ever be adopted by the TC dev,
especially after you called them/him "a stubborn TC dev".
regards
Leon
In that case, the OP could wrap their own request objects to actually
prevent their bug in production while researching it in dev/test,
instead of having to do little hacks like modifying processor affinities
and other things like that which only minimize the problem instead of
actually eliminating it.
Do you think any of the TC devs would be into anything like that? I
realize that a change like that would probably represent a drastic
re-factoring process, but it might be worth it for a number of components.
- -chris
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
