[JBoss JIRA] (ISPN-11851) FD_SOCK should use the same bind address as TCP
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11851?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11851:
-----------------------------------
Sprint: DataGrid Sprint #44, DataGrid Sprint #45 (was: DataGrid Sprint #44)
> FD_SOCK should use the same bind address as TCP
> -----------------------------------------------
>
> Key: ISPN-11851
> URL: https://issues.redhat.com/browse/ISPN-11851
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration, 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
>
>
> In the JGroups configuration files we ship, we use a different default for {{TCP.bind_addr}} and {{UDP.bind_addr}} than JGroups does.
> {code:xml}
> <TCP bind_addr="${jgroups.bind.address,jgroups.tcp.address:SITE_LOCAL}"/>
> <UDP bind_addr="${jgroups.bind.address,jgroups.udp.address:SITE_LOCAL}"/>
> {code}
> However, we didn't change the default for {{FD_SOCK}}, so it uses the JGroups default:
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 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)
4 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)
4 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)
4 years, 7 months