Bug 3948 – Service must release all of its resources on deactivation

Bug 3948 - Service must release all of its resources on deactivation

Summary:

Service must release all of its resources on deactivation

Status:	RESOLVED WONTFIX

Product:	GRAM
Component:	wsrf managed execution job service
Version:	development
Platform:	PC Windows XP

Importance:	P5 minor
Target Milestone:	---
Assigned To:	Stuart Martin

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2005-11-28 16:00 by Jarek Gawor
Modified:	2012-09-05 11:42 (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 Jarek Gawor 2005-11-28 16:00:56

During deactivation the service must properly release all of its resources. For 
example, the service must stop all of its threads, stop background tasks, close 
database connections, close opened files, etc. This is extremely important with 
the container dynamic deployment features as services that do not do proper 
cleanup might eventually crash the other services or the container. 

Please see the following for details on deactivation: 
http://www.mcs.anl.gov/~gawor/hotDeployDesign.pdf

------- Comment #1 From Peter Lane 2006-03-30 09:27:27 -------

Is this still a problem? I don't see any details on what exactly was going
wrong or how to reproduce it.

------- Comment #2 From Jarek Gawor 2006-03-31 16:58:21 -------

It is the service responsiblity to ensure that it shutdowns all of it threads,
stops all of processes, etc. You have to figure out what is needed here. To
test things I would suggest running things in a profiler. That is, submit a
job, wait until it is done, perform some hot deploy option (or just simply a
reload operation) that force GC and take a shapshot of the heap. See how many
instances of some gram classes are there. If they doubled then something is
holding references to them. Also, check the number of gram-specific threads.
There should be no gram specific threads after reload (unless you do
loadOnStartup). And once all this looks good, do the same test but while the
job is executing.

------- Comment #3 From Peter Lane 2006-03-31 17:19:07 -------

(In reply to comment #2)
> It is the service responsiblity to ensure that it shutdowns all of it threads,
> stops all of processes, etc. You have to figure out what is needed here.

So you're saying that there is no evidence of anything wrong. This is just a
testing request. Is that right? If that's the case, I hardly consider this
"critical". Putting a target milestone seems more appropriate.

> To
> test things I would suggest running things in a profiler. That is, submit a
> job, wait until it is done, perform some hot deploy option (or just simply a
> reload operation)

What is a "reload" operation?

------- Comment #4 From Stuart Martin 2012-09-05 11:42:58 -------

Doing some bugzilla cleanup...  Resolving old GRAM3 and GRAM4 issues that are
no longer relevant since we've moved on to GRAM5.  Also, we're now tracking
issue in jira.  Any new issues should be added here:

http://jira.globus.org/secure/VersionBoard.jspa?selectedProjectId=10363