I'm not totally sure I understand your issue here but I'll give it a try.

The soft-state model defines the loose coupling between registrants and 
registry.  The registry is never informed "over-the-wire" that a registrant is 
no longer in existence, it relies on the period renewal of the registrant to 
keep it in the registry.

So, are you talking about getting some sort of callback when the entry 
resource is removed on the registry (server) side (indicating that the 
registrant renewal was not made in time)? 

If so, I think in order to do this, AggregatingServiceGroupEntryResource needs 
to implement RemoveCallback, and then during the invoked remove() call, the 
developer-supplied callback function can be invoked.  I do not think that the 
AggregatorSink.deliver() call is the appropriate place for this.

At this point we are in a code freeze and I think this sounds more like an 
enhancement request than a blocker bug.  I'm changing the severity to normal 
since it doesnt affect the out-of-the-box operation of the existing MDS code. 

Via email:
A removeCallback is one good way.
Another way I can see is some user configurable provider on the
softstate failure when the sweeper fails due to a dead registrant entry.
As answered by bug 3151, the current way is to only print some message
in the log file.

We had this ability in gt3.2, where an instance-operationProvider can be
configured in the wsdd file to take actions when registrant dies. Now in
gt4 this ability is gone, our system stopped working properly under
failure, thus I called it a blocker.

I appreciate it very much if you could suggest any workaround.
Xubo

OK, I think we are on the same page here - or close... :)

So, given that we are talking about the same thing, then I would agree that 
there needs to be some way of generating an interceptable code event or 
callback when AggregatingServiceGroupResource removes an expired entry on the 
registry (server) side.  I changed the summary line of this bug to reflect this.

As you point out there are multiple ways to implement this and ultimately I 
would like to choose the most flexible and utilitarian solution.  I'm happy to 
engage in a broader email discussion about how to approach it.

The bad news is that since we are now in a code freeze, this will not be 
implemented for the initial 4.0 release.  At this point, the earliest something 
could be done is 4.0.1.

In the meantime I'll try to consider a workaround for this, and certainly you 
are welcome to consider one as well.  We can always attach any workaround as 
diff patch to this bug. If I can come up with a decent patch I'll post it here.

hi Mike,
is it going to be included in 4.0.1? When is the timeframe for 4.0.1?
thanks!

I've committed code to CVS HEAD that will invoke a user-supplied callback 
function when an AggregatingServiceGroupEntry resource is removed by the 
sweeper thread.  

The user-supplied class must be found in the classpath and implement the 
org.globus.mds.aggregator.impl.AggregatorServiceGroupEntryRemovedCallback 
class.  The administrator configures the usage of the callback by adding a 
configuration parameter in the AggregatorConfiguration element of a service 
jndi-config.xml file.  

A service must already incorporate the Aggregator framework to make use of 
this feature.

An example configuration entry is as follows:

<parameter>
  <name>entryRemovedCallback</name>
  <value>org.my.custom.package.SampleAggregatorRemoveCallback</value>
</parameter>               

Fixed for 4.0.1