tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Specific Thread of an web Application
Date Tue, 03 Aug 2010 21:37:37 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Karthik,

On 8/3/2010 10:31 AM, Karthik Nanjangude wrote:
>>> application has some bad code built by a 3rd party
> 
> Yet another Problem ...
> we do not have the license to hack the code and fix the problem .... :(

You've been robbed.

> Any other Solutions please.

Hire someone else?

I don't believe JConsole allows you to interrupt threads in any way. You
can always write your own code to do it, though.

Let's just say for instance that your webapp had been written to
fire-off a thread for each user to do some stupid task and then leave
that thread in the user's session. You want to kill the thread when the
session dies. Here's one (unsafe) say to do it:

public class UserThreadMurderer
  implements HttpSessionListener
{
    public void sessionDestroyed(HttpSessionEvent evt)
    {
        HttpSession session = evt.getSession();

        if(null != session)
        {
            Thread userThread
                    = (Thread)session.getAttribute("dumb_thread");

            if(null != userThread)
            {
                if(ThreadState.TERMINATED == userThread.getState())
                {
                    // No need to stop the thread
                }
                else
                {
                   // ... and I'm all out of bubble gum

                   System.out.println("Murdering thread "
                          + userThread.getName()
                          + " which is terribly busy trying to:");

                   userThread.dumpStack();

                   try
                   {
                       // maybe try interrupt() first? nah...

/*
- From the Thread.stop javadoc:

[Use of Thread.stop] is inherently unsafe. Stopping a thread with
Thread.stop causes it to unlock all of the monitors that it has locked
(as a natural consequence of the unchecked ThreadDeath exception
propagating up the stack). If any of the objects previously protected by
these monitors were in an inconsistent state, the damaged objects become
visible to other threads, potentially resulting in arbitrary behavior.
Many uses of stop should be replaced by code that simply modifies some
variable to indicate that the target thread should stop running. The
target thread should check this variable regularly, and return from its
run method in an orderly fashion if the variable indicates that it is to
stop running. If the target thread waits for long periods (on a
condition variable, for example), the interrupt method should be used to
interrupt the wait. For more information, see Why are Thread.stop,
Thread.suspend and Thread.resume Deprecated?.
*/

                       userThread.stop(); // This is my "boom stick"
                   }
                   catch (Throwable t)
                   {
                       t.printStackTrace(); // probably should log this
                   }
                }
            }
        }
    }

    public void sessionCreated(HttpSessionEvent evt) { }
}

If you want even better code, you could always hire someone like me. Or
just me.

This really ought to be a last resort.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxYjCEACgkQ9CaO5/Lv0PCG1wCgplLtQcN724TqOam2WQfV/MDH
nIEAoIgOzDg1R7Kc6QYMcf2y/Bs2qNCI
=We6D
-----END PGP SIGNATURE-----

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


Mime
View raw message