On 09/12/2019 19:54, Jerry Malcolm wrote: <snip/>
> Thanks to all of the responders on this problem. From the beginning of > this problem, I was convinced that I was doing something bad wrong to > cause this. I think now I have finally identified the 'bad thing'. > Periodically the model code that runs in the request determines that I > need to spin off another thread to do some background work. That thread > needs a few parameters from the request object. So I pass the request > object into the thread object. I realize now that doing that is a > horrible thing to do. I was not aware until yesterday that request > objects are pooled and recycled. So I figured holding onto the request > object a little longer before it is discarded for that thread to use was > not going to be a problem. Obviously, that was incorrect. Yep, that'll do it. > From what I can deduce, the main request thread finishes and returns. > The request object recycle code runs and the object is returned to the > pool. However, then the async thread later gets a parm and must > apparently still be able to use the request object even though it's back > in the pool. The 'parametersProcessed' gets set to true. Then the next > request comes in, and that request object is assigned with > parametersProcessed=true. I think this analysis is correct. > I'm assuming the fix is to get everything I need out of the request > object and pass those parm values to the thread before returning instead > of passing the request object itself to the thread. Correct. > Does all of this sound plausible as the source for this. The good news > is that I'm still teachable... :-) Very plausible. Kudos for figuring this out so quickly - and for the very clear write up. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
