tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject AJP14 Suggestion
Date Wed, 06 Jun 2001 08:00:37 GMT
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: rainer.jung@kippdata.de


Mime
View raw message