Stopping a very time consuming class method's execution on tomcat server using JSP.

[nihardhruva]

Hey all,

I have a very strange problem and expecting to receive your answer very urgent...

I have a class in my package named MyPackage on my tomcat server. I am using one method of this class, which is very time consuming, as follows in my jsp page...

HeavyClass hc = new HeavyClass();
hc.methodLongTimeExecution();

once I press submit button in my jsp page, it will start execution of this method on the server, and will execute for longer time. meanwhile, as this process is very timeconsuming, when a user clicks Stop button, my browser will stop responding, but the execution of the method will still continue on my Tomcat Server. Now, because, this method execution requires very heavy memory as well as it takes very long time, what I want is, whenever a person clicks a stop button of browser, it should also stop the execution of that method on my remote tomcat server.

Can anyone guide me how can I do this???

or also, guide me about what I should do if I want to put my own button to stop the execution, and how can stop execution of the method on click of that button...

I need the answer very urgently...

Kindly reply soon,

Thanking you,

Nihar.

[masijade]

Well, you could write a stop method and rewrite the "start" method to use
threads, then after you instantiate the class, store it as a session variable, then
start the "start" method as a thread. Then return a page containing the key used
to store the object and stop button. The stop button will call another jsp that
will retreive the object stored under that key and call the "stop" method. This is
all really loosely explained, but you should be able to extrapolate from here.
Unfortunately, your user will also get no notification that the process is finished.
You could, however, write a checkProgress method that another jsp can use to check the process and "refreshes" from time to time. This would have to called
using a refresh from the "stop button" page and also then must contain the "stop
button".

[nihardhruva]

Hi masijade,

Thanks for your suggestion. It really worked. I implemented it and it is working fine...

Really thanks for your kindness.

--> Nihar Dhruva.

Well, you could write a stop method and rewrite the "start" method to use
threads, then after you instantiate the class, store it as a session variable, then
start the "start" method as a thread. Then return a page containing the key used
to store the object and stop button. The stop button will call another jsp that
will retreive the object stored under that key and call the "stop" method. This is
all really loosely explained, but you should be able to extrapolate from here.
Unfortunately, your user will also get no notification that the process is finished.
You could, however, write a checkProgress method that another jsp can use to check the process and "refreshes" from time to time. This would have to called
using a refresh from the "stop button" page and also then must contain the "stop
button".

[masijade]

That was quick. I'm glad I was able to help.

[coltech]

Hi there masijade.

Would you care to explain a little bit further what you're saying, I have the same problem but I don't understand your soultion.

Thanx for your time.

coltech

Well, you could write a stop method and rewrite the "start" method to use
threads, then after you instantiate the class, store it as a session variable, then
start the "start" method as a thread. Then return a page containing the key used
to store the object and stop button. The stop button will call another jsp that
will retreive the object stored under that key and call the "stop" method. This is
all really loosely explained, but you should be able to extrapolate from here.
Unfortunately, your user will also get no notification that the process is finished.
You could, however, write a checkProgress method that another jsp can use to check the process and "refreshes" from time to time. This would have to called
using a refresh from the "stop button" page and also then must contain the "stop
button".

[masijade]

Sorry, I was away.

Well, what I am saying goes as follows:

the long running process should be contained in its own object rather than
being called directly from the jsp. Also, creating an instance of this
object should not start the process, but just create a "handle" to it. This
object should have "start", "stop", and "checkProgress" methods. The
start method should start the long running process in a thread. The stop
method should interupt this thread and perform and needed cleanup. The
checkProgress method should report back how far the process has
progressed (how you do/report/track this is completely up to you).

Now on to usage:

