On 21/10/18 12:36, Durand, Dustin wrote:
> On 10/20/18, 3:34 PM, "Caldarale, Charles R" <chuck.caldar...@unisys.com>
> wrote:
>> your application is likely hanging on to some reference to the prior request
>> and inadvertently using it when a new request shows up.
>> This often takes the form of instance variables in a servlet being used to
>> hold request information.
>> Since the servlet object is shared across all requests using it, information
>> leakage can occur between concurrent requests; this is
>> also true for filters used in the request handling.
>> Leakage can also occur with other singletons used by the webapp, or in any
>> persistent data maintained by the app (e.g., in a session object).
>
> This makes sense, but, unless I'm misunderstanding, I'm not sure it applies
> in this case.
>
> When we started seeing getCookies() returning null, although a valid cookie
> header was present, the "AccessLogFilter" class was created and added as the
> first filter to be applied in the chain.
>
> It has no instance variables and collects all its information from the
> provided ServletRequest argument, before passing the HttpServletRequest down
> the chain.
> If there was an issue where a filter, servlet, or singleton was caching (and
> reusing) the old request, then this "first" filter should be unaffected,
> since it's above all other application code, and references nothing but the
> slf4j logger.
>
> The data gathered by the AccessLogFilter should be coming from a brand-new
> instance of HttpServletRequest that's coming from Tomcat.
>
>
> If I've made a mistake in any of my assumptions above, please let me know.
Tomcat recycles HttpServletRequest objects. If an application retains a
reference to a request then you can see the behaviour you describe.
Setting the following system property:
org.apache.catalina.connector.RECYCLE_FACADES=true
will cause Tomcat to create a new wrapper for each request/response.
This has two advantages. One it should stop one request seeing data from
another. Two it should trigger an NPE when the application tries to
access to request/response that has been retained after it should have
been discarded.
Mark
>
> -------
> public class AccessLogFilter implements Filter {
>
> private static final Logger log =
> LoggerFactory.getLogger(AccessLogFilter.class);
>
> public AccessLogFilter() {}
>
> public void doFilter(ServletRequest request, ServletResponse response,
> FilterChain chain) throws IOException, ServletException {
> HttpServletRequest httpServletRequest = (HttpServletRequest) request;
>
> StringBuilder message = new StringBuilder();
> message.append("StartTime=\"" + getTimestamp()+"\"");
> message.append(" requestURI=\"" + httpServletRequest.getRequestURI()
> + "\"");
> ...
> chain.doFilter(request, response);
> log.info(message.toString());
> }
> ...
> ------
>
> StackTrace @ AccessLogFilter
> 1. DoFilter -> AccessLogFilter (Our new filter)
> 2. InternalDoFilter -> Application Filter Chain (org.apache.catalina.core)
> 3. Invoke -> StandardWrapperValue (org.apache.catalina.core)
> 4. Invoke -> StandardContextValue (org.apache.catalina.core)
> 5. Invoke -> AuthenicatorBase (org.apache.catalina.authenicator)
> ... (All related to org.apache.*, until we hit the java concurrency frames
> for the thread)
>
> -----
>
>
>
> Thanks,
> Dustin
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
