Re: Tomcat log warnings for connection parameter limits?

[Baron Fujimoto]

>From our perspective, it needn't be super timely. It would be more for
forensic confirmation that there's something we should consider. I think a
hysteresis behavior would be compatible with this.

On Mon, Apr 15, 2024 at 12:00 AM Mark Thomas  wrote:

> On 11/04/2024 21:28, Baron Fujimoto wrote> I was thinking it would be
> something that would be left on in a live> system. We can set these
> parameters, so it would be useful to know if we
> > were hitting the set limits.
>
> For the connection limit:
>
> How timely do you need the information to be? It is much easier to add a
> check when the connection is closed since a) it returns the current
> count and b) we are already checking the return value for mis-counting.
>
> For the thread limit:
>
> We have a couple of options here. (We use a custom queue which
> effectively changes the way threads in the pool re used.) The simplest
> is probably to add log in TaskQueue.offer() if all threads are currently
> being used.
>
> > I'm not sure I fully grasp how this additional logging presents a
> > significant incremental DOS risk. I mean, if an attacker is flooding you
> > with enough traffic or connections where this becomes an issue, aren't
> you
> > already logging various aspects of the attempts anyway (e.g., access
> logs,
> > etc)? At that point aren't your logs already being filled anyway?
>
> It is an area we need to be careful with. Log messages that include
> exceptions are of greatest concern since they are relatively expensive
> to generate. If an invalid HTTP message triggers a log message with an
> exception (it does, but only when configured for debug logging) then
> there is a degree of DoS risk there.
>
> Access logs are a special case and one that we have taken care to try
> and optimise. Still, if you want to make a performance test look good
> turning off access logging is one of the first things to do (and of
> course results in totally meaningless results that don't reflect real
> world usage).
>
> I think the concern Chris was trying to express (although I'm sure he'll
> correct me if I am wrong) is that when these limits are reached there is
> a risk of a lot of log messages being generated and that can cause
> issues both from a performance issue and from just filling the logs with
> the same message over and over again.
>
> I think what we would need is some form of hysteresis. Log a message
> when the limit is reached, log another message when usage falls below
> 80%? of the limit. That way, administrators see the peaks in usage but
> aren't inundated with log messages.
>
> My only concern is that at least some this code is going to run for
> every single request. It needs to be efficient. We should measure the
> impact of adding this code before we decide on whether to include it.
>
> Mark
>
>
> >
> > On Thu, Apr 11, 2024 at 1:44 AM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> >> Baron,
> >>
> >> On 4/9/24 16:33, Baron Fujimoto wrote:
> >>> I'm investigating occasional 503 errors for our CAS service running in
> a
> >>> Tomcat 10.1.x container. The 503s appear to correlate with some traffic
> >>> spikes at the same time.
> >>>
> >>> The connector is configured as follows:
> >>>
> >>>>>>  port="8443"
> >>>  maxThreads="2500"
> >>>  maxConnections="5"
> >>>  maxPostSize="10"
> >>>  maxParameterCount="1000"
> >>>  scheme="https" secure="true"
> >>>  SSLEnabled="true"
> >>>  >
> >>>
> >>> Can Tomcat log info such as when the maxThreads or maxConnections
> limits
> >>> are reached? I'm basically trying to see if there is a good way to
> >>> more definitively determine what may have caused the 503s and what may
> be
> >>> feasible to mitigate them.
> >>
> >> Are you thinking of a debugging feature or something to be left-on for a
> >> live production system?
> >>
> >> Such logging might be considered a DOS vector for a live system: you can
> >> fill the logs by asking lots of trivial requests.
> >>
> >> -chris
> >>
> >> -
> >> 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
>
>

-- 
Baron Fujimoto  ::: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum descendus pantorum

RE: Question on the ErrorReportValve

[Mcalexander, Jon J.]

Thanks Chris.

Yes, it’s probably academic, but I was mainly looking for opinions from the 
true “experts” out there. 😊

When I get free time to do so, I’ll play around with it.

Thanks,

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.

From: Christopher Schultz 
Sent: Monday, April 15, 2024 12:26 PM
To: Tomcat Users List ; Mcalexander, Jon J. 

Subject: Re: Question on the ErrorReportValve

Jon, On 4/15/24 12: 36, Mcalexander, Jon J. wrote: > Quick question on the 
ErrorReportValve and location within the server. xml file. I know that 
typically this would be inside the  element, but if you have 
Multiple


