On 12/9/2019 5:39 AM, Konstantin Kolinko wrote:
вс, 8 дек. 2019 г. в 08:09, Jerry Malcolm <techst...@malcolms.com>:
I have ajax code that sends requests to TC in a REST-style process. I
send the parms url-encoded in the body. This has worked untouched
literally for years. I have some new data objects in my db that "should
be" sending the same type of requests through the same javascript
routines. But for some inexplicable reason, the HttpServletRequest
object is randomly deciding to not process the parms. When I try to
enumerate the parms, I get none. Any parm I request comes back not
found. I added some code to read the body myself (request.getReader(),
etc). When the parms are available as it normally works, the reader is
empty, which is what I would expect since it's been read by the request
obj. But when the request object tells me I have no parms, I can read
the entire url-encoded parm string from the reader, which if I
understand things, means the request object never tried to read the
stream, unless it somehow restores the stream after a read (??). But
the important point I determined is that the parms are indeed present in
the body... just not processed.
[...]
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.
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'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.
Does all of this sound plausible as the source for this. The good news
is that I'm still teachable... :-)
Jerry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
