ZK normally does all it's work for a single request on the server in a single thread. Events.echoEvent
lets you get around that by finishing the request, and then calling back to the server immediately in a brand new request (and thread). The user's interaction with the client fires off a new request, so that will be a new thread also.
So, in your example above, you will be working with three threads:
- for the original request which calls
echoEvent
- for the new request created by the
echoEvent
- for the request created when the user clicks 'cancel'
Obviously, the first will be long gone by the time the last two get called, but this is what you need to be thinking about in order to solve your problem.
You'll find plenty of discussion on StackOverflow about getting two threads to interact, or more specifically, getting one thread to interrupt another.
I'll refer you to 'How to stop threads in Java?' where the accepted answer favored sharing some sort of 'stop flag' over directly calling interrupt
on a thread.
In your scenario this would play out with the long running process doing it's work while periodically checking the stop flag (a simple boolean
). When the user clicks 'Cancel', you just need to flip the flag to true
.