Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@jakarta.apache.org Received: (qmail 50815 invoked by uid 500); 6 Jun 2001 07:55:23 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: tomcat-dev@jakarta.apache.org Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 50655 invoked from network); 6 Jun 2001 07:55:15 -0000 Message-Id: <4.2.2.20010606095025.00e18990@mailserver.kippdata.de> X-Sender: jung@mailserver.kippdata.de X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 06 Jun 2001 10:00:37 +0200 To: tomcat-dev@jakarta.apache.org From: Rainer Jung Subject: AJP14 Suggestion In-Reply-To: <02dc01c0ee55$a28a0900$1e3a0e0a@kcs.com.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N I want to know how the developers think about adding a request id to ajp14= =20 requests, which is then presented back in the response phase. Background: We had serious trouble in diagnosing problems with tomcat 3.2 related to=20 bug 728 (SimplePool synchronization issue). The problem caused customers in an ecommerce application to receive=20 responses which belonged to other requests, i.e. were meant to be seen by=20 some other customer. This bug is fixed now, but I wonder if one could make= =20 the whole request-response handling more robust by adding an id to the=20 request. This id should then be given back by te response, preferably=20 during a very late phase. The requesting component could then check, if the= =20 request and response ids are the same. If furthermore the id would be part of the servlet infrastructure, then=20 application developers could take the id and pass it on the application=20 server etc. I know, that at the moment this is not contained in a standard or existing= =20 product, but in a situation where money is involved on the customer side,=20 people implementing solutions with tomcat would poosibly like very much=20 such checking possibilities. Once again: we had a hard time and were missing such a possibility a lot.=20 In Tomcat 3.2 you can easily produce stress test situations where a request= =20 gets as response body two valied bodies concatenated, one of them belonging= =20 to another request, or some other body, or no body at all, or a corrupted=20 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=DFe 33a 53111 Bonn Tel.: 0228/98549-0 Fax: 0228/98549-50 email: rainer.jung@kippdata.de