One solution I thought of was to have TreeCache set a boolean value in a ThreadLocal in _clusteredGet and _dataGravitationCleanup. A cache listener could then check for the ThreadLocal and ignore events that arise from data gravitation.
Kinda hacky though.
Should node removals originating from data gravitation cleanups emit notifications in the first place? I suppose so, for correctness and predictability of behaviour.
What about an additional parameter to the remove notification, to indicate whether the remove is cluster-wide (i.e., a REAL remove) or local (i.e., a data gravitation cleanup)? This would be a 2.0.0 fix though.
I don't think the distinction of LOCAL vs. REMOTE will suffice though? I thought this is problematic for remote node as well.
Maybe we should have a data gravitated event to distinguish this? But we still need to prevent the nodeRemoved event. So that may back to square one.
I think what Manik's suggesting isn't really LOCAL vs REMOTE but rather dataGravitation=true/false. It would get signalled on whatever node was affected by the gravitation.
That could work, and is certainly less hacky than the ThreadLocal :) But, should this be added to all notifications? In my current usage of JBC, only confusion about the nodeRemoved caused a problem. But that's just because of the way the code works; other use cases may have a similar problem with other notifications.
BTW, turns out this is not an issue for ClusteredSSO. Thinking about this made me realize BR is totally inappropriate for ClusteredSSO (I'd thought it was non-optimal but usable; it's not.)