I want to know how the developers think about adding a request id to ajp14
requests, which is then presented back in the response phase.
Background:
We had serious trouble in diagnosing problems with tomcat 3.2 related to
bug 728 (SimplePool synchronization issue).
The problem caused customers in an ecommerce application to receive
responses which belonged to other requests, i.e. were meant to be seen by
some other customer. This bug is fixed now, but I wonder if one could make
the whole request-response handling more robust by adding an id to the
request. This id should then be given back by te response, preferably
during a very late phase. The requesting component could then check, if the
request and response ids are the same.
If furthermore the id would be part of the servlet infrastructure, then
application developers could take the id and pass it on the application
server etc.
I know, that at the moment this is not contained in a standard or existing
product, but in a situation where money is involved on the customer side,
people implementing solutions with tomcat would poosibly like very much
such checking possibilities.
Once again: we had a hard time and were missing such a possibility a lot.
In Tomcat 3.2 you can easily produce stress test situations where a request
gets as response body two valied bodies concatenated, one of them belonging
to another request, or some other body, or no body at all, or a corrupted
one. An id would at least make sure the response belongs to the right request.
In the apache 1.3 szenario, the id would have to be generated by mod_jk!
Any comments?
Rainer Jung
kippdata informationstechnologie GmbH
Bornheimer Straße 33a
53111 Bonn
Tel.: 0228/98549-0
Fax: 0228/98549-50
email: [EMAIL PROTECTED]
