[infinispan-issues] [JBoss JIRA] (ISPN-10678) Cluster Expiration should only expire primary owned entries

[Wolf-Dieter Fink (Jira)]

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

Wolf-Dieter Fink commented on ISPN-10678:
-----------------------------------------

Some tests
Environment 2 nodes clustered on a local machine - configuration:
~~~
            <cache-container name="clustered" default-cache="ExpirationCache" statistics="true">
                <transport lock-timeout="60000"/>
                <global-state/>
                <distributed-cache name="ExpirationCache">
                  <locking isolation="READ_COMMITTED" striping="false"/>
                  <transaction mode="NON_XA" locking="OPTIMISTIC"/>
                  <expiration interval="10000"/>
                </distributed-cache>
            </cache-container>
~~~

Two test clients will add as much as possible bc of the key it will be a max of 1 entry per millisecond each. The expiration is set to 1sec
In the cluster the expiration thread spikes >50sec (with one node it will be <2sec)
Between start and stop message there are
27948  pool-9-thread  Submitting expiration removal for key
1200    remote-thread  Submitting expiration removal for key 


> Cluster Expiration should only expire primary owned entries
> -----------------------------------------------------------
>
>                 Key: ISPN-10678
>                 URL: https://issues.jboss.org/browse/ISPN-10678
>             Project: Infinispan
>          Issue Type: Enhancement
>          Components: Expiration
>    Affects Versions: 9.4.16.Final, 10.0.0.CR2
>            Reporter: Will Burns
>            Assignee: Will Burns
>            Priority: Major
>             Fix For: 10.0.0.Final, 9.4.17.Final
>
>
> Today cluster expiration fires for any expired entry it finds. We should instead only expire an entry when it is the primary owner encountering the entry. This will allow expiration to scale much better depending on the number of owners. This also reduces network and locking contention as we may have been sending duplicate expiration commands from backups and primary at the same time.



--
This message was sent by Atlassian Jira
(v7.13.8#713008)