Bug 5656 – Destruction of subscription resources relies on alive producer resources

Bug 5656 - Destruction of subscription resources relies on alive producer resources

Summary:

Destruction of subscription resources relies on alive producer resources

Status:	RESOLVED FIXED

Product:	Java WS Core
Component:	globus_wsrf_core
Version:	unspecified
Platform:	Macintosh All

Importance:	P1 blocker
Target Milestone:	4.2.0
Assigned To:	Mike Darcy

URL:
Keywords:

Depends on:	5819
Blocks:	5247
	Show dependency tree / graph

Reported:	2007-10-31 09:45 by Martin Feller
Modified:	2008-06-06 15:02 (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 Martin Feller 2007-10-31 09:45:50

Currently a subscription resource must be destroyed *before* the
corresponding producer resource is destroyed. If a client tries to
destroy a subscription resource after the destruction of the producer
resource an exception is thrown because SimpleSubscription.remove()
can't find the producer resource in the producer home anymore.

I wonder if this strict behavior is necessary. It seems to be
sufficient to just return quietly like it is done in case the
producer resource does not implement the interface
TopicListAccessor.

With this destruction behavior of subscription resources a service
could introduce a new asynchronous destruction pattern for its
resources like: "Terminate my resource and destroy it once you are
done with all cleanup steps" and a client can then still consume
notifications to check the success of the cleanup. Once the final
notification has been sent the subscription resource can be destroyed
although the producer resource had already been destroyed.

------- Comment #1 From Martin Feller 2007-12-04 09:43:00 -------

Gram in 4.2 will rely on the fact that one can destroy
subscription resources after destruction of producer
resources. I talked to Rachana about this and make this
bug a blocker.

------- Comment #2 From Rachana Ananthakrishnan 2008-01-10 15:15:20 -------

Discussed potential solutions with Martin and Tom and outlining proposed
solution here: 

When the notify operation is returned the notification is added to a queue to
be sent and does not depend on any information from producer or subscription
resource to actually send the notification. Rather than allow for orphan
subscriptions, the solution will be to do a cascade delete such that when a
producer resource is removed, it deletes the subscriptions. This implies that
if there is an error processing the notification in the queue, the producer
resource (which the job resource in case of GRAM) will not exist, but given we
don't have reliable notifications, it does not change the model current model.

The implementation will require that the subscription home maintian a list of
subscription resourcer for a given producer, allow for removing all
subscription resources given a producer and reconstruct this information upon
container recovery.

------- Comment #3 From Mike Darcy 2008-01-22 16:53:51 -------

It looks like there is already an existing API to support this in CVS trunk. 
Spoke with Martin and recommended he have a look at
SubscriptionRemovalHelper.java to see if it meets his needs in this case.

------- Comment #4 From Rachana Ananthakrishnan 2008-03-26 09:55:15 -------

Talked to Martin, GRAM leverages the API and things work as expected. Closing
the bug.