[JBoss JIRA] (ISPN-10689) RocksDB 6.2.2
by Tristan Tarrant (Jira)
Tristan Tarrant created ISPN-10689:
--------------------------------------
Summary: RocksDB 6.2.2
Key: ISPN-10689
URL: https://issues.jboss.org/browse/ISPN-10689
Project: Infinispan
Issue Type: Component Upgrade
Components: Loaders and Stores
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (ISPN-10683) Remove CustomFailurePolicy transaction parameters
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-10683?page=com.atlassian.jira.plugin... ]
Dan Berindei commented on ISPN-10683:
-------------------------------------
Does it really make sense to register/unregister resources in the failure policy? I thought all the policy could do is throw a {{BackupFailureException}}.
Initially I meant to remove the transaction completely, but then I thought we might want a way to connect the prepare and commit commands for the same tx.
> Remove CustomFailurePolicy transaction parameters
> -------------------------------------------------
>
> Key: ISPN-10683
> URL: https://issues.jboss.org/browse/ISPN-10683
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 10.0.0.CR2
> Reporter: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> The {{CustomFailurePolicy}} javadoc says it should be thread-safe, but the {{javax.transaction.Transaction}} javadoc doesn't say anything about thread safety.
> We should replace the {{javax.transaction.Transaction}} with a {{GlobalTransaction}}, which we know is thread-safe.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (ISPN-10678) Cluster Expiration should only expire primary owned entries
by Wolf-Dieter Fink (Jira)
[ https://issues.jboss.org/browse/ISPN-10678?page=com.atlassian.jira.plugin... ]
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)
5 years, 2 months