Jon,



On 4/15/24 12:36, Mcalexander, Jon J. wrote:

> Quick question on the ErrorReportValve and location within the server.xml 
> file. I know that typically this would be inside the  
> element, but if you have Multiple  elements, do you add the valve to 
> each Host section, or can it be placed at the Engine or even Server level?



The configuration reference doesn't specify, but the Javadoc says it

"should be" used in  but "should work in ".



I would think you'd want to separately configure them for each ,

anyway.



Is this an academic question? It seems like a very easy think to just

try out and see what happens. :)



-chris



-

To unsubscribe, e-mail: 
users-unsubscr...@tomcat.apache.org

For additional commands, e-mail: 
users-h...@tomcat.apache.org

Re: Retrieve server.built, server.number

[Christopher Schultz]

On 4/11/24 10:59, Mark Thomas wrote:



On 11/04/2024 15:49, Bill Stewart wrote:

On Wed, Apr 10, 2024 at 2:14 PM Mark Thomas wrote:


... and it might represent an information leakage vulnerability in your

application. Be Careful.


Shall we start the flame war now on whether exposing the current version
   you are running represents a valid vulnerability or if hiding it is
just security by obscurity? Or do you want to save it for Bratislava?

:)

More seriously, your time is likely to be better spent (in my view)
keeping your Tomcat installations up to date with the latest releases
than it is ensuring that you hide the version number.



The amusing thing (or irritating thing, depending on your point of 
view) is

when a large organization uses a vulnerability scanner and a Tomcat
instance gets flagged as a security risk because it reveals its version
number in the 404 error page. (Yes, this is a real scenario.)


At least it is an easy fix: showServerInfo="false"

assuming that is going to be easier than convincing folks that exposing 
the version number isn't an issue.


+1

Revealing the server version isn't a vulnerability, period. But if your 
operational practices are such that you leave old versions that have 
known published vulnerabilities running in production, then you have 
broken operational practices that need to be fixed.


IMHO, revealing your server version number may be an incentive to keep 
your software up-to-date.


On the flip side, hiding your server's version number is *not a valid 
security control*. If you are advertising your server version number it 
only increases the likelihood of someone identifying your site as 
potentially vulnerable /if you have an old version/.


If a zero-day is published against Tomcat, anyone who wants to attack 
Tomcat-based services will attack anyone they want since the 
vulnerability is likely to affect both old-version and new-version 
deployments.


But well-known vulnerabilities from past versions may make it attractive 
for miscreants to use something like Shodan to search for servers 
running particularly old versions to attack them.


So... if you want to reveal your server version, feel free to do so. But 
make sure you stay up-to-date. You should always stay up-to-date. The 
policy of the Apache Tomcat Security Team is to release security-related 
patches with announcements /coming later/. So any release make be a 
security-related release. You won't know until afterward whether or not 
it's an "important" update.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Question on the ErrorReportValve

[Christopher Schultz]

Jon,

On 4/15/24 12:36, Mcalexander, Jon J. wrote:

Quick question on the ErrorReportValve and location within the server.xml file. I know that 
typically this would be inside the  element, but if you have Multiple 
 elements, do you add the valve to each Host section, or can it be placed at the 
Engine or even Server level?


The configuration reference doesn't specify, but the Javadoc says it 
"should be" used in  but "should work in ".


I would think you'd want to separately configure them for each , 
anyway.


Is this an academic question? It seems like a very easy think to just 
try out and see what happens. :)


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Question on the ErrorReportValve

[Mcalexander, Jon J.]

Hi all!
Quick question on the ErrorReportValve and location within the server.xml file. 
I know that typically this would be inside the  element, but if 
you have Multiple  elements, do you add the valve to each Host section, 
or can it be placed at the Engine or even Server level?

Thank you,

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.

Re: [EXT]Re: .intermittent InvocationTargetException errors

[Christopher Schultz]

Rick,

On 4/15/24 11:29, Rick Noel wrote:

The complete trace.

java.lang.reflect.InvocationTargetException
 at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
 at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.base/java.lang.reflect.Method.invoke(Method.java:568)
 at com.radiovoodoo.display.EvalExpr.evalIdentifier(EvalExpr.java:317)
 at com.radiovoodoo.display.EvalExpr.eval(EvalExpr.java:57)
 at com.radiovoodoo.display.EvalExpr.eval(EvalExpr.java:30)
 at com.radiovoodoo.display.Expr.evaluate(Expr.java:370)
 at com.radiovoodoo.display.PropertyTag.evaluate(PropertyTag.java:102)
 at com.radiovoodoo.display.PropertyTag.doStartTag(PropertyTag.java:55)
 at 
