>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. ajp14 is in it's early stage and a uniq request id could be added but how will you use it ? >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. Very strange, but are you sure the web-server must trash incorrect replies (ie without the matching id ?) >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. That something I know well in my day job... >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? The request id could be easily added, ie a 32 bits incrementing id but I'd like to know the others developpers opinion....
