On 12 February 2014 10:40, Mircea Markus <[email protected]> wrote: > 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?
I would really wish we would not push such a burden to the API consumer. If we at least had a modification counter associated with each entry this could help to identify duplicate triggers as well (on top of ordering of modification events as already discussed many times). Sanne > > Cheers, > -- > Mircea Markus > Infinispan lead (www.infinispan.org) > > > > > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
