Bugzilla – Bug 3150
AggregatingServiceGroup* needs to provide Resource.RemoveCallback for entry resources (or equivalent functionality) for derived code
Last modified: 2005-07-20 16:39:07
You need to
before you can comment on or make changes to this bug.
I have built a registry using IndexResource, with a customer sink (extending
ServiceGroupEntryAggregatorSink). The sink gets nothing when a registrant dies.
This is not desirable as the sink should get the same info when the source
loses any entry, just like when the source gets a new entry.
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.
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.
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.
is it going to be included in 4.0.1? When is the timeframe for 4.0.1?
I've committed code to CVS HEAD that will invoke a user-supplied callback
function when an AggregatingServiceGroupEntry resource is removed by the
The user-supplied class must be found in the classpath and implement the
class. The administrator configures the usage of the callback by adding a
configuration parameter in the AggregatorConfiguration element of a service
A service must already incorporate the Aggregator framework to make use of
An example configuration entry is as follows:
Fixed for 4.0.1