[
https://issues.jboss.org/browse/ISPN-5545?page=com.atlassian.jira.plugin....
]
William Burns commented on ISPN-5545:
-------------------------------------
I wonder if we should convert this JIRA into something a little more generic regarding how
to make near cache scale better.
I came to the same conclusion re: Create for INVALIDATION. I think this is critical to
reduce the # of events are generated with very low cost and the user is completely
unaffected.
The second is a bit more interesting, because the user would have to specify what entries
they want to cache and we would have to be able to send that to the server in some fashion
(possibly causing class loading issues).
I thought of two more additional ways to reduce near cache overhead:
1. When a client event queue is found to be exhausted, instead of waiting forever we
should probably add some sort of timeout. And if the timeout occurs, we throw out the
event queue and just send a clear event to the client. This way the client can essentially
start over with their near cache. This could cause issues if the server is constantly
under fire from modify/remove events, but for those given bursts it will at least let the
server respond in a more timely fashion.
2. Possibly store the requested keys on the server side for a given client. This way only
INVALIDATION messages are sent for keys that are actually modified, instead of all keys.
This would require clearing out cache during rehash I would think though, since you
don't want to retain keys for non owned entries (also this shouldn't be used if
the underlying storage is off heap) - we should make sure the retained key is the same one
in the container.
Make lazy near caching more selective
-------------------------------------
Key: ISPN-5545
URL:
https://issues.jboss.org/browse/ISPN-5545
Project: Infinispan
Issue Type: Enhancement
Reporter: Galder ZamarreƱo
Assignee: Galder ZamarreƱo
In the current form, when lazy near caching is enabled, the server sends invalidation
messages for any key that has been created, modified or removed.
This is suboptimal for a couple of reasons:
1. First of all, a near cache might only interested in receiving invalidation events for
those keys that are currently stored in the near cache. If the near cache is small subset
of the entire cache, having such option would vastly reduce the number of events sent to
clients. So, there needs to be a way to be able to narrow the events sent from the server
to this subset of keys.
2. Lazy near caches do not care about created events. If an entry is present in the near
cache, it has already been created, so it's only interested in modified and removed
events. There needs to be a way to narrow this down too.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)