[#OSGI-228] RunnableTimedExecution uses Thread.stop()

Spring OSGi

RunnableTimedExecution uses Thread.stop()

Created: 10/Oct/07 07:52 AM Updated: 06/Jun/08 09:03 AM Due: 09/Nov/07

Component/s:

EXTENDER

Affects Version/s:

1.0 M3

Fix Version/s:

1.1 RC1

Time Tracking:

Not Specified

Description

« Hide

RunnableTimedExecution uses Thread.stop(). Thread.stop() is known to not work properly and have unintended side-effects. We should find some other way of providing the required behaviour.

All

Comments

Work Log

Change History

FishEye

Builds

Sort Order:

[ Permlink | « Hide ]

Philip May added a comment - 11/Oct/07 03:43 AM

Even the ContextLoaderListener is using ThreadGroup.stop().

[ Permlink | « Hide ]

Costin Leau added a comment - 18/Oct/07 09:38 AM

Indeed Thread.stop should not be used but in practice, I've found no other way to stop 'rogue' threads. Consider the case where the thread instead of looking at a flag just keeps on waiting or working - there is nothing we can do to interrupt that particular thread for doing its work especially when catching exceptions.
Both runnableTimedExecution and especially ContextLL deal with app starts/stops where the platform can shutdown while some contexts are initializing and in that case, we have to make sure everything goes down.
We actually have an excellent test made by Hal where the platform shuts down while an appCtx is started and w/o using thread.stop, things just keep hanging.

[ Permlink | « Hide ]

Andy Piper added a comment - 19/Oct/07 04:55 AM

But isn't the code using thread.stop() regardless? Seems like it should first see if it exits gracefully? Or maybe I am missing something.

[ Permlink | « Hide ]

Costin Leau added a comment - 22/Oct/07 09:26 AM

thread.stop is called only if waitForZero does not exist succesfully -i.e. task.run takes longer then expected in which case, the thread is stopped and true returned.
If the task.run ends faster then the time period, then false is returned w/o interacting with the thread.