Could it depend on whether 'suspend=n' or 'suspend=y' is set on the jdwp
options?

JP
-----Original Message-----
From: Mark Thomas <ma...@apache.org>
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)

<snip/>

> 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 <ma...@apache.org>
> 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 <ma...@apache.org>
>
>> 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=xxxx,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 commands, e-mail: users-h...@tomcat.apache.org

Reply via email to