Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification.
The "FAQ/Troubleshooting_and_Diagnostics" page has been changed by KonstantinKolinko: https://wiki.apache.org/tomcat/FAQ/Troubleshooting_and_Diagnostics?action=diff&rev1=20&rev2=21 Comment: Rearrange text about Response state troubleshooting E.g. [[https://bz.apache.org/bugzilla/show_bug.cgi?id=61289|61289]], [[https://bz.apache.org/bugzilla/show_bug.cgi?id=58457|58457]] - The main suspect is your own web application keeping a reference to Request / Response objects outside of their life cycle. (*) + The main suspect is '''your own web application''' keeping a reference to Request / Response objects outside of their life cycle. + + {{{#!wiki note + + The lifetime of the Response object is documented in the [[Specifications|Servlet specification]]. Quoting from section "5.8 Lifetime of the Response Object" of Servlet 4.0 specification: + + "Each response object is valid only within the scope of a servlet’s service method, or within the scope of a filter’s doFilter method, unless the associated request object has asynchronous processing enabled for the component. If asynchronous processing on the associated request is started, then the response object remains valid until complete method on !AsyncContext is called." + + In case of asynchronous processing, when an error occurs Tomcat notifies all registered `AsyncListener`s and then calls `complete()` automatically if none of the listeners have called it yet. (Reference: [[https://bz.apache.org/bugzilla/show_bug.cgi?id=61768#c3|61768]]) + + Also see sections "2.3.3.4 Thread Safety" and "3.13 Lifetime of the Request Object" of the same specification. + }}} + + To troubleshoot the issue: 1. Set the following [[http://tomcat.apache.org/tomcat-8.5-doc/config/systemprops.html#Security|system property]] in Tomcat configuration: {{{org.apache.catalina.connector.RECYCLE_FACADES=true}}} - When flag is set, Tomcat recycles facades to its internal objects when request processing completes. This makes it easier to spot illegal access when it happens, instead of waiting until side effects of such access become visible.<<BR>><<BR>> + When the above flag is set, Tomcat recycles facades to its internal objects when request processing completes. This makes it easier to spot illegal access when it happens, instead of waiting until side effects of such access become visible.<<BR>><<BR>> - This flag is also mentioned on the [[http://tomcat.apache.org/tomcat-8.5-doc/security-howto.html#System_Properties|Security Considerations]] page. The flag is `true` when Tomcat runs with enabled [[http://tomcat.apache.org/tomcat-8.5-doc/security-manager-howto.html|Java Security Manager]]. + This flag is also mentioned on the [[http://tomcat.apache.org/tomcat-8.5-doc/security-howto.html#System_Properties|Security Considerations]] page.<<BR>><<BR>> + The flag is `true` when Tomcat runs with enabled [[http://tomcat.apache.org/tomcat-8.5-doc/security-manager-howto.html|Java Security Manager]]. 2. Read about [[FAQ/KnownIssues#ImageIOIssues|Java ImageIO]] issue. - (*) '''Note''' - - The lifetime of the Response object is documented in the [[Specifications|Servlet specification]]. Quoting from section "5.8 Lifetime of the Response Object" of Servlet 4.0 specification: - - || Each response object is valid only within the scope of a servlet’s service method, or within the scope of a filter’s doFilter method, unless the associated request object has asynchronous processing enabled for the component. If asynchronous processing on the associated request is started, then the response object remains valid until complete method on AsyncContext is called. || - - In case of asynchronous processing, when an error occurs Tomcat notifies all registered `AsyncListener`s and then calls `complete()` automatically if none of the listeners have called it yet. (Reference: [[https://bz.apache.org/bugzilla/show_bug.cgi?id=61768#c3|61768]]) - - Also see sections "2.3.3.4 Thread Safety" and "3.13 Lifetime of the Request Object" of the same specification. ---- [[CategoryFAQ]] --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
