On Mon, 2006-02-06 at 01:06, Jason T. Greene wrote:
Actually the behavior you describe is the semantics of Thread.destroy()
if it were actually implemented. Thread.stop() just forces the targeted
thread to throw a ThreadDeath exception. This causes all finally blocks
to execute, and in fact if
PROTECTED] [mailto:jboss-
[EMAIL PROTECTED] On Behalf Of Adrian Brock
Sent: Monday, February 06, 2006 3:25 AM
To: jboss-development@lists.sourceforge.net
Subject: RE: [JBoss-dev] BasicThreadPool and Thread.stop()
Thanks for the clarification. Re-reading this:
http://java.sun.com/j2se/1.5.0/docs
: RE: [JBoss-dev] BasicThreadPool and Thread.stop()
On Sat, 2006-02-04 at 17:44, Scott M Stark wrote:
It was the only way I found to implement a timeout behavior that had
a
chance of working when there were uncooperative tasks. See the
org.jboss.test.util.test
It was the only way I found to implement a timeout behavior that had a
chance of working when there were uncooperative tasks. See the
org.jboss.test.util.test.
ThreadPoolTaskUnitTestCase.testCompleteTimeoutWithSpinLoop as an
example.
-Original Message-
From: [EMAIL PROTECTED]
On Sat, 2006-02-04 at 17:44, Scott M Stark wrote:
It was the only way I found to implement a timeout behavior that had a
chance of working when there were uncooperative tasks. See the
org.jboss.test.util.test.
ThreadPoolTaskUnitTestCase.testCompleteTimeoutWithSpinLoop as an
example.
There is
Its kind of sad there is no solution to this after all of this time.
Gosh Java sucks... ;-) I'm sure it all works perfectly in NuFuBarX
lang...we must migrate JBoss immediately.
Adrian Brock wrote:
On Sat, 2006-02-04 at 17:44, Scott M Stark wrote:
It was the only way I found to implement a
This sounds like a good blog:
Sun, we want fixes not new features
Talk about this thread problem as well as the serialization problems.
Adrian Brock wrote:
On Sat, 2006-02-04 at 17:44, Scott M Stark wrote:
It was the only way I found to implement a timeout behavior that had a
chance of
