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: [EMAIL PROTECTED]
