[infinispan-issues] [JBoss JIRA] (ISPN-5545) Make lazy near caching more selective

[William Burns (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-5545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13625905#comment-13625905 ] 

William Burns edited comment on ISPN-5545 at 8/29/18 10:45 AM:
---------------------------------------------------------------

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 regarding Create for INVALIDATION. I think this is critical to reduce the # of events that are generated with very low cost and the user is completely unaffected. The only time this can't be used is if we implement tombstones in the near cache, since CREATE would have to invalidate those.

The second is a bit more interesting (being selective), 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.


was (Author: william.burns):
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 regarding Create for INVALIDATION. I think this is critical to reduce the # of events that are generated with very low cost and the user is completely unaffected.

The second is a bit more interesting (being selective), 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)