[
https://issues.jboss.org/browse/ISPN-186?page=com.atlassian.jira.plugin.s...
]
Pete Muir commented on ISPN-186:
--------------------------------
My impl of this ends up creating a web of unicasts, sending a command to each owner of a
key, requesting them to send invalidation commands as required to each node that has
cached the key. Because of this, I don't have a single place at which I know the
number of nodes to which invalidation will be sent, so can't implement a simple
threshold as Bela proposes.
Without changing this design (I can't see a lower overhead way to do it, but open to
ideas), I think the best way to handle a threshold is to make N = number of invalidations
+ number of owners but this seems a bit complex. Looking for ideas...
Smart L1 cache invalidation
---------------------------
Key: ISPN-186
URL:
https://issues.jboss.org/browse/ISPN-186
Project: Infinispan
Issue Type: Feature Request
Components: Distributed Cache
Reporter: Manik Surtani
Assignee: Pete Muir
Labels: l1
Fix For: 5.0.0.BETA1, 5.0.0.Final
Need to build a mechanism in which L1 invalidation is NOT multicast, but instead is
unicast _if necessary_ to specific nodes that may have cached a given entry. This can be
detected by maintaining a list of nodes who have requested a key via a remote get, but
this would need to be relayed by all data owners.
Benefits would be performance by removing unnecessary invalidation where this is not
needed, and by reducing noise in network stacks of most nodes.
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira