Hey Will,
With the current design, during a topology change, an event might be delivered twice to a
cluster listener. I think we might be able to identify such situations (a node becomes a
key owner as a result of the topology change) and add this information to the event we
send, e.g. a flag "potentiallyDuplicate" or something like that. Event
implementors might be able to make good use of this, e.g. checking their internal state if
an event is redelivered or not. What do you think? Are there any other more-than-once
delivery situations we can't keep track of?
Cheers,
--
Mircea Markus
Infinispan lead (
www.infinispan.org)