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
signature.asc
Description: OpenPGP digital signature
