Incorrect. Thread.interrupt() simply sets a Thread.isInterrupted() flag. It is up to the user code (Wicket) to check for this value on a regular basis in order to decide whether to abort rendering and we should do so.
There is no risk of "crashing" the Thread. Again, this interruptability thing is just a flag. Certain methods will throw InterruptedException -- which we should handle and treat as if Thread.isInterrupted() returned true. I've already used this strategy in my product code and it works fine for signaling an abort.
If you are not comfortable with this, set some other flag/variable.
Gili
--Original Message Text---
From: Johan Compagner
Date: Wed, 05 Jan 2005 17:35:07 +0100
thread.interrupt() will only work for blocking io. (or wait)
You can't just interrupt a running thread.
There is no way to do that in java. (thread.stop() can't be used and that is also a thing you don't want to do)
second you don't have any idea which thread handles what at the moment.. And if you just "crash" the thread
then the components /models can be in a complete invalid state.
So just let it go is the only thing that can be done.
Gili wrote: Suggestion: right before you lock on the session, check if it
is currently in mid-processing. If so, call Thread.interrupt() on it or
signal interruption in some other manner, *then* lock on the session.
The benefit here is that if a user hits REFRESH multiple times quickly,
we don't fall behind trying to render pages when they have been
aborted.
I know how to implement this easily under JDK 1.5 (using
java.util.concurrent.Lock) but I'm not sure how you could do it using
older JDKs... Still, I think it is a great idea and would give Wicket a
huge advantage over other frameworks from a scalability point of view.
Gili
On Wed, 05 Jan 2005 16:26:50 +0100, Eelco Hillenius wrote:
It works different. Johan synchronizes on the session, so two users have
their requests executed without this. The problem occured when one user
(one session) refreshed quickly.
So, as the synchronizations happens for a session, the scalability is
not reduced.
Eelco
Gili wrote:
On Wed, 5 Jan 2005 15:17:59 +0100, Juergen Donnerstag wrote:
Hi Eelco,
Syncronized around session object in HandleRender so that only one request
can touch/render a page and its components.
I think I understand the change, but is there a possibility that it
could ever happen and thus requires synchronization?
It can if two users hit a Page at the same time (I think).
Thing is, I think that synchronizing Page rendering by default isn't
necessarily a good thing. It simplifies things but it'll also reduce
the scalability of Wicket.
Gili
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
