> I don't think this is a bug in TC's implementation. This is a
> relatively subtle mistake that seems both easy enough to make
> and easy to fix.

Maybe Tomcat should enforce this like for instance when we get an
exception trying to write into a response that was already committed.
It would have saved weeks of effort on our side.

> Gael, what was the reasoning behind caching that
> RequestDispatcher? Was it simply because you would have been
> calling the same method with the same parameters repeatedly,
> and figured that you'd get some performance edge by saving
> the resulting object? Were you observing any performance
> degradation at any point? Or was this a case of premature
> optimization? ;)

We did implement this 2 years ago, so details have vanished but it was
mainly based on our spec interpretation and also I admit on premature
optimization.

In several places, the spec defines different behaviors of
RequestDispatcher when it was obtained using getNamedDispatcher(String)
and noticeably for handling parameters.
So, our interpretation was that a RequestDispatcher obtained using
getNamedDispatcher() was different than one obtained using
getRequestDispatcher(): it has a different behavior and a wider scope.
This was the reason behind our implementation and also the fact that our
previous container (before migrating to Tomcat) seemed to work this way
(as far as I remember).

> I'd really like to hear if simply eliminating the caching of
> this object fixes your problem. Does it?

So far so good, the new code has been running fine for 2 hours while it
was failing usually within 30 minutes.

Gael

---------------------------------------------------------------------
To start a new topic, e-mail: users@(protected)
To unsubscribe, e-mail: users-unsubscribe@(protected)
For additional commands, e-mail: users-help@(protected)