[JBoss JIRA] (ISPN-11802) Create SPI for Cross-Site Replication conflict resolution
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11802?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11802:
-----------------------------------
Sprint: DataGrid Sprint #44, DataGrid Sprint #45 (was: DataGrid Sprint #44)
> Create SPI for Cross-Site Replication conflict resolution
> ---------------------------------------------------------
>
> Key: ISPN-11802
> URL: https://issues.redhat.com/browse/ISPN-11802
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core, Cross-Site Replication
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Priority: Major
>
> A conflict happens if 2 sites try to update the same key (put/remove) concurrently.
> With async Cross-Site Replication (aka IRAC) when a conflict is detected, we use the site name to pick the winning update.
> h2. Interface
> {code:java}
> interface ABC<V> { // or concrete class
> String site(); //the site name which wrote this value
> V value(); // the value. can be null if the key was removed
> Metadata metadata(); //can be null
> }
> interface Resolve<K, V> {
> ABC<V> resolve(K key, ABC<V> entry1, ABC<V> entry2);
> }
> {code}
> h2. Configuration
> Set the class name to use. Can be a {{Class}} object (as shown above) or a {{String}} with the class name.
> For server mode, you need to add your jar with the classes required to {{server/lib}}.
> The configuration fails to validate if the conflict resolution class is set with {{SYNC}} strategy.
> {code:java}
> ConfigurationBuilder.sites().addBackup()
> .site("S")
> .strategy(BackupConfiguration.BackupStrategy.ASYNC)
> .conflictResolution(MyResover.class);
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (ISPN-11847) Remove QueryBuilder and other deprecated dsl package usages
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11847?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11847:
-----------------------------------
Sprint: DataGrid Sprint #44, DataGrid Sprint #45 (was: DataGrid Sprint #44)
> Remove QueryBuilder and other deprecated dsl package usages
> -----------------------------------------------------------
>
> Key: ISPN-11847
> URL: https://issues.redhat.com/browse/ISPN-11847
> Project: Infinispan
> Issue Type: Task
> Components: Embedded Querying, Remote Querying
> Affects Versions: 11.0.0.Dev05
> Reporter: Nistor Adrian
> Assignee: Nistor Adrian
> Priority: Major
> Fix For: 11.0.0.Final
>
>
> The QueryBuilder and friends is deprecated, scheduled for removal in next major.
> We need to remove all its usages from tests and convert them to query string. There might be some tests that do not need to be converted because will be removed with the QueryBuilder when the time comes.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (ISPN-11855) Internal caches should ignore wildcard configurations
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11855?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11855:
-----------------------------------
Sprint: DataGrid Sprint #44, DataGrid Sprint #45 (was: DataGrid Sprint #44)
> Internal caches should ignore wildcard configurations
> -----------------------------------------------------
>
> Key: ISPN-11855
> URL: https://issues.redhat.com/browse/ISPN-11855
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 11.0.0.Dev05, 10.1.8.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 11.0.0.Final, 10.1.9.Final
>
>
> {{InternalCacheRegistryImpl.registerInternalCache}} throws a {{CacheConfigurationException}} if a wildcard configuration matches the internal cache name.
> It should ignore wildcard configurations instead, and a user should be able to replicate the pre-ISPN-11367 behaviour with a {{*}} wildcard:
> {code:xml}
> <cache-container>
> <local-cache-configuration name="*">
> </local-cache-configuration>
> </cache-container>
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (ISPN-11878) Embedded configuration builders should automatically be enabled when attributes configured
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11878?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11878:
-----------------------------------
Sprint: DataGrid Sprint #44, DataGrid Sprint #45 (was: DataGrid Sprint #44)
> Embedded configuration builders should automatically be enabled when attributes configured
> ------------------------------------------------------------------------------------------
>
> Key: ISPN-11878
> URL: https://issues.redhat.com/browse/ISPN-11878
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration
> Affects Versions: 11.0.0.Dev05
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 11.0.0.Final
>
>
> Currently it's neccessary for a user to do the following to configure the global state, as well serveral other configuration elements:
> {{globalBuilder.globalState().enable().persistentLocation(location)}}
> However the configuration of {{persistentLocation}} should be sufficient to enable the global state, i.e. the following should result in enabled(true) being called:
> {{globalBuilder.globalState().persistentLocation(location);}}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (ISPN-11634) Merge TopologyUpdateStableCommand and TopologyUpdateCommand
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11634?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11634:
-----------------------------------
Sprint: DataGrid Sprint #43, DataGrid Sprint #44, DataGrid Sprint #45 (was: DataGrid Sprint #43, DataGrid Sprint #44)
> Merge TopologyUpdateStableCommand and TopologyUpdateCommand
> -----------------------------------------------------------
>
> Key: ISPN-11634
> URL: https://issues.redhat.com/browse/ISPN-11634
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 11.0.0.Dev04
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 11.0.0.Final
>
>
> {code:java}
> 19:48:14,672 TRACE (testng-Test:[]) [TopologyManagementHelper] Attempting to execute command on self: StableTopologyUpdateCommand{cacheName='testCache', origin=Test-NodeD, currentCH=DefaultConsistentHash
> {ns=256, owners = (1)[Test-NodeE: 256+0]}
> , pendingCH=null, actualMembers=[Test-NodeE], persistentUUIDs=[72b17309-62d1-4928-abf6-88a8606ef342], rebalanceId=5, topologyId=27, viewId=7}
> 19:48:14,686 INFO (jgroups-5,Test-NodeE:[]) [CLUSTER] ISPN000094: Received new cluster view for channel org.infinispan.statetransfer.Test: [Test-NodeE|8] (1) [Test-NodeE]
> 19:48:14,690 TRACE (non-blocking-thread-Test-NodeE-p9541-t5:[Merge-8]) [PreferConsistencyStrategy] Max stable partition topology: CacheTopology{id=25, phase=NO_REBALANCE, rebalanceId=5, currentCH=DefaultConsistentHash
> {ns=256, owners = (2)[Test-NodeD: 129+127, Test-NodeE: 127+129]}
> , pendingCH=null, unionCH=null, actualMembers=[Test-NodeD, Test-NodeE], persistentUUIDs=[099401f9-c0b6-460d-8dc8-5051699e8287, 72b17309-62d1-4928-abf6-88a8606ef342]}
> 19:48:14,690 TRACE (non-blocking-thread-Test-NodeE-p9541-t5:[Merge-8]) [PreferConsistencyStrategy] Max active partition topology: CacheTopology{id=27, phase=NO_REBALANCE, rebalanceId=5, currentCH=DefaultConsistentHash
> {ns=256, owners = (1)[Test-NodeE: 256+0]}
> , pendingCH=null, unionCH=null, actualMembers=[Test-NodeE], persistentUUIDs=[72b17309-62d1-4928-abf6-88a8606ef342]}
> 19:48:14,690 DEBUG (non-blocking-thread-Test-NodeE-p9541-t3:[]) [LocalTopologyManagerImpl] Ignoring topology 27 for cache testCache from old coordinator Test-NodeD
> {code}
> The old coordinator (NodeD) sent the topology update and the stable topology update, and NodeE received both. However NodeE might ignores the stable topology update because it was processed after it got the new cluster view, with itself as the coordinator. The proper fix is to get rid of the StableTopologyUpdateCommand and add a stable=true/false field in CacheTopology or in TopologyUpdateCommand.
> There's still a small chance that the coordinator will shut down before sending the topology update command to any of the other nodes, but it's a small chance. It's much more likely that a separate stable topology update command will be ignored because it is queued by LocalTopologyManagerImpl after the regular topology update command, and the regular topology update has a lot of processing to do in StateConsumerImpl.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months