Hmmm, one hacky way might be to hold on to the grouper instance passed in via
configuration, and once the cache manager has been started, set it in the
grouper and use to query either the address, or the physical address (via
EmbeddedCacheManager.getTransport…)?
On May 14, 2013, at 6:34 PM,
I guess the grouper could use a KeyAffinityService (or something similar)
to generate a key local to each node and return that instead of 0 or 1.
However, you won't have any guarantee that the keys will stay on the same
node if the cache topology changes (e.g. another node joins).
It used to be
Thanks for the response Galder. Interesting. I have been counseled by
Mircea to use the KeyAffiinityService API to do my physical key pinning @
specific node participants. However, the KeyAffinityService brings the risk
of not being able to allow my pinned keys to survive topology changes
Ben, do you think being able to pin a key permanently to a node would be
useful?
Indeed I do.
The ideal mechanism would be to merge both the ambitions of the
Grouper#computeGroup(key) API and KeyAffinityService API into a capability
that would allow me to render non-anonymous grouping that
I am playing with the Infinispan 5.3 quick-start package to exercise my usage
of the Grouping API. As we know the quick start package is made up of
AbstractNode.java, Node0.java, Node1.java and Node2.java (plus a
util/listener).
My ambition is to demonstrate
1. that any
