Bug 3948 - Service must release all of its resources on deactivation
: Service must release all of its resources on deactivation
Status: RESOLVED WONTFIX
: GRAM
wsrf managed execution job service
: development
: PC Windows XP
: P5 minor
: ---
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2005-11-28 16:00 by
Modified: 2012-09-05 11:42 (History)


Attachments


Note

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


Description From 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 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 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 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 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