Re: Tomcat Internal Architect for JSP compilation?
Hi Chris Thanks for your response. So i added below properties in application.properties file > spring.mvc.cache-control.cache-allowed=false > > and then Deleted the /tmp/tomcat directory . So now when i restart the server A.jsp only fail with 500 error (ClassNotFoundException) as this is first page which i was trying to load, rest JSP pages working fine without any issue . Why i am doing this exercise? In our some of the deployed linux environment many clients are complaining about this issue , We tried to monitor who actually deleting these /tmp/tomcat folder but still we are not able to figure it out and we are not able to reproduce it . So i have to do reproduce it manually deleting the /tmp/tomcat directory. thanks & regards On Thu, Mar 21, 2024 at 7:24 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > Subudh, > > On 3/21/24 07:32, Subodh Joshi wrote: > > Expert, > > > > Recently i came across a issue and i was getting no clue what was going > on > > wrong with the Application. > > > > So here is the issue , we were getting following issue in our web > > application(Springboot+Embedded Tomcat) which is deployed into Linux > machine > > > > java.lang.ClassNotFoundException: > >> org.apache.jsp.WEB_002dINF.jsp.ImportTab_jsp > >> at > >> java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:445) > >> at > >> org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:129) > >> at > >> org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:58) > >> at > >> > org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:151) > >> at > >> > org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:189) > >> at > >> > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:410) > >> at > >> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:380) > >> at > >> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:328) > >> at > jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658) > >> at > >> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:205) > >> at > >> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149) > >> at > >> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51) > >> at > >> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:174) > >> at > >> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149) > >> at > >> > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:110) > >> at > >> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:174) > >> at > >> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149) > >> at > >> > org.springframework.web.filter.CompositeFilter$VirtualFilterChain.doFilter(CompositeFilter.java:108) > >> at > >> > org.springframework.security.web.FilterChainProxy.lambda$doFilterInternal$3(FilterChainProxy.java:231) > >> at > >> > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:365) > >> at > >> > org.springframework.security.web.access.intercept.AuthorizationFilter.doFilter(AuthorizationFilter.java:100) > >> at > >> > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374) > >> at > >> > org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:126) > >> at > >> > org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:120) > >> at > >> > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374) > >> at > >> > org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:100) > >> at > >> > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374) > >> at > >> > org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:179) > >> at > >> > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374) > >> at > >> > org.springframework.security.web.savedrequest.RequestCacheAwareFilter.doFilter(RequestCacheAwareFilter.java:63) > >> at > >> > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374) > >> at > >> >
Re: HttpSession tracking
Just to add a bit more information, our handler class, for better or for worse, implements the following interfaces all in one class: implements HttpSessionBindingListener, HttpSessionActivationListener, HttpSessionIdListener, HttpSessionListener, ServletContextListener We also use that same class as our "session model" object that we bind as an attribute to the session itself (it's a bit of a mixed bag historically that I want to clean up). And in terms of registration, we do not have any annotations on the class, instead we register it in web.xml (in the application WAR file) using a standard listener entry: <> Our web.xml is set at Servlet API version 3.0 (kind-of old), and we are running against Tomcat 9.5 (and this worked on 8.5 and before as well). Not sure if that adds anything Chris that you haven't already looked at. I would really prefer a way to query the sessions from the app, but as we know, that's not part of the current Servlet specification, or any extensions Tomcat currently provides. Robert On Thu, Mar 21, 2024 at 3:31 PM Robert Turner wrote: > We receive the sessionWillPassivate and sessionDidActivate callbacks on > startup. Odd that you are not. That's how we achieve the same. > > On Thu, Mar 21, 2024 at 3:25 PM Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> All, >> >> After having written a solution using JMX to do something like this, I'd >> like to make it cleaner and I'm not sure it's entirely possible using >> just Servlet APIs. >> >> I'd like to be able to track every HttpSession for the application. >> >> for admin purposes, I'd like to be able to analyze: >> >> 1. The total number of sessions >> >> 2. The number of sessions which represent a logged-in user vs a >> crawler-session or someone who visited the home-page and got a session >> but never logged-in >> >> 3. Checking-out some specific roles of those logged-in users e.g. >> end-user, staff, admin >> >> 4. Be able to kill a session at will. For example "chris is already >> logged-in, kill his old session and let the new login remain" >> >> I started with the obvious HttpSessionListener + >> HttpSessionActivationListener, but I tried this experiment and it didn't >> turn out how I expected: >> >> 1. Start the application and hit the front page >> >> -> I get a call to HttpSessionListener.sessionCreated (expected) >> >> 2. Login >> >> 3. Logout >> >> -> I get a call to HttpSessionListener.sessionDestroyed (expected) >> -> I get a call to HttpSessionListener.sessionCreated (expected) >> (this second one happens because our home-page creates a session) >> >> 4. Login again >> >> 5. Stop Tomcat >> >> -> No calls to anything I can see >> >> 6. Start Tomcat >> >> -> No calls to anything I can see >> >> 7. Access a protected page >> >> -> Access is allowed; I'm still logged-in. >> >> When Tomcat shuts-down, it's saving the sessions using local >> persistence[1]. When the application comes back up, all those sessions >> are restored from the disk. >> >> When my HttpSeessionListener starts, it's empty and doesn't know about >> any sessions. Tomcat doesn't notify it that any sessions are coming from >> that storage. >> >> I would have expected calls to >> HttpSessionActivationListener.sessionWillPassivate and >> HttpSessionActivationListener.sessionDidActivate. >> >> Do I have unrealistic expectations? Is there a way to capture these >> events so my in-memory session-watcher/manager is able to have an >> accurate view of what Tomcat can see? >> >> Thanks, >> -chris >> >> [1] >> >> https://tomcat.apache.org/tomcat-8.5-doc/config/manager.html#Persistence_Across_Restarts >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >>
Re: [EXT]Re: Tomcat 10 waning that expireSessionsOnShutdown is not set
> On Mar 21, 2024, at 14:50, Rick Noel wrote: > > Do you have a feel if DeltaManager is better than BackupManager? Depends on what your needs are. There are some presentations on the subject that you might want to look at: https://tomcat.apache.org/presentations.html ApacheCon 2018 NA: Deep dive into Tomcat Clustering, Keiichi Fujino TomcatCon London 2017: Reverse Proxies, Load-Balancing & Clustering, Mark Thomas - Chuck
RE: [EXT]Re: Tomcat 10 waning that expireSessionsOnShutdown is not set
Thank you Chuck Do you have a feel if DeltaManager is better than BackupManager? Rick Noel Systems Programmer | Westwood One rn...@westwoodone.com -Original Message- From: Chuck Caldarale Sent: Thursday, March 21, 2024 3:37 PM To: Tomcat Users List Subject: [EXT]Re: Tomcat 10 waning that expireSessionsOnShutdown is not set [You don't often get email from n82...@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > On Mar 21, 2024, at 14:23, Rick Noel wrote: > > Could someone tell me why I would get the below waning about > expireSessionsOnShutdown not being set > > WARNING [main] org.apache.tomcat.util.digester.SetPropertiesRule.begin Match > [Server/Service/Engine/Host/Cluster/Manager] failed to set property > [expireSessionsOnShutdown] to [false] > > I am using Tomcat 10.1.19 and trying to get clusting set up so session data > is not lost because of web app being deployed on two servers and service by a > load balancer > > Here is my server.xml snippet... > > > channelSendOptions="6"> > >className="org.apache.catalina.ha.session.BackupManager" > > expireSessionsOnShutdown="false" > > notifyListenersOnReplication="true" > > mapSendOptions="6"/> The expireSessionsOnShutdown attribute is only available for the DeltaManager, not the BackupManager. See: https://tomcat.apache.org/tomcat-10.1-doc/config/cluster-manager.html - Chuck CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you know the sender and you are sure the content is safe. Please report the message using the Report Message feature in your email client if you believe the email is suspicious. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 10 waning that expireSessionsOnShutdown is not set
> On Mar 21, 2024, at 14:23, Rick Noel wrote: > > Could someone tell me why I would get the below waning about > expireSessionsOnShutdown not being set > > WARNING [main] org.apache.tomcat.util.digester.SetPropertiesRule.begin Match > [Server/Service/Engine/Host/Cluster/Manager] failed to set property > [expireSessionsOnShutdown] to [false] > > I am using Tomcat 10.1.19 and trying to get clusting set up so session data > is not lost because of web app being deployed on two servers and service by a > load balancer > > Here is my server.xml snippet... > > > channelSendOptions="6"> > >className="org.apache.catalina.ha.session.BackupManager" > > expireSessionsOnShutdown="false" > > notifyListenersOnReplication="true" > > mapSendOptions="6"/> The expireSessionsOnShutdown attribute is only available for the DeltaManager, not the BackupManager. See: https://tomcat.apache.org/tomcat-10.1-doc/config/cluster-manager.html - Chuck
Re: HttpSession tracking
We receive the sessionWillPassivate and sessionDidActivate callbacks on startup. Odd that you are not. That's how we achieve the same. On Thu, Mar 21, 2024 at 3:25 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > All, > > After having written a solution using JMX to do something like this, I'd > like to make it cleaner and I'm not sure it's entirely possible using > just Servlet APIs. > > I'd like to be able to track every HttpSession for the application. > > for admin purposes, I'd like to be able to analyze: > > 1. The total number of sessions > > 2. The number of sessions which represent a logged-in user vs a > crawler-session or someone who visited the home-page and got a session > but never logged-in > > 3. Checking-out some specific roles of those logged-in users e.g. > end-user, staff, admin > > 4. Be able to kill a session at will. For example "chris is already > logged-in, kill his old session and let the new login remain" > > I started with the obvious HttpSessionListener + > HttpSessionActivationListener, but I tried this experiment and it didn't > turn out how I expected: > > 1. Start the application and hit the front page > > -> I get a call to HttpSessionListener.sessionCreated (expected) > > 2. Login > > 3. Logout > > -> I get a call to HttpSessionListener.sessionDestroyed (expected) > -> I get a call to HttpSessionListener.sessionCreated (expected) > (this second one happens because our home-page creates a session) > > 4. Login again > > 5. Stop Tomcat > > -> No calls to anything I can see > > 6. Start Tomcat > > -> No calls to anything I can see > > 7. Access a protected page > > -> Access is allowed; I'm still logged-in. > > When Tomcat shuts-down, it's saving the sessions using local > persistence[1]. When the application comes back up, all those sessions > are restored from the disk. > > When my HttpSeessionListener starts, it's empty and doesn't know about > any sessions. Tomcat doesn't notify it that any sessions are coming from > that storage. > > I would have expected calls to > HttpSessionActivationListener.sessionWillPassivate and > HttpSessionActivationListener.sessionDidActivate. > > Do I have unrealistic expectations? Is there a way to capture these > events so my in-memory session-watcher/manager is able to have an > accurate view of what Tomcat can see? > > Thanks, > -chris > > [1] > > https://tomcat.apache.org/tomcat-8.5-doc/config/manager.html#Persistence_Across_Restarts > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
HttpSession tracking
All, After having written a solution using JMX to do something like this, I'd like to make it cleaner and I'm not sure it's entirely possible using just Servlet APIs. I'd like to be able to track every HttpSession for the application. for admin purposes, I'd like to be able to analyze: 1. The total number of sessions 2. The number of sessions which represent a logged-in user vs a crawler-session or someone who visited the home-page and got a session but never logged-in 3. Checking-out some specific roles of those logged-in users e.g. end-user, staff, admin 4. Be able to kill a session at will. For example "chris is already logged-in, kill his old session and let the new login remain" I started with the obvious HttpSessionListener + HttpSessionActivationListener, but I tried this experiment and it didn't turn out how I expected: 1. Start the application and hit the front page -> I get a call to HttpSessionListener.sessionCreated (expected) 2. Login 3. Logout -> I get a call to HttpSessionListener.sessionDestroyed (expected) -> I get a call to HttpSessionListener.sessionCreated (expected) (this second one happens because our home-page creates a session) 4. Login again 5. Stop Tomcat -> No calls to anything I can see 6. Start Tomcat -> No calls to anything I can see 7. Access a protected page -> Access is allowed; I'm still logged-in. When Tomcat shuts-down, it's saving the sessions using local persistence[1]. When the application comes back up, all those sessions are restored from the disk. When my HttpSeessionListener starts, it's empty and doesn't know about any sessions. Tomcat doesn't notify it that any sessions are coming from that storage. I would have expected calls to HttpSessionActivationListener.sessionWillPassivate and HttpSessionActivationListener.sessionDidActivate. Do I have unrealistic expectations? Is there a way to capture these events so my in-memory session-watcher/manager is able to have an accurate view of what Tomcat can see? Thanks, -chris [1] https://tomcat.apache.org/tomcat-8.5-doc/config/manager.html#Persistence_Across_Restarts - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 10 waning that expireSessionsOnShutdown is not set
Hello, Could someone tell me why I would get the below waning about expireSessionsOnShutdown not being set WARNING [main] org.apache.tomcat.util.digester.SetPropertiesRule.begin Match [Server/Service/Engine/Host/Cluster/Manager] failed to set property [expireSessionsOnShutdown] to [false] I am using Tomcat 10.1.19 and trying to get clusting set up so session data is not lost because of web app being deployed on two servers and service by a load balancer Here is my server.xml snippet... And in my application web.xml I have. the needed Rick Noel Systems Programmer | Westwood One rn...@westwoodone.com
Re: Memory leak in EncodingDetector?
Hi Chris
Personally I'd go with
XML_INPUT_FACTORY =
XMLInputFactory.newFactory(XMLInputFactory.class.getName(),
EncodingDetector.class.getClassLoader());
allowing me to place my own JAR in common/lib if I really want to (the
only scenario I can think of is an edge-case where there's a bug in
the JVM XMLInputFactory and no upgrade path is available, so I'd place
my own JAR in common/lib).
> I wonder if there really are any use-cases for applications wanting Tomcat to
> specify the XMLInputFactory *to be used for JSP*
That sounds pretty far-fetched. Our use case is simply that we deploy
frequently (several times a day) on a Tomcat 10.1 installation, and
have various reasons for not going down the Docker/container/FAT JAR
path. So, making sure we don't have memory leaks is relevant.
Simon
On Thu, Mar 21, 2024 at 1:44 PM Christopher Schultz
wrote:
>
> Simon,
>
> On 3/20/24 15:36, Simon Niederberger wrote:
> >> What if you create an empty jaxp.properties file and make it available to
> >> the common ClassLoader (e.g. in lib/empty-jaxp.jar:/jaxp.properties) --
> >> does that prevent the problem?
> >
> > I think that boils down to what I'm already doing with the system
> > property, getting to the FactoryFinder before it uses
> > findServiceProvider(). Haven't tried it, but I'm sure it would work.
>
> The difference is that Tomcat can ship it as a part of the distribution,
> while we shouldn't really be setting system properties like that. It
> might prevent, for example, applications using their own preferred
> implementation.
>
> > imho, Tomcat's EncodingDetector should init with either
> >
> > XML_INPUT_FACTORY = XMLInputFactory.newDefaultFactory();
> >
> > to just always use the JVM XMLInputFactory, or then
> >
> > XML_INPUT_FACTORY =
> > XMLInputFactory.newFactory(XMLInputFactory.class.getName(),
> > EncodingDetector.class.getClassLoader());
> >
> > to honor it's own classloader (maybe
> > EncodingDetector.class.getClassLoader() is the wrong approach,
> > basically something getTomcatCommonClassloader())
>
> Yeah, that's probably better than an empty properties file wrapped in a
> JAR file wrapped in an enigma.
>
> We also have the option of using the JreMemoryLeakPreventionListener for
> this. There are already some XML-related protections in there, though
> this one is not specifically there.
>
> Do you have a preferred technique for fixing this? All of those
> suggestions seem equally reasonable. I think I have a slight preference
> for passing the JSP compiler's ClassLoader in to the factory method:
>
>XML_INPUT_FACTORY =
> XMLInputFactory.newFactory(XMLInputFactory.class.getName(),
> EncodingDetector.class.getClassLoader());
>
> If you absolutey need to get your JSP compiler to have a custom
> XMLInputFactory, you can copy the JSP compiler into your application and
> it will use that ClassLoader instead.
>
> > What I just don't get is why there's so little online about others
> > havingEncodingDetector similar issues. Spring + libs like CXF or
> > jackson-dataformat-xml are common, both those libs have transitive
> > dependencies on woodstox-core. Throw in ehcache, also common, and your
> > webapp won't undeploy if it's the first webapp to load a JSP and thus
> > clinit EncodingDetector. Maybe the public has just given up on clean
> > undeploying.
>
> My guess is that most people don't really care too much about clean
> shutdowns of their applications. They either bring their applications up
> and down along with the whole JVM (either standalone or via Docker,
> etc.) or they use an embedded Tomcat where their own application hosts
> Tomcat and they start/stop that.
>
> Or they disable/ignore memory-leak detection log messages. *shrug*
>
> I wonder if there really are any use-cases for applications wanting
> Tomcat to specify the XMLInputFactory *to be used for JSP*. I suspect not.
>
> -chris
>
> > On Wed, Mar 20, 2024 at 7:01 PM Christopher Schultz
> > wrote:
> >>
> >> Simon,
> >>
> >> On 3/20/24 09:59, Simon Niederberger wrote:
> >>> The whole thing is caused by Maven dependencies which pull in
> >>> com.fasterxml.woodstox:woodstox-core. The WstxInputFactory has a
> >>>
> >>> @ServiceProvider(XMLInputFactory.class)
> >>>
> >>> annotation, where ServiceProvider is
> >>> org.ehcache.spi.service.ServiceProvider. I didn't manage to trace the
> >>> key code section, but I do find that the
> >>> javax.xml.stream.FactoryFinder then ends up finding WstxInputFactory
> >>> as registered service provider. As WstxInputFactory is not on the
> >>> common classpath (it's in WEB-INF/lib), I assume it's the webapp
> >>> classloader which is used. Below is the stacktrace where
> >>> EncodingDetector clinit happens (I defined a
> >>> ch.want.funnel.FunnelApp$DelegatingXMLInputFactory to get
> >>> stacktraces):
> >>>
> >>> Currently I'm setting
> >>>
> >>> System.setProperty("javax.xml.stream.XMLInputFactory",
> >>> "com.sun.xml.internal.stream.XMLInputFactoryImpl");
> >>> to get a
Re: Regression in mutual authentication in 9.0.86+?
On 21/03/2024 16:12, Amit Pande wrote:
Thank you Mark for your inputs.
Upon further debugging, it looks like the issue we ran into is also with the
reloading of SSL context.
Test execution sequence:
1. Add a trusted CA in Tomcat's trust store.
2. The SSL context is reloaded if any of the trust/key store has changes.
3. Perform a mutual client authentication using a client certificate signed by
the CA used in step 1.
Still a bit puzzled in such a case there was no SSL handshake failure at Tomcat
level but request made it to application and failed (due to empty
javax.servlet.request.X509Certificate).
It sounds like you have optional certificate verification enabled.
One follow-up question:
Are we planning to have an immediate 9.0.88 release, or it will be regular
cadence? Asking because the versions until 9.0.85 have vulnerabilities reported
and this regression might potentially block the upgrade to 9.0.86/87.
This fix will be picked up in the April release round.
Mark
Lastly, I wholeheartedly echo the gratitude many have expressed around the
awesome Tomcat leads.
Thanks,
Amit
-Original Message-
From: Mark Thomas
Sent: Monday, March 18, 2024 4:41 AM
To: users@tomcat.apache.org
Subject: Re: Regression in mutual authentication in 9.0.86+?
CAUTION: This email originated from outside the organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe. If you believe this is a phishing email, use the Report to
Cybersecurity icon in Outlook.
I've just tested 9.0.x and mutual TLS authentication appears to be working as
expected.
I suggest starting with testing a simple JSP that echoes that attribute and if
you still see the issue, provide us with your configuration. Note that the
issue may be related to the certs you are using so the configuration
information should include steps to recreate the TLS certs with keystore,
OpenSSL or similar.
On 15/03/2024 00:48, Amit Pande wrote:
Hello all,
I have upgraded the Tomcat version from 9.0.85 to 9.0.86 (and tried with 9.0.87
too).
Some of our tests which involve on mutual authentication ("certificateVerification =
optional") have started to fail.
In tests where the client does pass the certificate, I didn't see any SSL handshake
errors (with SSL handshake debugging enabled) but
"javax.servlet.request.X509Certificate" attribute wasn't set. This is the
attribute the application needs for further validations.
Have you confirmed that the certificate was sent from the client?
Could anyone please give pointers on how to debug this further?
Any code pointers where Tomcat sets this
"javax.servlet.request.X509Certificate" attribute?
git clone
grep
Also, one more question - with optional certificate verification, the
connection doesn't fail if certificate is not passed. But connection will fail
if SSL handshake fails when a certificate is passed by client, is that correct
understanding?
Yes, that is what I would expect.
Mark
-
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
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Regression in mutual authentication in 9.0.86+?
Thank you Mark for your inputs.
Upon further debugging, it looks like the issue we ran into is also with the
reloading of SSL context.
Test execution sequence:
1. Add a trusted CA in Tomcat's trust store.
2. The SSL context is reloaded if any of the trust/key store has changes.
3. Perform a mutual client authentication using a client certificate signed by
the CA used in step 1.
Still a bit puzzled in such a case there was no SSL handshake failure at Tomcat
level but request made it to application and failed (due to empty
javax.servlet.request.X509Certificate).
One follow-up question:
Are we planning to have an immediate 9.0.88 release, or it will be regular
cadence? Asking because the versions until 9.0.85 have vulnerabilities reported
and this regression might potentially block the upgrade to 9.0.86/87.
Lastly, I wholeheartedly echo the gratitude many have expressed around the
awesome Tomcat leads.
Thanks,
Amit
-Original Message-
From: Mark Thomas
Sent: Monday, March 18, 2024 4:41 AM
To: users@tomcat.apache.org
Subject: Re: Regression in mutual authentication in 9.0.86+?
CAUTION: This email originated from outside the organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe. If you believe this is a phishing email, use the Report to
Cybersecurity icon in Outlook.
I've just tested 9.0.x and mutual TLS authentication appears to be working as
expected.
I suggest starting with testing a simple JSP that echoes that attribute and if
you still see the issue, provide us with your configuration. Note that the
issue may be related to the certs you are using so the configuration
information should include steps to recreate the TLS certs with keystore,
OpenSSL or similar.
On 15/03/2024 00:48, Amit Pande wrote:
> Hello all,
>
> I have upgraded the Tomcat version from 9.0.85 to 9.0.86 (and tried with
> 9.0.87 too).
>
> Some of our tests which involve on mutual authentication
> ("certificateVerification = optional") have started to fail.
>
> In tests where the client does pass the certificate, I didn't see any SSL
> handshake errors (with SSL handshake debugging enabled) but
> "javax.servlet.request.X509Certificate" attribute wasn't set. This is the
> attribute the application needs for further validations.
Have you confirmed that the certificate was sent from the client?
> Could anyone please give pointers on how to debug this further?
>
> Any code pointers where Tomcat sets this
> "javax.servlet.request.X509Certificate" attribute?
git clone
grep
> Also, one more question - with optional certificate verification, the
> connection doesn't fail if certificate is not passed. But connection will
> fail if SSL handshake fails when a certificate is passed by client, is that
> correct understanding?
Yes, that is what I would expect.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Use JAVA/CATALINA_OPTS arguments in server.xml
чт, 21 мар. 2024 г. в 17:04, Manak Bisht : > > I have not defined its value. It works fine if I do, however, I am > expecting it to use the default instead. How old is your version of Tomcat? This feature dates back to spring of year 2020 https://github.com/apache/tomcat/commit/90b8ff2f330973bbe54dbbe3d702b3111bb781fc https://github.com/apache/tomcat/commit/6f356df24241db9f655c8adb0c51aea95a2ab05d Maybe you can test it first in some other more easily observable place, e.g. in web.xml? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Use JAVA/CATALINA_OPTS arguments in server.xml
Manak, On 3/21/24 09:57, Manak Bisht wrote: On Thu, 21 Mar 2024, 19:18 Christopher Schultz, < ch...@christopherschultz.net> wrote: Manak, On 3/21/24 05:38, Manak Bisht wrote: Thanks, Chuck! This works for defining the port but does not work for the host. Using either of the above throws the following error, 21-Mar-2024 15:04:58.185 SEVERE [GroupChannel-Heartbeat-1] org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.memberAlive Unable to perform failure detection check, assuming member down. java.net.UnknownHostException: addr is of illegal length at java.net.InetAddress.getByAddress(InetAddress.java:1042) at java.net.InetAddress.getByAddress(InetAddress.java:1439) at org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.memberAlive(TcpFailureDetector.java:316) at org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.memberAlive(TcpFailureDetector.java:305) at org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.performForcedCheck(TcpFailureDetector.java:224) at org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.checkMembers(TcpFailureDetector.java:213) at org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor.sendPing(TcpPingInterceptor.java:132) at org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor.heartbeat(TcpPingInterceptor.java:99) at org.apache.catalina.tribes.group.ChannelInterceptorBase.heartbeat(ChannelInterceptorBase.java:98) at org.apache.catalina.tribes.group.GroupChannel.heartbeat(GroupChannel.java:154) at org.apache.catalina.tribes.group.GroupChannel$HeartbeatThread.run(GroupChannel.java:692) What is the value of the system property "tomcat.member"? > I have not defined its value. It works fine if I do, however, I am > expecting it to use the default instead. Yes, I agree. Can you run under a debugger and observe the value being set? Or recompile it with a log statement? I don't see much logging in that class, and I'm not familiar enough with the clustering code to know where best to enable logging to see the effective configuration. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Use JAVA/CATALINA_OPTS arguments in server.xml
I have not defined its value. It works fine if I do, however, I am
expecting it to use the default instead.
Sincerely,
Manak Bisht
On Thu, 21 Mar 2024, 19:18 Christopher Schultz, <
ch...@christopherschultz.net> wrote:
> Manak,
>
> On 3/21/24 05:38, Manak Bisht wrote:
> > Thanks, Chuck!
> > This works for defining the port but does not work for the host.
> >
> > > port="4000" host="${tomcat.member:-localhost}"/>
> > > port="4000" host="${tomcat.member:-127.0.0.1}"/>
> >
> > Using either of the above throws the following error,
> >
> > 21-Mar-2024 15:04:58.185 SEVERE [GroupChannel-Heartbeat-1]
> >
> org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.memberAlive
> Unable to perform failure detection check, assuming member down.
> > java.net.UnknownHostException: addr is of illegal length
> > at java.net.InetAddress.getByAddress(InetAddress.java:1042)
> > at java.net.InetAddress.getByAddress(InetAddress.java:1439)
> > at
> >
> org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.memberAlive(TcpFailureDetector.java:316)
> > at
> >
> org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.memberAlive(TcpFailureDetector.java:305)
> > at
> >
> org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.performForcedCheck(TcpFailureDetector.java:224)
> > at
> >
> org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.checkMembers(TcpFailureDetector.java:213)
> > at
> >
> org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor.sendPing(TcpPingInterceptor.java:132)
> > at
> >
> org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor.heartbeat(TcpPingInterceptor.java:99)
> > at
> >
> org.apache.catalina.tribes.group.ChannelInterceptorBase.heartbeat(ChannelInterceptorBase.java:98)
> > at
> >
> org.apache.catalina.tribes.group.GroupChannel.heartbeat(GroupChannel.java:154)
> > at
> >
> org.apache.catalina.tribes.group.GroupChannel$HeartbeatThread.run(GroupChannel.java:692)
>
> What is the value of the system property "tomcat.member"?
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Re: Tomcat Internal Architect for JSP compilation?
Subudh, On 3/21/24 07:32, Subodh Joshi wrote: Expert, Recently i came across a issue and i was getting no clue what was going on wrong with the Application. So here is the issue , we were getting following issue in our web application(Springboot+Embedded Tomcat) which is deployed into Linux machine java.lang.ClassNotFoundException: org.apache.jsp.WEB_002dINF.jsp.ImportTab_jsp at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:445) at org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:129) at org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:58) at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:151) at org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:189) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:410) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:380) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:328) at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:205) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:174) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:110) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:174) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149) at org.springframework.web.filter.CompositeFilter$VirtualFilterChain.doFilter(CompositeFilter.java:108) at org.springframework.security.web.FilterChainProxy.lambda$doFilterInternal$3(FilterChainProxy.java:231) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:365) at org.springframework.security.web.access.intercept.AuthorizationFilter.doFilter(AuthorizationFilter.java:100) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374) at org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:126) at org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:120) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374) at org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:100) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374) at org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:179) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374) at org.springframework.security.web.savedrequest.RequestCacheAwareFilter.doFilter(RequestCacheAwareFilter.java:63) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374) at com.comptel.catalog.support.filter.OperationClientRestFilter.doFilter(OperationClientRestFilter.java:86) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374) at com.comptel.catalog.support.filter.JwtSecurityChainFilter.doFilter(JwtSecurityChainFilter.java:100) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374) but how to reproduce this issue we were not able to get any clue. But Recently i got to know how to reproduce this issue 1- Start the web-application. 2- Tomcat will create a directory under /tmp/tomcat.*/.././.. 3- Now access web-application through browser. 4- But dont access all JSP pages. 5- Suppose application have A,B,C,D.jsp pages . 6- User accesses A,B.jsp only 7- Now user or any cron job deleted /tmp/tomcat directory Don't do that. 8- Now user click on C.jsp it is throwing above given exception. 9- Now click on D.jsp it will work fine as tomcat will create /tmp/tomcat . directory again. 10. But C.jsp which was failed with 500 error will never come upto the time tomcat will not start. Can someone please explain how tomcat works here and why it throws an exception and wont allow that jsp page
Re: Use JAVA/CATALINA_OPTS arguments in server.xml
Manak,
On 3/21/24 05:38, Manak Bisht wrote:
Thanks, Chuck!
This works for defining the port but does not work for the host.
port="4000" host="${tomcat.member:-localhost}"/>
port="4000" host="${tomcat.member:-127.0.0.1}"/>
Using either of the above throws the following error,
21-Mar-2024 15:04:58.185 SEVERE [GroupChannel-Heartbeat-1]
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.memberAlive Unable to perform failure detection check, assuming member down.
java.net.UnknownHostException: addr is of illegal length
at java.net.InetAddress.getByAddress(InetAddress.java:1042)
at java.net.InetAddress.getByAddress(InetAddress.java:1439)
at
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.memberAlive(TcpFailureDetector.java:316)
at
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.memberAlive(TcpFailureDetector.java:305)
at
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.performForcedCheck(TcpFailureDetector.java:224)
at
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.checkMembers(TcpFailureDetector.java:213)
at
org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor.sendPing(TcpPingInterceptor.java:132)
at
org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor.heartbeat(TcpPingInterceptor.java:99)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.heartbeat(ChannelInterceptorBase.java:98)
at
org.apache.catalina.tribes.group.GroupChannel.heartbeat(GroupChannel.java:154)
at
org.apache.catalina.tribes.group.GroupChannel$HeartbeatThread.run(GroupChannel.java:692)
What is the value of the system property "tomcat.member"?
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Memory leak in EncodingDetector?
Simon,
On 3/20/24 15:36, Simon Niederberger wrote:
What if you create an empty jaxp.properties file and make it available to the
common ClassLoader (e.g. in lib/empty-jaxp.jar:/jaxp.properties) -- does that
prevent the problem?
>
I think that boils down to what I'm already doing with the system
property, getting to the FactoryFinder before it uses
findServiceProvider(). Haven't tried it, but I'm sure it would work.
The difference is that Tomcat can ship it as a part of the distribution,
while we shouldn't really be setting system properties like that. It
might prevent, for example, applications using their own preferred
implementation.
imho, Tomcat's EncodingDetector should init with either
XML_INPUT_FACTORY = XMLInputFactory.newDefaultFactory();
to just always use the JVM XMLInputFactory, or then
XML_INPUT_FACTORY =
XMLInputFactory.newFactory(XMLInputFactory.class.getName(),
EncodingDetector.class.getClassLoader());
to honor it's own classloader (maybe
EncodingDetector.class.getClassLoader() is the wrong approach,
basically something getTomcatCommonClassloader())
Yeah, that's probably better than an empty properties file wrapped in a
JAR file wrapped in an enigma.
We also have the option of using the JreMemoryLeakPreventionListener for
this. There are already some XML-related protections in there, though
this one is not specifically there.
Do you have a preferred technique for fixing this? All of those
suggestions seem equally reasonable. I think I have a slight preference
for passing the JSP compiler's ClassLoader in to the factory method:
XML_INPUT_FACTORY =
XMLInputFactory.newFactory(XMLInputFactory.class.getName(),
EncodingDetector.class.getClassLoader());
If you absolutey need to get your JSP compiler to have a custom
XMLInputFactory, you can copy the JSP compiler into your application and
it will use that ClassLoader instead.
What I just don't get is why there's so little online about others
havingEncodingDetector similar issues. Spring + libs like CXF or
jackson-dataformat-xml are common, both those libs have transitive
dependencies on woodstox-core. Throw in ehcache, also common, and your
webapp won't undeploy if it's the first webapp to load a JSP and thus
clinit EncodingDetector. Maybe the public has just given up on clean
undeploying.
My guess is that most people don't really care too much about clean
shutdowns of their applications. They either bring their applications up
and down along with the whole JVM (either standalone or via Docker,
etc.) or they use an embedded Tomcat where their own application hosts
Tomcat and they start/stop that.
Or they disable/ignore memory-leak detection log messages. *shrug*
I wonder if there really are any use-cases for applications wanting
Tomcat to specify the XMLInputFactory *to be used for JSP*. I suspect not.
-chris
On Wed, Mar 20, 2024 at 7:01 PM Christopher Schultz
wrote:
Simon,
On 3/20/24 09:59, Simon Niederberger wrote:
The whole thing is caused by Maven dependencies which pull in
com.fasterxml.woodstox:woodstox-core. The WstxInputFactory has a
@ServiceProvider(XMLInputFactory.class)
annotation, where ServiceProvider is
org.ehcache.spi.service.ServiceProvider. I didn't manage to trace the
key code section, but I do find that the
javax.xml.stream.FactoryFinder then ends up finding WstxInputFactory
as registered service provider. As WstxInputFactory is not on the
common classpath (it's in WEB-INF/lib), I assume it's the webapp
classloader which is used. Below is the stacktrace where
EncodingDetector clinit happens (I defined a
ch.want.funnel.FunnelApp$DelegatingXMLInputFactory to get
stacktraces):
Currently I'm setting
System.setProperty("javax.xml.stream.XMLInputFactory",
"com.sun.xml.internal.stream.XMLInputFactoryImpl");
to get a XMLInputFactory implementation which is on the common
loader's classpath, so the webapp can be undeployed cleanly.
So this works, right?
What if you create an empty jaxp.properties file and make it available
to the common ClassLoader (e.g. in lib/empty-jaxp.jar:/jaxp.properties)
-- does that prevent the problem?
I'm wondering if Tomcat should simply ship with an empty jaxp.properties
file to prevent this kind of thing from happening by default. If someone
wants to bundle an XMLInputFactory into Tomcat's lib/ directory and use
that, they could remove this file.
BTW that's an impressive stack trace. ;)
-chris
java.lang.RuntimeException: Stracktrace for tracking XMLInputFactory creation
at
ch.want.funnel.FunnelApp$DelegatingXMLInputFactory.(FunnelApp.java:107)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
Tomcat Internal Architect for JSP compilation?
Expert, Recently i came across a issue and i was getting no clue what was going on wrong with the Application. So here is the issue , we were getting following issue in our web application(Springboot+Embedded Tomcat) which is deployed into Linux machine java.lang.ClassNotFoundException: > org.apache.jsp.WEB_002dINF.jsp.ImportTab_jsp > at > java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:445) > at > org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:129) > at > org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:58) > at > org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:151) > at > org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:189) > at > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:410) > at > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:380) > at > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:328) > at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:205) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149) > at > org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:174) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149) > at > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:110) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:174) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149) > at > org.springframework.web.filter.CompositeFilter$VirtualFilterChain.doFilter(CompositeFilter.java:108) > at > org.springframework.security.web.FilterChainProxy.lambda$doFilterInternal$3(FilterChainProxy.java:231) > at > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:365) > at > org.springframework.security.web.access.intercept.AuthorizationFilter.doFilter(AuthorizationFilter.java:100) > at > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374) > at > org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:126) > at > org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:120) > at > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374) > at > org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:100) > at > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374) > at > org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:179) > at > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374) > at > org.springframework.security.web.savedrequest.RequestCacheAwareFilter.doFilter(RequestCacheAwareFilter.java:63) > at > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374) > at > com.comptel.catalog.support.filter.OperationClientRestFilter.doFilter(OperationClientRestFilter.java:86) > at > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374) > at > com.comptel.catalog.support.filter.JwtSecurityChainFilter.doFilter(JwtSecurityChainFilter.java:100) > at > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374) > but how to reproduce this issue we were not able to get any clue. But Recently i got to know how to reproduce this issue 1- Start the web-application. 2- Tomcat will create a directory under /tmp/tomcat.*/.././.. 3- Now access web-application through browser. 4- But dont access all JSP pages. 5- Suppose application have A,B,C,D.jsp pages . 6- User accesses A,B.jsp only 7- Now user or any cron job deleted /tmp/tomcat directory 8- Now user click on C.jsp it is throwing above given exception. 9- Now click on D.jsp it will work fine as tomcat will create /tmp/tomcat . directory again. 10. But C.jsp which was failed with 500 error will never come upto the time tomcat will not start. Can someone please explain how tomcat works here and why it throws an
Re: Use JAVA/CATALINA_OPTS arguments in server.xml
Thanks, Chuck! This works for defining the port but does not work for the host. Using either of the above throws the following error, 21-Mar-2024 15:04:58.185 SEVERE [GroupChannel-Heartbeat-1] org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.memberAlive Unable to perform failure detection check, assuming member down. java.net.UnknownHostException: addr is of illegal length at java.net.InetAddress.getByAddress(InetAddress.java:1042) at java.net.InetAddress.getByAddress(InetAddress.java:1439) at org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.memberAlive(TcpFailureDetector.java:316) at org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.memberAlive(TcpFailureDetector.java:305) at org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.performForcedCheck(TcpFailureDetector.java:224) at org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.checkMembers(TcpFailureDetector.java:213) at org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor.sendPing(TcpPingInterceptor.java:132) at org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor.heartbeat(TcpPingInterceptor.java:99) at org.apache.catalina.tribes.group.ChannelInterceptorBase.heartbeat(ChannelInterceptorBase.java:98) at org.apache.catalina.tribes.group.GroupChannel.heartbeat(GroupChannel.java:154) at org.apache.catalina.tribes.group.GroupChannel$HeartbeatThread.run(GroupChannel.java:692) Sincerely, Manak Bisht
