On 09/12/2019 00:44, Jerry Malcolm wrote: <snip/>
> Mark, thank you so much for the info. I downloaded the TC source and > got everything up and running in Eclipse. After getting familiar with > the paths when it worked normally, I was able to single-step a failure. > I added a request.getParameter( "abc" ) as the first line of the JSP. > It steps into the RequestFacade then to the Catalina Request object. I > see the lazy parsing you described. It checks "parametersParsed". In > this error case, parametersParsed is already set to true, so it skips > parsing. However this is the first time here for this request, and the > parameters have not been parsed, and the getParameter returns null. > > I grepped the source tree to see if there were any other places where > parametersParsed is being set to true. The parseParameters method is > the only place. Being the first line in the JSP, I'm not aware of any > other code above the JSP that would be causing the parsing. And it > appears the only way out of the parser method is with an error condition > or successful parse, which neither appears to happen, implying it's > never being called in the error condition... leading to the possibility > that parametersParsed is somehow incorrectly set to true coming in. > > I saw some code about recycling the object instance. I haven't dug into > any of that code. Is there any possible way that a request object could > be recycled without being wiped clean first? That should not be possible. > I see the recycle method > where everything is cleaned out. But I guess it could somehow throw an > exception while cleaning it out. I realize this is a long shot. But I'm > just grasping at straws as to why the object would indicate with no > errors that the parameters had been parsed when they hadn't. You could out a try/catch around the recycle method but I have a hard time trying to thing of a scenario that would throw an Exception there. > I guess my next step is to figure out how to breakpoint when request > objects are allocated from the pool and trace it all the way up to my > JSP line. Can you give me a pointer to the class(es) that handle > request object pool mgmt? The reference chain is: Processor -> CoyoteRequest -> Request. Processors are pooled and allocated starting here: https://github.com/apache/tomcat/blob/master/java/org/apache/coyote/AbstractProtocol.java#L772 The CoyoteRequest and Response object are final fields on the Processor: https://github.com/apache/tomcat/blob/master/java/org/apache/coyote/AbstractProcessor.java#L64 The Request and Response are held as notes on the corresponding Coyote objects: https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/connector/CoyoteAdapter.java#L303 > Also, I've seen several places in the code where it says "if debug" or > something like that. I've set logging to FINEST for everything, but I > believe there are debug statements that aren't showing. Is there > another way to enable 'debug'? That should be sufficient. Can you provide a specific example? > I'm resisting setting up a full rebuild environment of TC where I can > put in println statements. But I guess if that's required, I can do > it. If you'd like to talk me out that, I'm listening.... That is often where I end up investigating issues such as this. I usually try and turn those println statements into useful debug logging so I need less of them next time. Issues like this can be caused if a reference to a request or response is retained longer than it should be. You can try setting: -Dorg.apache.catalina.connector.RECYCLE_FACADES=true Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
