AJP14 Suggestion

[Rainer Jung <ra...@kippdata.de>]

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

Re: AJP14 Suggestion

[kevin seguin <se...@motive.com>]

i guess i'm just not sure of the usefullness of an id for ajp
requests...  haven't really thought much about it though...

-kevin.

Rainer Jung wrote:
> 
> 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