On 6/6/07, Craig McClanahan <[EMAIL PROTECTED]> wrote:
Speaking as the original author of this part of Tomcat in 4.1 and 5.0 (and it hasn't changed that much in 5.5 and 6.0 AFAICT), request and response instances can indneed be pooled and reused for *different* requests. That being said, Tomcat has been pretty rigorously tested for thread safety by virtue of the fact that tens of thousands of applications (many very high volume) are running on it. It is *substantially* more likely that there are thread safety issues in user code (such as simultaneous access to session scoped or application scoped beans), rather tha a bug in Tomcat, when you see intermittent issues like this.
I'm not debating that there could be bad user code here....(although I've reduced my test cases down to an empty axis service call and an nearly empty struts action....If there IS bad code, it's probably at a low level inside axis or struts or some other library that I don't have immediate control over) What I'm trying to determine if the re-use of response instances could be the reason why the axis servlet is getting a response given to it that is already in a committed state... I'm not 'afraid' of dealing with pooled objects that may be in a questionable state (like with database connection pool handles...knowing to check/set auto-commit on them when acquiring them from pool because the previous user may have changed some settings on them)...I'm just interested in knowing if this is a 'known' danger of running without a security manager on Tomcat (5.5) and just as easily avoidable. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
