Bug 3814 – Calling GramJob.destroy() from the notification call

Bug 3814 - Calling GramJob.destroy() from the notification call

Summary:

Calling GramJob.destroy() from the notification call

Status:	RESOLVED FIXED

Product:	Java WS Core
Component:	globus_wsrf_core
Version:	4.0.1
Platform:	PC Linux

Importance:	P3 normal
Target Milestone:	---
Assigned To:	Jarek Gawor

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2005-10-13 19:56 by Mihael Hategan
Modified:	2005-10-14 15:31 (History)

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note

You need to log in before you can comment on or make changes to this bug.

Description From Mihael Hategan 2005-10-13 19:56:43

I have a gram job. I add a listener to that. When the job completes (or fails),
in the listener, I call job.destroy(). This tries to shut down the notification
container. That happens (among other things) by signalling all the service
threads in the pool, and then waiting for them to complete. However, since the
wait happens in one of these threads, it cannot complete unless it times out.

------- Comment #1 From Jarek Gawor 2005-10-13 23:10:09 -------

This might be viewed from two separate point of views. 1) it's a user's bug - 
you shouldn't be shutting down the notificatin consumer container from within 
one of its threads, 2) it's a container issuse - when waiting for its threads 
to shutdown, it should ignore the container thread that is the same as the 
current calling thread.

I think probably both things should be fixed.

------- Comment #2 From Mihael Hategan 2005-10-13 23:30:04 -------

I think this is a reasonable usage scenario (calling the destroy from the
notification call). Otherwise I would have to artificially create a thread (or
queue) just for the purpose of destroying GRAM jobs.

------- Comment #3 From Jarek Gawor 2005-10-14 15:31:45 -------

Fixes committed to globus_4_0_branch and trunk. If the calling thread is one of 
the container threads it will be ignored when waiting for all the container 
threads to finish. Also, added a test case for this scenario.