Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 316696

Summary:

[otre] OTRE doesn't know about all threads

Product:

[Tools] Objectteams

Reporter:

Stephan Herrmann <stephan.herrmann>

Component:

OTJ

Assignee:

Stephan Herrmann <stephan.herrmann>

Status:

VERIFIED FIXED

QA Contact:

Severity:

normal

Priority:

Version:

1.4

Target Milestone:

0.7

Hardware:

OS:

Linux

Whiteboard:

trac

Attachments:

Description	Flags
proposed fixes	none

Description Stephan Herrmann

2010-06-13 08:33:11 EDT

(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)!

Comment 1 Stephan Herrmann

2010-06-13 08:56:37 EDT

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.

Comment 2 Stephan Herrmann

2010-06-27 07:06:08 EDT

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

Comment 3 Stephan Herrmann

2010-06-27 08:20:52 EDT

(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.

Comment 4 Stephan Herrmann

2010-06-27 08:28:34 EDT

(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.

Comment 5 Stephan Herrmann

2010-07-06 07:23:30 EDT

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.