org.apache.jsp.services.system.contesting.contest_005fschedule_005fedit_jsp._jspx_meth_ww_005fproperty_005f5(contest_005fschedule_005fedit_jsp.java:6193)
 at 
org.apache.jsp.services.system.contesting.contest_005fschedule_005fedit_jsp._jspService(contest_005fschedule_005fedit_jsp.java:1299)
 at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
 at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658)
 at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:456)
 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)


The compiler is working. Whatever RadioVoodoo is is causing this error. 
I can see that the JSP compiler has finished because the call stack 
includes 
org.apache.jsp.services.system.contesting.contest_005fschedule_005fedit_jsp._jspService 
which means your services/system/contesting/contest-schedule-edit.jsp 
has been compiled successfully.


RadioVoodoo appears to be a JSP tag library and I'm guessing that it's 
being invoked to perform some kind of expression evaluation and THAT is 
failing.


You might need to reach out to the RadioVoodoo people to find out what's 
happening...



Caused by: java.lang.NullPointerException: Cannot invoke 
"java.util.TimeZone.getDisplayName()" because "this.customerTimeZone" is null
 at 
com.radiovoodoo.action.station.ContestManager.getCustomerTimeZoneDisplayName(ContestManager.java:1195)
 ... 51 more


Well, that tells you what is really happening: you have a null reference 
and you are trying to make a call on it. RadioVoodoo is allowing you to 
try to invoke a method on a null reference and getting an NPE for its 
trouble. The rest of the details are below:



Apr 15, 2024 11:26:51 AM com.radiovoodoo.util.Log log
SEVERE:
 Exception:  java.lang.NullPointerException: Cannot invoke 
"java.util.TimeZone.getDisplayName()" because "this.customerTimeZone" is null
 Stack Trace follows:
 java.lang.NullPointerException: Cannot invoke 
"java.util.TimeZone.getDisplayName()" because "this.customerTimeZone" is null
 at 
com.radiovoodoo.action.station.ContestManager.getCustomerTimeZoneDisplayName(ContestManager.java:1195)
 at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
 at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.base/java.lang.reflect.Method.invoke(Method.java:568)
 at com.radiovoodoo.display.EvalExpr.evalIdentifier(EvalExpr.java:317)
 at com.radiovoodoo.display.EvalExpr.eval(EvalExpr.java:57)
 at com.radiovoodoo.display.EvalExpr.eval(EvalExpr.java:30)
 at com.radiovoodoo.display.Expr.evaluate(Expr.java:370)
 at com.radiovoodoo.display.PropertyTag.evaluate(PropertyTag.java:102)
 at com.radiovoodoo.display.PropertyTag.doStartTag(PropertyTag.java:55)
 at 
org.apache.jsp.services.system.contesting.contest_005fschedule_005fedit_jsp._jspx_meth_ww_005fproperty_005f5(contest_005fschedule_005fedit_jsp.java:6193)
 at 
org.apache.jsp.services.system.contesting.contest_005fschedule_005fedit_jsp._jspService(contest_005fschedule_005fedit_jsp.java:1299)
 at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
 at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658)
 at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:456)
 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)
  

RE: [EXT]Re: .intermittent InvocationTargetException errors

[John.E.Gregg]

The NullPointerException is the real problem.


From: Rick Noel 
Sent: Monday, April 15, 2024 10:30 AM
To: Tomcat Users List 
Subject: RE: [EXT]Re: .intermittent InvocationTargetException errors

The complete trace. . . . . . . . . java. lang. reflect. 
InvocationTargetException at java. base/jdk. internal. reflect. 
NativeMethodAccessorImpl. invoke0(Native Method) at java. base/jdk. internal. 
reflect. NativeMethodAccessorImpl. invoke(NativeMethodAccessorImpl. java: 77)


The complete trace.



java.lang.reflect.InvocationTargetException

at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)

at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.base/java.lang.reflect.Method.invoke(Method.java:568)

at com.radiovoodoo.display.EvalExpr.evalIdentifier(EvalExpr.java:317)