In initial JSP:
- create instance
- store instance as session object
- call instance start routine
- return an html page containing a "stop" link (url to "stop" page")
- this page will (after a set time) refresh to the "checkProgress" page
use the refresh header info for this

In refresh jsp:
- retrieve instance from session
- call the checkProgress method
- return an html page that will refresh to itself after a set time
use the refresh header info for this
- this page should also contain the "stop" link (url to the "stop" page)

In Stop page:
- retrieve instance from session
- call "stop" method
- delete the session object
- return an acknowledgement html page

[dkerberwra]

I've never tried to do this, but I think you're going to have to track the thread ID of the long-running process and terminate that thread when the user clicks your "stop processing" button in your app. I don't think you can detect them pressing the browser's cancel button. Also, I have never dealt with threads so I have no idea how to implement this suggestion.

[masijade]

I've never tried to do this, but I think you're going to have to track the thread ID of the long-running process

The Object that "controls" the thread is what is being stored in the session. IOW, already suggested.

and terminate that thread when the user clicks your "stop processing" button in your app.

You can't terminate a thread (you can only interrupt, i.e. signal, it and let the thread clean itself up). IOW, already suggested.

I don't think you can detect them pressing the browser's cancel button.

Already mentioned.

Also, I have never dealt with threads so I have no idea how to implement this suggestion.

Well, I don't mean to be mean, but then why post this? He has already been given a very detailed answer and this post didn't add anything, I'm sorry to say.

Aside from the fact that this thread is 2 years old.

[~s.o.s~]

IMO creating and manipulating threads in a managed environment is bad in itself since the request is already being processed by a thread and the chances of the programmer screwing up with threading and making the mess out of the entire affair is pretty high. Plus, there is no reliable way of completely stopping a thread since it's inherently unsafe and has been deprecated.

If the user isn't expecting a quick response, one possible way would be to use asynchronous messaging. A better method would be to make the entire process interactive and execute the process in chunks so that the user always has the option of going back or canceling the process under consideration.

[masijade]

As far as the programmer making a mess of the programming, that can always happen.

And, I never said he should call thread destroy, or anything in that manner. I said to call interuppt and let the Thread clean itself up (and those actions are once again something the programmer must do), which is not, of course, deprecated.

The last paragraph, of course, is another very good option, though.

I agree, that it is not a very good idea to have a browser wait on a long running process, it would be a much better idea to have a "batch" style backend that the user can either check on at a later date, or that the backend can notify the user in some way (email, sms, etc.).

Some things cannot always be run in chunks, however. As an example, I recently had to write a Monte-Carlo financial simulation that operated on a few hundred thousand transactions, over a 10 year time period on a quarterly basis, over a minimum of 20000 iterations. The simulation could not be broken down (and still be effecient) and took a couple of hours to run. We used an event driven batch-style backend that sent an email upon completion.

[dkerberwra]

I only posted because I didn't see any other responses at the time. I wouldn't have said a word if I had seen that first response; the author obviously has a much better handle on it than I do.

[~s.o.s~]

> As far as the programmer making a mess of the programming, that can always happen.

Though the probability increases in this case. :-)

> And, I never said he should call thread destroy, or anything in that manner.

I guess I misread your first post.

The stop button will call another jsp that will retreive the object stored under that key and call the "stop" method.

[masijade]

Sorry. It's explained (better, although still not perfectly) in the next post.

The stop method should interupt this thread and perform and needed cleanup.

;-)

[jwenting]

NEVER use Thread.stop(). It's extremely dangerous and will more likely than not cause very nasty things to happen.
It's deprecated for a reason you know, and that reason is that it will NOT do any cleanup.
It will kill the thread, and everything in it, now. No questions asked.
If that leaves data in an incomplete or unstable state, it doesn't care. If it leaves network or database resources open it couldn't care less. If it keeps hardware locked, waiting for commands that never can come no more, it's oblivious of that.

[masijade]

NEVER use Thread.stop(). It's extremely dangerous and will more likely than not cause very nasty things to happen.
It's deprecated for a reason you know, and that reason is that it will NOT do any cleanup.
It will kill the thread, and everything in it, now. No questions asked.
If that leaves data in an incomplete or unstable state, it doesn't care. If it leaves network or database resources open it couldn't care less. If it keeps hardware locked, waiting for commands that never can come no more, it's oblivious of that.

Yes. I know. Read again, that was suppossed to be self-written "stop" method in a class that created the thread (not the one from the thread class) designed to call interrupt on the actual thread and then perform some clean-up.

Edit: And yes, it was a very poor choice of a name, and it caused the confusion, but hey, at least I knew what I meant. ;-)

[jwenting]

of course including any such method in a JSP (which the kid was asking for) is as bad as calling Thread.stop()...
It's likely going to be ineffective as well, as the thread may well survive the context in which the JSP is executed.

[unicode]

That was quick. I'm glad I was able to help.

Dear masijade,

Can u plz help me out in similar kind of proble?
My Server is having two Consecutive very long process having lon time on JBOSS server 4.0.2, how can I make my client to wait till the process ends and responce in JSP apge.

Thanks

[jwenting]

that's a different problem, and one you can't solve.
The server will time out the request, and even if not the client will at some point time out the request.