> 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@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
