Gael,

Marziou, Gael wrote:
>> 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.

Can you suggest a fix? I'm not sure how this kind of thing could be
safely veto'd... for instance, it might actually be appropriate for a
RequestDispatcher to be re-used in some context (say, repeating a
request twice) or even to do so with different threads, as long as the
access is done strictly serially.

> 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.

No problem. I'm pretty sure we're all guilty of that some of the time.

> 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.

Agreed... the "spirit" of the "named dispatcher" as opposed to a
standard dispatcher obtained for a certain URI seems to be that it could
be used universally.

> 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).

Perhaps TC should consider returning an object of a different type when
using getNamedDispatcher -- one that does not keep any request-related
information at all.

>> 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.

Fantastic! I'm glad we were able to help, even if it did take a while.

-chris