Community
Participate
Working Groups
(originally from http://trac.objectteams.org/ot/ticket/208) (From Jira:TPX-477) When starting AO disposition and trying to execute the cyclic disposition workflow, an exception ist thrown (see below). Note that a change of isActive() to isActive(aThread) in Workflow.java doesn't work, too. In 0.9.13, the problem doesn't occur. ---------------------------------------------------- Exception in thread "AWT-EventQueue-0" java.lang.IllegalThreadStateException: Called 'isActive(...)' for a thread which is no longer running! at org.objectteams.Team.isActive(Team.java:245) at org.objectteams.Team.isActive(Team.java:227) at de.gebit.topprax.disposition.aop.controller.disposition.cyclic.Workflow$__OT__Controller.deactivate(Workflow.java:365) ... Answer by resix: The "IllegalThreadStateException" should be thrown, if you call isActive(th) for a thread 'th' which is already finished. This is not the case in your example, but the OTRE has the problem, that it is not "aware" of all threads (threads loaded by the bootstrap classloader, the main thread, ?). Temporary fix of this problem: instead of checking for if (!TeamThreadManager.getExistingThreads().contains(thread)) { throw exception } the OTRE now checks for if (!thread.isAlive()) { throw exception } but we have to develop a more general solution for the problems with overlooked threads (see also TPX-414)!
For all threads started before entering main it seems that asking the top-level ThreadGroup for all its active threads would easily allow as to register all known threads at that point. Once all threads are known we can then remove the workarounds regarding the AWT-Event-Thread from class Team (methods deactivate(Thread) and isActive(Thread)) Another thing that bothers me is the use of (new Exception().getStackTrace().length > 3) in TeamThreadManager#newThreadStarted(..) We might get around that by just checking whether the thread is already registered in existingThreads. While we're at it: field Team#_OT$activatedThreads seems to be used inconsistently: Since possible values per thread are TRUE and FALSE, using containsKey(..) looks wrong, should also check the value.
Created attachment 172853 [details] proposed fixes This patch implements the following changes: > For all threads started before entering main it seems that asking > the top-level ThreadGroup for all its active threads would easily > allow as to register all known threads at that point. Done. > Once all threads are known we can then remove the workarounds regarding the > AWT-Event-Thread from class Team (methods deactivate(Thread) and > isActive(Thread)) Done. > Another thing that bothers me is the use of > (new Exception().getStackTrace().length > 3) > in TeamThreadManager#newThreadStarted(..) > > We might get around that by just checking whether the thread is already > registered in existingThreads. Done. Still want to look at usage of Team#_OT$activatedThreads
(In reply to comment #1) > Another thing that bothers me is the use of > (new Exception().getStackTrace().length > 3) > in TeamThreadManager#newThreadStarted(..) > > We might get around that by just checking whether the thread is already > registered in existingThreads. added test5215_explicitActivationForAllThreads3a() to challenge this part.
(In reply to comment #1) > While we're at it: field Team#_OT$activatedThreads > seems to be used inconsistently: Since possible values per thread > are TRUE and FALSE, using containsKey(..) looks wrong, should also > check the value. This was false alarm: the boolean value discriminates explicit vs. implicit activation and is actually used consistently. This closes this issue.
Verified using build 201007050931 I used the following scenario to check the issue of the AWT-Event-Queue: Debugging FlightBonus, BP on FlightBonus-ctor, change activate() to activate(ALL_THREADS), but interactively deactivate for current thread. => Globally active except for AWT event thread -> not effective.
