Simon,
On 7/18/24 14:54, Simon Arame wrote:
Greetings folks,
According to JavaServer Pages™ specs v2.3 #JSP4.2, when a JSP page does not
provide the TYPE value of the contentType attribute, "the initial content
type is “text/html” for JSP pages in standard syntax"
With our relatively big web application, we are experiencing an
intermittent issue which is a missing Content-Type header on some JSP pages
and the issue goes away when we use 9.0.90+ or set
org.apache.catalina.connector.RECYCLE_FACADES to true.
This is likely because the default for that setting changed in 9.0.90
from "false" to "true":
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html#Tomcat_9.0.90_(remm)
If the issue goes away when discarding facades, my first response would
be to suggest that there is an issue in the application which is
retaining a reference to a response object and damaging that content-type.
It's also possible that there is a subtle bug in Tomcat where the
content-type isn't being reset as expected.
Some of our clients are not easily updating their tomcat version so I would
like to know what we are doing wrong maybe in our custom Filter that causes
the occasional missing content-type when facades are not recycled.
It may be very difficult to track-down the source of this issue. If you
are able to provide a simple JSP that behaves in this way and perhaps a
Filter that sometimes causes an issue, we may be able to help track it
down. But if you can't share code, we can't help.
It may be better for you to simply reconfigure your clients to disable
facade reuse either by using the RECYCLE_FACADES=true system property or
to use the discardFacades="true" <Connector> attribute which has been in
Tomcat 9.0.x since 9.0.31:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html#Tomcat_9.0.31_(markt)
I got help from Konstantin Kolinko to locate some historical tomcat code
changes. What I was trying to determine is details about the "recycle"
method of the Request implementation and with Konstantin's help (see
below), I make the reconciliation with the CoyoteRequest and the
CoyoteRequestFacade classes. Now I can see the commit 301781 simply adds
those. Is this coming straight on from a CVS repository ? If yes, can the
CVS repository archive can still be publicly accessed ? At this point, I am
not sure if commit 302827 (
https://svn.apache.org/viewvc?view=revision&revision=302827 ) would explain
what i was searching for. My point is that at 301781 (
https://svn.apache.org/viewvc?view=revision&revision=301781 ), the facade
is only cleared if Constants.SECURITY is true and now since 9.0.90, facades
are cleared by default unless you change the option
org.apache.catalina.connector.RECYCLE_FACADES to false.
The facade is always "cleared" in one way or the other. When the facade
will be re-used (aka "recycled"), the information that had previously
been in the facade needs to be "cleared" by nulling-out references and
setting primitive fields back to their defaults.
If the facade will be discarded and a new object created in its place,
there is no reason to explicitly "clear" the old object... Tomcat simply
lets the reference go out of scope and the GC will clean it up at some
point. So when the facade will be GC'd, we don't bother blanking-out all
those fields.
So following that logic, I found out what facade recycling was but I don't
know why we rely on it.
This is a performance optimization that IMHO is mostly historical at
this point. Requests ought to be fast enough that the cycle of request
-> new object -> end request -> GC should be very cheap as most requests
will not "survive" a minor GC action. The effects of "new/malloc" and
(conceptually) delete/free are essentially zero with modern Java memory
managers for short-lived objects.
The missing content-type occurs when we navigate quickly between jsp pages.
Here are some of the actions we performed in our custom Filter,
1. we are conditionally setting some headers on the Response object.
Where does this happen? In the doFilter method, or elsewhere? If you are
not retaining any references to the response (or request, for that
matter) after doFilter ends, then this issue shouldn't be "your fault".
But if you are stashing references to the HttpServletRequest or
HttpServletResponse into the request, response, session, some
object-level or class-level member, etc. then you might be causing this
problem yourself.
2. we are conditionally calling the RequestDispatcher.include method to add
a JSP head ( stuffs like <html><head><meta /><script ... /><style ...
/></head> )
This sounds like a job for a view-framework, but should have nothing to
do with the behavior you are describing.
3. depending on an external authentication call result we are either
sending a redirect or calling FilterChain.doFilter
Sounds okay to me so far.
Please note that we tried the following without success:
- declaring a default-content-type inside a jsp-property-group as
prescribed by the JavaServer Pages™ Specification v2.3 #JSP.3.3.9
I checked, and a new Response object (and friends) should have a
Content-Type header of null. The recycle method (which clears these
fields) likewise sets the content type to null and not any kind of
"default value" such as "text/plain", etc. That suggests to me that the
default is established elsewhere and so the "problem" is not
directly-related to recycling (re-using) the facade, response, etc.
That points more toward something your application is doing and less
toward a problem with Tomcat.
Hope that helps,
-chris
---------- Forwarded message ---------
From: Konstantin Kolinko <knst.koli...@gmail.com>
Date: Thu, Jul 18, 2024 at 2:15 PM
Subject: Re: Earlier Tomcat source code
To: Simon Arame <saxeo...@gmail.com>
чт, 18 июл. 2024 г. в 19:23, Simon Arame <saxeo...@gmail.com>:
Hi,
Thank you for this reply, is it ok if I forward this to the mailing list
with additional questions ?
OK.
Best regards,
Konstantin Kolinko
On Thu, Jul 18, 2024 at 9:43 AM Konstantin Kolinko <knst.koli...@gmail.com>
wrote:
вт, 16 июл. 2024 г. в 22:44, Simon Arame <saxeo...@gmail.com>:
Hi,
I recently experienced a problem with tomcat that was fixed by release
9.0.90.
However, i would like to get a way around the actual proposed fix
which simply changes the default value of property
org.apache.catalina.connector.RECYCLE_FACADES.
And to understand what's going on, i'm trying to follow the commit
history.
I first stumbled on your message
https://svn.haxx.se/dev/archive-2011-09/0558.shtml that states that tc6 can
not be browsed before 389146/389140
then, i tried to follow the subversion history of the file
org.apache.catalina.connector.Request.java which at revision 302975 changed
from being an interface to being a class. the commit message mentioned it
was copied over from Coyote Adapter, but when I go to coyote subfolder the
Request.java that is there let's say at revision 302974 is the same class
but at an earlier version.
So i'm trying to fill the gap to understand what happened to that
internal Request class between 302975 and earlier, let's say
https://svn.apache.org/repos/asf/tomcat/connectors/trunk/coyote/src/java/org/apache/coyote/Request.java@301074
...
Regarding looking up the old Tomcat sources
1. If you look at the commit message for r302975,
https://svn.apache.org/viewvc?view=revision&revision=302975
it mentions "I'm using version number 5.5 for this refactoring, as an
indication that this is no longer 5.0.x."
Essentially, it looks like a commit that branched off Tomcat 5.5.x,
and thus the earlier code is with Tomcat 5.0.x.
https://svn.apache.org/viewvc/tomcat/archive/tc5.0.x/trunk/
2. Tomcat consists of several Layers (or Components):
Catalina is the container, i.e. Servlet container. It implements the
Servlet specification.
Coyote is the underlying implementation of network protocols (HTTP,
AJP), and all that stuff.
There are two "Request" and "Response" classes: one pair in Catalina,
and one pair in Coyote.
The CoyoteAdapter class is a component of Catalina.
3. In Tomcat 5.0 the relevant code is here:
https://svn.apache.org/viewvc/tomcat/archive/tc5.0.x/trunk/container/catalina/src/share/org/apache/coyote/tomcat5/
Essentially CoyoteRequest class of Catalina [1] became Request class
of Catalina [2].
[1]
https://svn.apache.org/viewvc/tomcat/archive/tc5.0.x/trunk/container/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java?revision=588818&view=markup
[2]
https://svn.apache.org/viewvc/tomcat/container/catalina/trunk/catalina/src/share/org/apache/catalina/connector/Request.java?view=markup&pathrev=302975
If you look at commit 302975 closely, there is the following line:
tomcat/container/catalina/trunk/catalina/src/share/org/apache/coyote/
deleted
That is the directory that contained the old code.
4. If you go further into older code, the source control system at
that time was CVS.
https://en.wikipedia.org/wiki/Concurrent_Versions_System
Essentially, CVS does not version directories. While with Subversion
you can commit several files at once, with CVS you essentially commit
single files. A migration tool essentially tried to recreate
multi-file commits from individual files. Thus you may need to look at
adjacent commits in the Subversion repository to see related changes
in other files.
5. I think that you would better understand Tomcat code if you run it
with a debugger. See
https://cwiki.apache.org/confluence/display/TOMCAT/Troubleshooting+and+Diagnostics#TroubleshootingandDiagnostics-CommonTroubleshootingScenario
and
https://cwiki.apache.org/confluence/display/TOMCAT/Developing#Developing-Debugging
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
