rom: [EMAIL 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:
>
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
> Sent: Saturday, February 04, 2006 5:15 PM
> To: jboss-development@lists.sourceforge.net
> Subject: 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
> &
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 wor
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
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.
Ther
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]
[mailto:[EMAI