at com.radiovoodoo.display.EvalExpr.eval(EvalExpr.java:57)

at com.radiovoodoo.display.EvalExpr.eval(EvalExpr.java:30)

at com.radiovoodoo.display.Expr.evaluate(Expr.java:370)

at com.radiovoodoo.display.PropertyTag.evaluate(PropertyTag.java:102)

at com.radiovoodoo.display.PropertyTag.doStartTag(PropertyTag.java:55)

at 
org.apache.jsp.services.system.contesting.contest_005fschedule_005fedit_jsp._jspx_meth_ww_005fproperty_005f5(contest_005fschedule_005fedit_jsp.java:6193)

at 
org.apache.jsp.services.system.contesting.contest_005fschedule_005fedit_jsp._jspService(contest_005fschedule_005fedit_jsp.java:1299)

at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)

at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658)

at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:456)

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:206)

at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:150)

at 
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)

at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:175)

at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:150)

at 
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:653)

at 
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:419)

at 
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:340)

at 
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:277)

at 
com.radiovoodoo.action.ServletDispatcher.service(ServletDispatcher.java:177)

at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658)

at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:206)

at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:150)

at 
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)

at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:175)

at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:150)

at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:167)

at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:90)

at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)

at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:115)

at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:93)

at 
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:673)

at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)

at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)

at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:391)

at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:63)

at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:896)

at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1736)

at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorB

RE: [EXT]Re: .intermittent InvocationTargetException errors

[Rick Noel]

The complete trace.

java.lang.reflect.InvocationTargetException
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at com.radiovoodoo.display.EvalExpr.evalIdentifier(EvalExpr.java:317)
at com.radiovoodoo.display.EvalExpr.eval(EvalExpr.java:57)
at com.radiovoodoo.display.EvalExpr.eval(EvalExpr.java:30)
at com.radiovoodoo.display.Expr.evaluate(Expr.java:370)
at com.radiovoodoo.display.PropertyTag.evaluate(PropertyTag.java:102)
at com.radiovoodoo.display.PropertyTag.doStartTag(PropertyTag.java:55)
at 
org.apache.jsp.services.system.contesting.contest_005fschedule_005fedit_jsp._jspx_meth_ww_005fproperty_005f5(contest_005fschedule_005fedit_jsp.java:6193)
at 
org.apache.jsp.services.system.contesting.contest_005fschedule_005fedit_jsp._jspService(contest_005fschedule_005fedit_jsp.java:1299)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658)
at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:456)
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:206)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:150)
at 
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:175)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:150)
at 
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:653)
at 
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:419)
at 
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:340)
at 
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:277)
at 
com.radiovoodoo.action.ServletDispatcher.service(ServletDispatcher.java:177)
at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:206)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:150)
at 
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:175)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:150)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:167)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:90)
at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:115)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:93)
at 
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:673)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)
at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:391)
at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:63)
at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:896)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1736)
at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52)
at 
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
at 
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:63)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: java.lang.NullPointerException: Cannot invoke 
"java.util.TimeZone.getDisplayName()" because "this.customerTimeZone" is null
at 
com.radi

Re: .intermittent InvocationTargetException errors

[Christopher Schultz]

Rick,

On 4/15/24 10:04, Rick Noel wrote:

Hello,

I am using Tomcat 10 with java 17.

I am getting itermitant jsp compile errors below.

Some times the page compiles correctly but sometimes the page hits result in 
below errors

java.lang.reflect.InvocationTargetException
 at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
 at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.base/java.lang.reflect.Method.invoke(Method.java:568)
 at com.radiovoodoo.display.EvalExpr.evalIdentifier(EvalExpr.java:317)
 at com.radiovoodoo.display.EvalExpr.eval(EvalExpr.java:57)


What is RadioVoodoo?

Is there more of the stack trace?


I found this explanation for possible cause..
Normally "java.lang.reflect.InvocationTargetException" occurs when java 
compiler finds 2 different classes with same name in 2 different packages.
When you are importing both classes at a time and when you are trying to create object of 
that class it throws "java.lang.reflect.InvocationTargetException" exception .
The solution is that when you are creating the object of the class use package 
name also along with class name so that compiler knows what class it has to use.


This is unlikely to be the explanation. I've never seen 
InvocationTargetException under the conditions described. The compiler 
should never allow you to import two classes with the same "simple" 
(without package) name, because it's impossible for it to then tell 
which one you mean in a given expression.



