RE: Debugging Tomcat during shutdown
Could it depend on whether 'suspend=n' or 'suspend=y' is set on the jdwp
options?
JP
-Original Message-
From: Mark Thomas
Sent: woensdag 8 juni 2022 14:50
To: users@tomcat.apache.org
Subject: Re: Debugging Tomcat during shutdown
On 08/06/2022 13:39, Jean Pierre URKENS wrote:
> Indeed the servlet#destroy() method is called.
>
> That is however not the issue I was troubleshooting, I just mentioned
> it as an example of a method I can't debug since the debug session is
> killed before hitting the servlet#destroy() method.
I can't recreate that problem. I have tested with 10.1.x, 8.5.x and
8.5.43 and in all cases, as long as I make sure a servlet has been loaded,
execution stops at the breakpoint I have set.
> What I am actually was trying to troubleshoot is spring context
> cleanup which seems to happen after the servlet cleanups. Here e.g.
> the stacktrace I was tackling:
>
> java.lang.NullPointerException
>
> at
> java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.j
> ava:1106)
> In the meantime I know why the NPE occurs, but it bothered me that I
> couldn’t debug through it (debug session got killed before hitting any
> breakpoint I activated, e.g. in Serverimpl#stop()).
That is odd. I'd expect the debug session to be active as long as the JVM
was running.
One thing you could try is adding an additional breakpoint to the finally
block in StandardServer.await(). That should allow you to control the
shutdown process.
A final thought. Are you sure you have the right source code in your IDE?
While RHEL may based Tomcat 8.5.x on 8.5.43 they will have back-ported
security and other fixes so the 8.5.43 source code from the ASF is unlikely
to be a prefect match to what you have running. Often you can get away with
it, but sometimes I have had issues with breakpoints not activating because
I was using the wrong source code.
Glad you fixed the NPE anyway.
Mark
>
>
>
> -Original Message-
> From: Mark Thomas
> Sent: woensdag 8 juni 2022 14:23
> To: users@tomcat.apache.org
> Subject: Re: Debugging Tomcat during shutdown
>
>
>
> On 08/06/2022 11:54, Jean Pierre URKENS wrote:
>
>> Hi Mark,
>
>>
>
>> I know the version is quite old, but that is what the client
>> currently
>
>> has installed.
>
>
>
> ACK.
>
>
>
>> I am shutting Tomcat down with ${TOMCAT_HOME}/bin/shutdown.sh (RHEL
>
>> 7.x server).
>
>
>
> Good. I think that is likely to be the best option in this case.
>
>
>
>> We've got TOMCAT_HOME under '/opt/tomcat8' and several TOMCAT_BASE
>
>> server instances.
>
>
>
> When you say servlet clean-up actions, what exactly do you mean? The
>
> Servlet.destroy() method?
>
>
>
> Generally, I'd recommend a ServletContextListener for resource clean-up.
>
> Partly that is personal preference - I find it cleaner if all the code
> is in one place - and partly it is avoiding potential issues around
> containers destroying unused servlets while the web app is running.
> Most
>
> (all) containers won't do this but you never know.
>
>
>
> Meanwhile, I'm planning on some local testing to see if I can recreate
> the issue you are seeing.
>
>
>
> Mark
>
>
>
>
>
>>
>
>> J.P.
>
>>
>
>>
>
>>
>
>> -Original Message-
>
>> From: Mark Thomas
>
>> Sent: woensdag 8 juni 2022 12:45
>
>> To: users@tomcat.apache.org
>
>> Subject: Re: Debugging Tomcat during shutdown
>
>>
>
>> On 08/06/2022 11:29, Jean Pierre URKENS wrote:
>
>>> I am trying to debug the cleanup of resources during a shutdown of
>
>>> Tomcat
>
>>> 8.5.43
>
>>
>
>> That is a rather old version. I'd recommend upgrading.
>
>>
>
>>> and notices that my debug session gets killed prior to performing
>>> any
>
>>> servlet cleanup actions.
>
>>>
>
>>> I am starting Tomcat in debug mode with the JVM options:
>
>>>
>
>>> JAVA_OPTS="$JAVA_OPTS -Xdebug
>
>>> -Xrunjdwp:transport=dt_socket,address=,server=y,suspend=n"
>
>>>
>
>>> Is this normal behavior? How do I debug tomcat in this scenario.
>
>>
>
>> How are you triggering shutdown?
>
>>
>
>> 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
>
-
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
Re: tomcat logging
Hi Alan,
On 09.06.22 12:56, Alan F wrote:
> Tomcat logging
>
> I would like to add a delimiter or characters " " around {user-agent} for
> logging, I wanted it in double quotes for example "Mozilla 5.0.." but can't
> seem to make it work. Or even adding a # symbol before would help any ideas?
I assume, you refer to access logging. Recent Tomcat has a proper example
already in the standard server.xml (IIRC for a long time), just use the "
XML
entity, where you need it (taken from 9.0.64):
If you are happy with a standard combined pattern, just use pattern="combined",
it contains user agent in double quotes.
See https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Access_Log_Valve
for complete pattern information.
hth,
Thomas
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
[ANN] Apache Tomcat 10.1.0-M16 (beta) available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 10.1.0-M16 (beta). Apache Tomcat 10 is an open source software implementation of the Jakarta Servlet, Jakarta Server Pages, Jakarta Expression Language, Jakarta WebSocket, Jakarta Authentication and Jakarta Annotations specifications. The Jakarta EE specifications implemented by Tomcat 10.1.x are now final and Tomcat's implementation of those specifications is complete. Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 without changes. Java EE applications designed for Tomcat 9 and earlier may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat will automatically convert them to Jakarta EE and copy them to the webapps directory. This conversion is performed using the Apache Tomcat migration tool for Jakarta EE tool which is also available as a separate download for off-line use. Apache Tomcat 10.1.0-M16 is a milestone release of the 10.1.x branch and has been made to provide users with early access to the new features in Apache Tomcat 10.1.x so that they may provide feedback. The notable changes compared to 10.1.0-M15 include: - Refactor synchronization blocks locking on SocketWrapper to use ReentrantLock to support users wishing to experiment with project Loom. - Correct a regression in the support added for encrypted PKCS#1 formatted private keys in the previous release that broke support for unencrypted PKCS#1 formatted private keys. - Increase the default buffer size for cluster messages from 43800 to 65536 bytes. This is expected to improve performance for large messages when running on Linux based systems. Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-10.1-doc/changelog.html Downloads: http://tomcat.apache.org/download-10.cgi Migration guides from Apache Tomcat 7.0.x, 8.5.x and 9.0.x: http://tomcat.apache.org/migration.html Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
tomcat logging
Tomcat logging
I would like to add a delimiter or characters " " around {user-agent} for
logging, I wanted it in double quotes for example "Mozilla 5.0.." but can't
seem to make it work. Or even adding a # symbol before would help any ideas?
Thanks
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
[ANN] Apache Tomcat 9.0.64 available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 9.0.64. Apache Tomcat 9 is an open source software implementation of the Java Servlet, JavaServer Pages, Java Unified Expression Language, Java WebSocket and JASPIC technologies. Apache Tomcat 9.0.64 is a bugfix and feature release. The notable changes compared to 9.0.63 include: - Correct a regression in the support added for encrypted PKCS#1 formatted private keys in the previous release that broke support for unencrypted PKCS#1 formatted private keys. - Increase the default buffer size for cluster messages from 43800 to 65536 bytes. This is expected to improve performance for large messages when running on Linux based systems. - When using TLS with non-blocking writes and the NIO connector, ensure that flushing the buffers attempts to empty all of the output buffers. Along with lots of other bug fixes and improvements. Please refer to the change log for the complete list of changes: https://tomcat.apache.org/tomcat-9.0-doc/changelog.html Downloads: https://tomcat.apache.org/download-90.cgi Migration guides from Apache Tomcat 7.x and 8.x: https://tomcat.apache.org/migration.html Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat service switches to another JDK under the hood
I have some updates. First of all, there is no JDK switch under the hood. I am glad my conclusion was wrong. In my REST API client app I use Java 11+ HTTPClient. For the POST call the external API requires Content-Lenght header even the body is empty, which HTTPClient doesn't support out of the box. You can add this header manually, but it is only allowed in JDK12+ together with the setting the system property jdk.httpclient.allowRestrictedHeaders=content-length. This property has to be set before instantiating the HTTPClient, so I set the system property directly in the code the line before httpClient initialization. It worked fine after deployment, but stopped working after while (next day). Now it is clear that even setting the system property in the code, it is ignored by that httpClient initialization code. It sounds like HTTPClient instance is somehow reused/shared across threads/apps and some created without this system property in place was picked up. Now I am setting the system property as the command line param when starting the tomcat and issue has gone (= all httpClient instances are equivalent). Jan -Original Message- From: Zdeněk Henek Sent: Monday, April 11, 2022 2:35 PM To: Tomcat Users List Subject: Re: Tomcat service switches to another JDK under the hood Nothing you mentioned could have any effect. How do you ensure jdks are not mixing between tomcat and the other jdk8 application? Try to use separated cmd files as described above for both Tomcat and the other application and remove all jdk configurations from windows variables just to test this option. I think it is much better to keep all config separated especially when you have two apps each using different jdk. Regards, Zdenek Henek On Mon, Apr 11, 2022 at 1:50 PM Jan Tosovsky wrote: > There isn't any sign of the tomcat restart in the tomcat logs. In > tomcat9-stderr-2022-04-08.log there is just one bootstrap section with > the path to JDK 17, followed by mesages about the registering webapps. > Then weekend of silence interrupted by today's exception. > > In that bootstrap section there are listed exact params I can see in > the service configuration accessible via tray icon. So in this stage I > believe tomcat does its job properly. There is no interference with OS > settings. > But then something breaks. > > > If this could have some infuence: > - one of tomcat webapps is based on Quartz scheduler running various > tasks including java based utilities (i.e. running their own JVMs) > - our apps are served by Apache HTTP via AJP > - all webapps are JSF based, no DB, just simple controller; the main > purpose is to process user input or fetch external REST API services > and display the result > - there is one extra 3rd party "hotfolder" Java app running as a > service (JDK 8 is used in this case) > > > -Original Message- > From: Zdeněk Henek > Sent: Monday, April 11, 2022 1:04 PM > To: Tomcat Users List > Subject: Re: Tomcat service switches to another JDK under the hood > > Hi Jan, > > looks like somebody/something has restarted tomcat with different > JAVA_HOME/PATH variables. It is not possible to change jvm process > while running. > > Another option could be you have there running two tomcat instances. > > Create cmd file e.g. tomcatStart.cmd with content like > > set JAVA_HOME=c:/... > set CATALINA_HOME=c:/.. > set PATH=%JAVA_HOME%/bin;%PATH% > > and use only this file to start tomcat. Put there other variables eg. > JAVA_OPTS in case you have some other jvm variables. > Do not rely on MS Windows variables settings. > > Regards, > > Zdenek Henek > > > On Mon, Apr 11, 2022 at 12:18 PM Jan Tosovsky wrote: > > > We have a mixed JDK environment on our internal Windows Server. > > > > Tomcat is installed using the service installer and its service > > configuration points to the JDK 17 as it serves some internal apps > > requiring JDK 12+. > > > > > > > > JAVA_HOME points to older JDK 8. > > > > PATH variable contains link to JDK 8, but also to JDK 11 in this > > order (the latter link is a bug I spotted right now). > > > > > > > > And now weirdness comes. From time to time the tomcat somehow > > switches to older JDK: we detect this by the fact the internal > > webapp complains about the issue only present in pre-JDK 12 > > versions. I assume JDK 11 is used as this is related to JDK > > HttpClient which is not the part of > the JDK 8. > > > > It is strange the only reference to JDK 11 is that PATH entry, but > > is the second one so JDK 8 should win if the PATH is somehow involved. > > > > > > > > Actual case: the tomcat was restarted manually on Friday using tray > > icon and in the log I can see that JDK 17 was picked up. There was > > no user activity during the weekend. Today when accessing the app > > error is raised. Manual restart via try icon fixed the issue. > > > > > > > > This issue is not urgent in any case, there are no mission-critical
