Multi processor issue 2006-12-13 - By Leon Rosenberg
Back
On 12/13/06, Christopher Schultz <chris@(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@(protected)
To unsubscribe, e-mail: users-unsubscribe@(protected)
For additional commands, e-mail: users-help@(protected)
|
|