I looked at my code in the jsp and the code in question could be mistaking for 
two different classes.
My code is meant to use  java.util.Timezone but my code also has a  
com.radiovoodoo.customer.Timezone class


What do your imports look like?


So I thought ah ah will specifical declare the class the I want, so I changed
From
private TimeZone customerTimeZone;
to
private java.util.TimeZone customerTimeZone;

so that the compiler will not think to use com.radiovoodoo.customer.Timezone 
but instead always use java.util.TimeZone
But this had no effect.


What do your imports look like?


I still get intermittent java.lang.reflect.InvocationTargetException
Could this be a possible bug in   the class tomcat 10 uses to compile jsp   ->  
org.apache.jasper.servlet.JspServlet


It's possible, but not very likely. We have a pretty good set of unit 
tests, plus we aren't getting any reports from others that the compiler 
is failing in this way.



Is there a different JspServlet class I could use to test that theory out?


I'm curious as to why RadioVoodoo is being invoked during compilation. 
Or is this happening during JSP execution, post-compile? A more complete 
stack trace would reveal that.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [EXT]Re: [EXT]Re: Tomcat 10 session replication fails

[Christopher Schultz]

Rick,

On 4/15/24 08:12, Rick Noel wrote:

Hi Chuck,
Your suggestion did not work.

I defined Membership as suggested...


and still getting this in the logs

org.apache.catalina.ha.session.DeltaManager.startInternal Starting clustering 
manager at [##0001]
15-Apr-2024 07:55:36.744 INFO [main] 
org.apache.catalina.ha.session.DeltaManager.getAllClusterSessions Manager 
[##0001]: skipping state transfer. No members active in cluster group

Do you think the transfer is not happening because the application is only on 
one machine?
Our Production environment will have  our application on two machines but in our dev environment we 
have only one machine in the "cluster". So we really do not have a "cluster" 
environment.
Again, we would like to know is going on before we introduce clustering in our 
live environment.

We are using Java 17 and Tomcat 10


I've never set up replication in Tomcat, so I may be speaking out of turn.

But is it possible that since you have only a single node (right?), 
Tomcat is really saying "skipping state transfer. No [other] members 
active in cluster group"?


-chris


-Original Message-
From: Chuck Caldarale 
Sent: Saturday, April 13, 2024 4:00 PM
To: Tomcat Users List 
Subject: [EXT]Re: [EXT]Re: Tomcat 10 session replication fails



On Apr 11, 2024, at 09:07, Rick Noel  wrote:

We are getting closer
Changing ports from the 5000 range to the 4000 range stopped two
errors But now I get this..

INFO: Manager [##0001]: skipping state transfer. No members active in
cluster group

How to I make the member machine in the cluster active?



There’s a cluster configuration option that may be coming into play here: 
localLoopbackDisabled. Once upon a time, the JDK method:
 MulticastSocket.setLoopbackMode(boolean disable) did the opposite of 
what one might think from just the method name - passing in true disabled local 
receipt of multicast packets. That method has since been deprecated, and Tomcat 
currently uses this method:
  DatagramSocket.setOption​(SocketOption name, T value) which, at 
least in Java 21, operates as you might expect from the name - specifying true enables 
multicast loopback.

However, there’s some interesting logic in Tomcat's handling of 
localLoopbackDisabled that can inverts the config value based on the Java 
level, along with this comment:
 Java < 14, a value of true means loopback is disabled. Java 14+ a 
value of true means loopback is enabled.

Having not dug into the JRE source code for the various Java versions, I’m not yet 
convinced the version checking logic is correct. You might try setting 
localLoopbackDisabled to true in your  config to see if that 
has an effect on your dev system.

Also, let us know what Java version you’re using.

   - Chuck


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

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



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

.intermittent InvocationTargetException errors

[Rick Noel]

Hello,

I am using Tomcat 10 with java 17.

I am getting itermitant jsp compile errors below.

Some times the page compiles correctly but sometimes the page hits result in 
below errors

java.lang.reflect.InvocationTargetException
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at com.radiovoodoo.display.EvalExpr.evalIdentifier(EvalExpr.java:317)
at com.radiovoodoo.display.EvalExpr.eval(EvalExpr.java:57)

I found this explanation for possible cause..
Normally "java.lang.reflect.InvocationTargetException" occurs when java 
compiler finds 2 different classes with same name in 2 different packages.
When you are importing both classes at a time and when you are trying to create 
object of that class it throws "java.lang.reflect.InvocationTargetException" 
exception .
The solution is that when you are creating the object of the class use package 
name also along with class name so that compiler knows what class it has to use.

I looked at my code in the jsp and the code in question could be mistaking for 
two different classes.
My code is meant to use  java.util.Timezone but my code also has a  
com.radiovoodoo.customer.Timezone class
So I thought ah ah will specifical declare the class the I want, so I changed
From
private TimeZone customerTimeZone;
to
private java.util.TimeZone customerTimeZone;

so that the compiler will not think to use com.radiovoodoo.customer.Timezone 
but instead always use java.util.TimeZone
But this had no effect.

I still get intermittent java.lang.reflect.InvocationTargetException
Could this be a possible bug in   the class tomcat 10 uses to compile jsp   ->  
org.apache.jasper.servlet.JspServlet

Is there a different JspServlet class I could use to test that theory out?


Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com

RE: [EXT]Re: [EXT]Re: Tomcat 10 session replication fails

[Rick Noel]

Hi Chuck,
Your suggestion did not work.

I defined Membership as suggested...


and still getting this in the logs

org.apache.catalina.ha.session.DeltaManager.startInternal Starting clustering 
manager at [##0001]
15-Apr-2024 07:55:36.744 INFO [main] 
org.apache.catalina.ha.session.DeltaManager.getAllClusterSessions Manager 
[##0001]: skipping state transfer. No members active in cluster group

Do you think the transfer is not happening because the application is only on 
one machine?
Our Production environment will have  our application on two machines but in 
our dev environment we have only one machine in the "cluster". So we really do 
not have a "cluster" environment.
Again, we would like to know is going on before we introduce clustering in our 
live environment.

We are using Java 17 and Tomcat 10


Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com

-Original Message-
From: Chuck Caldarale  
Sent: Saturday, April 13, 2024 4:00 PM
To: Tomcat Users List 
Subject: [EXT]Re: [EXT]Re: Tomcat 10 session replication fails


> On Apr 11, 2024, at 09:07, Rick Noel  wrote:
>
> We are getting closer
> Changing ports from the 5000 range to the 4000 range stopped two 
> errors But now I get this..
>
> INFO: Manager [##0001]: skipping state transfer. No members active in 
> cluster group
>
> How to I make the member machine in the cluster active?


There’s a cluster configuration option that may be coming into play here: 
localLoopbackDisabled. Once upon a time, the JDK method:
MulticastSocket.setLoopbackMode(boolean disable) did the opposite of 
what one might think from just the method name - passing in true disabled local 
receipt of multicast packets. That method has since been deprecated, and Tomcat 
currently uses this method:
 DatagramSocket.setOption​(SocketOption name, T value) which, at 
least in Java 21, operates as you might expect from the name - specifying true 
enables multicast loopback.

However, there’s some interesting logic in Tomcat's handling of 
localLoopbackDisabled that can inverts the config value based on the Java 
level, along with this comment:
Java < 14, a value of true means loopback is disabled. Java 14+ a value 
of true means loopback is enabled.

Having not dug into the JRE source code for the various Java versions, I’m not 
yet convinced the version checking logic is correct. You might try setting 
localLoopbackDisabled to true in your  config to see if that 
has an effect on your dev system.

Also, let us know what Java version you’re using.

  - Chuck


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

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: Package URLs for Apache Tomcat distributions

[von Loewenstein, Jan]

Hi all,

I recently started a discussion about pURLs as package identifier on the Tomcat 
mailing list and it was brought up, that this might be a broader topic to be 
discussed here.

Best regards
Jan

From: Thomas Hoffmann (Speed4Trade GmbH) 

Date: Monday, 15. April 2024 at 13:14
To: Tomcat Users List 
Subject: AW: Package URLs for Apache Tomcat distributions
[You don't often get email from thomas.hoffm...@speed4trade.com.invalid. Learn 
why this is important at https://aka.ms/LearnAboutSenderIdentification ]

> On 11/04/2024 16:52, von Loewenstein, Jan wrote:
> > Hi folks,
> >
> > I am part of the Paketo community, and we are providing Cloud Native
> Buildpacks to create container images with – amongst other technologies –
> Apache Tomcat and Apache TomEE as application runtimes.
> >
> > One of the features of Cloud Native Buildpacks is that images come with
> Software-Bill-of-Material. When installing Apache Tomcat, we issue the
> following CPE and pURL to the SBOM:
> >
> >1.  cpe:2.3:a:apache:tomcat:10.1.20:*:*:*:*:*:*:*
> >2.  pkg:generic/apache-tomcat@10.1.20
> >
> > The former should be the right one for users to find relevant CVEs in
> > e.g. the nvd.nist.gov. The latter however is made up and will likely
> > not lead to any findings on e.g. 
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fosv.dev%2F&data=05%7C02%7Cjan.von.loewenstein%40sap.com%7Cb85c9c7b0ef84a12888a08dc5d3d36f8%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638487764973925741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C4%7C%7C%7C&sdata=THsJsmmmf%2BYnOFsfX2ET%2B9qosC%2F3%2BTmn73piJBppidA%3D&reserved=0
> >
> > Now I am wondering if you report Tomcat vulnerabilities under any pURL and
> which one that would be.
>
> We don't.
>
> > There is a 
> > proposal spec/blob/master/PURL-TYPES.rst#other-candidate-types-to-define> to
> introduce `pkg:apache` as a namespace, which would open up
> `pkg:apache/tomcat@10.1.20` as a canonical pURL.
>
> That is a foundation wide decision and not one the Tomcat project can make
> unilaterally. That is probably a topic for security-
> disc...@community.apache.org where pURL has already been touched on this
> thread:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2F7hs5ooqhfozmhlvq24k5xztzn1nwp9yv&data=05%7C02%7Cjan.von.loewenstein%40sap.com%7Cb85c9c7b0ef84a12888a08dc5d3d36f8%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638487764973940781%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C4%7C%7C%7C&sdata=GxRiFt2Dwk74ykwVxLf0rE9DItO2cnyg5u5nZ8%2Fr0%2Fs%3D&reserved=0
>
> Mark

This topic might get even more important when the cyber resilience act of the 
European Union will be released.
Software manufacturers will be obliged to provide an inventory / SBOM list.
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedium.com%2F%40interlynkblog%2Feu-cra-and-sbom-5100c55752fa%23%3A~%3Atext%3DThe%2520CRA%2520text%2520implies%2520that%2Cregulators&data=05%7C02%7Cjan.von.loewenstein%40sap.com%7Cb85c9c7b0ef84a12888a08dc5d3d36f8%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638487764973945572%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C4%7C%7C%7C&sdata=3SaPhtmEDR1Dsf8l5f9zZo7UMfqCpelZIgC9Bl%2FgO9o%3D&reserved=0')%20and%20product%20manufacturers.



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

AW: Package URLs for Apache Tomcat distributions

[Thomas Hoffmann (Speed4Trade GmbH)]

 
> On 11/04/2024 16:52, von Loewenstein, Jan wrote:
> > Hi folks,
> >
> > I am part of the Paketo community, and we are providing Cloud Native
> Buildpacks to create container images with – amongst other technologies –
> Apache Tomcat and Apache TomEE as application runtimes.
> >
> > One of the features of Cloud Native Buildpacks is that images come with
> Software-Bill-of-Material. When installing Apache Tomcat, we issue the
> following CPE and pURL to the SBOM:
> >
> >1.  cpe:2.3:a:apache:tomcat:10.1.20:*:*:*:*:*:*:*
> >2.  pkg:generic/apache-tomcat@10.1.20
> >
> > The former should be the right one for users to find relevant CVEs in
> > e.g. the nvd.nist.gov. The latter however is made up and will likely
> > not lead to any findings on e.g. https://osv.dev
> >
> > Now I am wondering if you report Tomcat vulnerabilities under any pURL and
> which one that would be.
> 
> We don't.
> 
> > There is a proposal spec/blob/master/PURL-TYPES.rst#other-candidate-types-to-define> to
> introduce `pkg:apache` as a namespace, which would open up
> `pkg:apache/tomcat@10.1.20` as a canonical pURL.
> 
> That is a foundation wide decision and not one the Tomcat project can make
> unilaterally. That is probably a topic for security-
> disc...@community.apache.org where pURL has already been touched on this
> thread:
> https://lists.apache.org/thread/7hs5ooqhfozmhlvq24k5xztzn1nwp9yv
> 
> Mark

This topic might get even more important when the cyber resilience act of the 
European Union will be released.
Software manufacturers will be obliged to provide an inventory / SBOM list.
https://medium.com/@interlynkblog/eu-cra-and-sbom-5100c55752fa#:~:text=The%20CRA%20text%20implies%20that,regulators')%20and%20product%20manufacturers.
  



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Package URLs for Apache Tomcat distributions

[Mark Thomas]

On 11/04/2024 16:52, von Loewenstein, Jan wrote:

Hi folks,

I am part of the Paketo community, and we are providing Cloud Native Buildpacks 
to create container images with – amongst other technologies – Apache Tomcat 
and Apache TomEE as application runtimes.

One of the features of Cloud Native Buildpacks is that images come with 
Software-Bill-of-Material. When installing Apache Tomcat, we issue the 
following CPE and pURL to the SBOM:

   1.  cpe:2.3:a:apache:tomcat:10.1.20:*:*:*:*:*:*:*
   2.  pkg:generic/apache-tomcat@10.1.20

The former should be the right one for users to find relevant CVEs in e.g. the 
nvd.nist.gov. The latter however is made up and will likely not lead to any 
findings on e.g. https://osv.dev

Now I am wondering if you report Tomcat vulnerabilities under any pURL and 
which one that would be.


We don't.


There is a 
proposal
 to introduce `pkg:apache` as a namespace, which would open up 
`pkg:apache/tomcat@10.1.20` as a canonical pURL.


That is a foundation wide decision and not one the Tomcat project can 
make unilaterally. That is probably a topic for 
security-disc...@community.apache.org where pURL has already been 
touched on this thread:

https://lists.apache.org/thread/7hs5ooqhfozmhlvq24k5xztzn1nwp9yv

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat log warnings for connection parameter limits?

[Mark Thomas]

On 11/04/2024 21:28, Baron Fujimoto wrote> I was thinking it would be 
something that would be left on in a live> system. We can set these 
parameters, so it would be useful to know if we

were hitting the set limits.


For the connection limit:

How timely do you need the information to be? It is much easier to add a 
check when the connection is closed since a) it returns the current 
count and b) we are already checking the return value for mis-counting.


For the thread limit:

We have a couple of options here. (We use a custom queue which 
effectively changes the way threads in the pool re used.) The simplest 
is probably to add log in TaskQueue.offer() if all threads are currently 
being used.



I'm not sure I fully grasp how this additional logging presents a
significant incremental DOS risk. I mean, if an attacker is flooding you
with enough traffic or connections where this becomes an issue, aren't you
already logging various aspects of the attempts anyway (e.g., access logs,
etc)? At that point aren't your logs already being filled anyway?


It is an area we need to be careful with. Log messages that include 
exceptions are of greatest concern since they are relatively expensive 
to generate. If an invalid HTTP message triggers a log message with an 
exception (it does, but only when configured for debug logging) then 
there is a degree of DoS risk there.


Access logs are a special case and one that we have taken care to try 
and optimise. Still, if you want to make a performance test look good 
turning off access logging is one of the first things to do (and of 
course results in totally meaningless results that don't reflect real 
world usage).


I think the concern Chris was trying to express (although I'm sure he'll 
correct me if I am wrong) is that when these limits are reached there is 
a risk of a lot of log messages being generated and that can cause 
issues both from a performance issue and from just filling the logs with 
the same message over and over again.


I think what we would need is some form of hysteresis. Log a message 
when the limit is reached, log another message when usage falls below 
80%? of the limit. That way, administrators see the peaks in usage but 
aren't inundated with log messages.


My only concern is that at least some this code is going to run for 
every single request. It needs to be efficient. We should measure the 
impact of adding this code before we decide on whether to include it.


Mark




On Thu, Apr 11, 2024 at 1:44 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Baron,

On 4/9/24 16:33, Baron Fujimoto wrote:

I'm investigating occasional 503 errors for our CAS service running in a
Tomcat 10.1.x container. The 503s appear to correlate with some traffic
spikes at the same time.

The connector is configured as follows:

  

Can Tomcat log info such as when the maxThreads or maxConnections limits
are reached? I'm basically trying to see if there is a good way to
more definitively determine what may have caused the 503s and what may be
feasible to mitigate them.


Are you thinking of a debugging feature or something to be left-on for a
live production system?

Such logging might be considered a DOS vector for a live system: you can
fill the logs by asking lots of trivial requests.

-chris

-
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