[JBoss JIRA] (ISPN-8245) Use Hibernate 5.1 for Hibernate Cache provider
by Galder Zamarreño (JIRA)
Galder Zamarreño created ISPN-8245:
--------------------------------------
Summary: Use Hibernate 5.1 for Hibernate Cache provider
Key: ISPN-8245
URL: https://issues.jboss.org/browse/ISPN-8245
Project: Infinispan
Issue Type: Bug
Components: Hibernate Cache
Affects Versions: 9.1.0.Final
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Fix For: 9.1.1.Final
Currently the base version in Hibernate Cache is Hibernate 5.2, but that causes issues with Wildfly. Instead, base on Hibernate 5.1 and we'll see how to deal with Hibernate 5.2 for Infinispan 9.2.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (ISPN-8244) ejb client-mappings cache is missing entries
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/ISPN-8244?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz closed ISPN-8244.
-------------------------------------
Release Notes Text: Replaced by JBEAP-12889.
Resolution: Done
> ejb client-mappings cache is missing entries
> --------------------------------------------
>
> Key: ISPN-8244
> URL: https://issues.jboss.org/browse/ISPN-8244
> Project: Infinispan
> Issue Type: Bug
> Reporter: Janine Eichler
>
> In JBoss EAP 7.0 (currently using 7.0.7) the client-mappings is missing some entries which can result in incomplete cluster topologies sent to the client.
> [~rachmato] already analysed (and fixed, at least locally) the problem:
> {quote}A little more detail. In the EAP config, there is a cache container called "ejb" and a defaultt cache called "dist" which is used to store SFSB sessions when they are created and make them available across the cluster. This cache has, by default, cache mode DIST. The client-mappings cache, which stores node -> IP:port information for the cluster nodes, is created internally but is based on the configuration of the "ejb"/"dist" cache but is set to cache mode REPL. There seems to be a problem with the configuration of the internally-created client-mappings cache which is causing the problems (in particular, the consistent hash for the Infinispan cache is *possibly* not being set correctly).{quote}
> {quote}
> [...] the CHF setting is the problem. It should be either set to null or ReplicatedConsistentHashFactory. What was happening was that using DefaultConsistentHashFactory (aimed for DIST caches) with a REPL cache only writes entries to numOwners nodes, but the reader thinks that the entries will be available at all nodes, resulting in null values.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 8 months
[JBoss JIRA] (ISPN-8244) ejb client-mappings cache is missing entries
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/ISPN-8244?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on ISPN-8244:
-------------------------------------------
This issue is an EAP clustering issue. Created JBEAP-12889 and closing this one.
> ejb client-mappings cache is missing entries
> --------------------------------------------
>
> Key: ISPN-8244
> URL: https://issues.jboss.org/browse/ISPN-8244
> Project: Infinispan
> Issue Type: Bug
> Reporter: Janine Eichler
>
> In JBoss EAP 7.0 (currently using 7.0.7) the client-mappings is missing some entries which can result in incomplete cluster topologies sent to the client.
> [~rachmato] already analysed (and fixed, at least locally) the problem:
> {quote}A little more detail. In the EAP config, there is a cache container called "ejb" and a defaultt cache called "dist" which is used to store SFSB sessions when they are created and make them available across the cluster. This cache has, by default, cache mode DIST. The client-mappings cache, which stores node -> IP:port information for the cluster nodes, is created internally but is based on the configuration of the "ejb"/"dist" cache but is set to cache mode REPL. There seems to be a problem with the configuration of the internally-created client-mappings cache which is causing the problems (in particular, the consistent hash for the Infinispan cache is *possibly* not being set correctly).{quote}
> {quote}
> [...] the CHF setting is the problem. It should be either set to null or ReplicatedConsistentHashFactory. What was happening was that using DefaultConsistentHashFactory (aimed for DIST caches) with a REPL cache only writes entries to numOwners nodes, but the reader thinks that the entries will be available at all nodes, resulting in null values.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 8 months
[JBoss JIRA] (ISPN-7546) InfinispanStoreRocksDBIT test failures
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-7546?page=com.atlassian.jira.plugin.... ]
Work on ISPN-7546 started by Ryan Emerson.
------------------------------------------
> InfinispanStoreRocksDBIT test failures
> --------------------------------------
>
> Key: ISPN-7546
> URL: https://issues.jboss.org/browse/ISPN-7546
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.0.0.CR2
> Reporter: Gustavo Fernandes
> Assignee: Ryan Emerson
> Fix For: 9.1.1.Final
>
>
> Seems intermittently, tests fails and apparently leaves a server running causing failures in other tests due to JMX duplicate domain exceptions.
> {noformat}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 9.323 sec <<< FAILURE! - in org.infinispan.test.integration.as.InfinispanStoreRocksDBIT
> testCacheManager(org.infinispan.test.integration.as.InfinispanStoreRocksDBIT) Time elapsed: 0.752 sec <<< ERROR!
> org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.start() on object of type PersistenceManagerImpl
> at org.rocksdb.RocksDB.open(Native Method)
> at org.rocksdb.RocksDB.open(RocksDB.java:184)
> at org.infinispan.persistence.rocksdb.RocksDBStore.openDatabase(RocksDBStore.java:98)
> at org.infinispan.persistence.rocksdb.RocksDBStore.start(RocksDBStore.java:62)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.lambda$start$0(PersistenceManagerImpl.java:158)
> at java.util.ArrayList.forEach(ArrayList.java:1249)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.start(PersistenceManagerImpl.java:174)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:867)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:633)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:622)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:547)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:231)
> at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:803)
> at org.infinispan.cache.impl.AbstractDelegatingCache.start(AbstractDelegatingCache.java:411)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:641)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:589)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:453)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:432)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:414)
> at org.infinispan.test.integration.as.InfinispanStoreRocksDBIT.testCacheManager(InfinispanStoreRocksDBIT.java:63)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 8 months
[JBoss JIRA] (ISPN-7546) InfinispanStoreRocksDBIT test failures
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-7546?page=com.atlassian.jira.plugin.... ]
Ryan Emerson reassigned ISPN-7546:
----------------------------------
Assignee: Tristan Tarrant (was: Ryan Emerson)
> InfinispanStoreRocksDBIT test failures
> --------------------------------------
>
> Key: ISPN-7546
> URL: https://issues.jboss.org/browse/ISPN-7546
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.0.0.CR2
> Reporter: Gustavo Fernandes
> Assignee: Tristan Tarrant
> Fix For: 9.1.1.Final
>
>
> Seems intermittently, tests fails and apparently leaves a server running causing failures in other tests due to JMX duplicate domain exceptions.
> {noformat}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 9.323 sec <<< FAILURE! - in org.infinispan.test.integration.as.InfinispanStoreRocksDBIT
> testCacheManager(org.infinispan.test.integration.as.InfinispanStoreRocksDBIT) Time elapsed: 0.752 sec <<< ERROR!
> org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.start() on object of type PersistenceManagerImpl
> at org.rocksdb.RocksDB.open(Native Method)
> at org.rocksdb.RocksDB.open(RocksDB.java:184)
> at org.infinispan.persistence.rocksdb.RocksDBStore.openDatabase(RocksDBStore.java:98)
> at org.infinispan.persistence.rocksdb.RocksDBStore.start(RocksDBStore.java:62)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.lambda$start$0(PersistenceManagerImpl.java:158)
> at java.util.ArrayList.forEach(ArrayList.java:1249)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.start(PersistenceManagerImpl.java:174)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:867)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:633)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:622)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:547)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:231)
> at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:803)
> at org.infinispan.cache.impl.AbstractDelegatingCache.start(AbstractDelegatingCache.java:411)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:641)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:589)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:453)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:432)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:414)
> at org.infinispan.test.integration.as.InfinispanStoreRocksDBIT.testCacheManager(InfinispanStoreRocksDBIT.java:63)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 8 months
[JBoss JIRA] (ISPN-7546) InfinispanStoreRocksDBIT test failures
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-7546?page=com.atlassian.jira.plugin.... ]
Ryan Emerson resolved ISPN-7546.
--------------------------------
Fix Version/s: 9.1.1.Final
Resolution: Done
> InfinispanStoreRocksDBIT test failures
> --------------------------------------
>
> Key: ISPN-7546
> URL: https://issues.jboss.org/browse/ISPN-7546
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.0.0.CR2
> Reporter: Gustavo Fernandes
> Assignee: Tristan Tarrant
> Fix For: 9.1.1.Final
>
>
> Seems intermittently, tests fails and apparently leaves a server running causing failures in other tests due to JMX duplicate domain exceptions.
> {noformat}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 9.323 sec <<< FAILURE! - in org.infinispan.test.integration.as.InfinispanStoreRocksDBIT
> testCacheManager(org.infinispan.test.integration.as.InfinispanStoreRocksDBIT) Time elapsed: 0.752 sec <<< ERROR!
> org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.start() on object of type PersistenceManagerImpl
> at org.rocksdb.RocksDB.open(Native Method)
> at org.rocksdb.RocksDB.open(RocksDB.java:184)
> at org.infinispan.persistence.rocksdb.RocksDBStore.openDatabase(RocksDBStore.java:98)
> at org.infinispan.persistence.rocksdb.RocksDBStore.start(RocksDBStore.java:62)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.lambda$start$0(PersistenceManagerImpl.java:158)
> at java.util.ArrayList.forEach(ArrayList.java:1249)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.start(PersistenceManagerImpl.java:174)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:867)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:633)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:622)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:547)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:231)
> at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:803)
> at org.infinispan.cache.impl.AbstractDelegatingCache.start(AbstractDelegatingCache.java:411)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:641)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:589)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:453)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:432)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:414)
> at org.infinispan.test.integration.as.InfinispanStoreRocksDBIT.testCacheManager(InfinispanStoreRocksDBIT.java:63)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 8 months
[JBoss JIRA] (ISPN-8244) ejb client-mappings cache is missing entries
by Janine Eichler (JIRA)
[ https://issues.jboss.org/browse/ISPN-8244?page=com.atlassian.jira.plugin.... ]
Janine Eichler updated ISPN-8244:
---------------------------------
Description:
In JBoss EAP 7.0 (currently using 7.0.7) the client-mappings is missing some entries which can result in incomplete cluster topologies sent to the client.
[~rachmato] already analysed (and fixed, at least locally) the problem:
{quote}A little more detail. In the EAP config, there is a cache container called "ejb" and a defaultt cache called "dist" which is used to store SFSB sessions when they are created and make them available across the cluster. This cache has, by default, cache mode DIST. The client-mappings cache, which stores node -> IP:port information for the cluster nodes, is created internally but is based on the configuration of the "ejb"/"dist" cache but is set to cache mode REPL. There seems to be a problem with the configuration of the internally-created client-mappings cache which is causing the problems (in particular, the consistent hash for the Infinispan cache is *possibly* not being set correctly).{quote}
{quote}
[...] the CHF setting is the problem. It should be either set to null or ReplicatedConsistentHashFactory. What was happening was that using DefaultConsistentHashFactory (aimed for DIST caches) with a REPL cache only writes entries to numOwners nodes, but the reader thinks that the entries will be available at all nodes, resulting in null values.
{quote}
was:
In JBoss EAP 7.0 the client-mappings is missing some entries which can result in incomplete cluster topologies sent to the client.
[~rachmato] already analysed (and fixed, at least locally) the problem:
{quote}A little more detail. In the EAP config, there is a cache container called "ejb" and a defaultt cache called "dist" which is used to store SFSB sessions when they are created and make them available across the cluster. This cache has, by default, cache mode DIST. The client-mappings cache, which stores node -> IP:port information for the cluster nodes, is created internally but is based on the configuration of the "ejb"/"dist" cache but is set to cache mode REPL. There seems to be a problem with the configuration of the internally-created client-mappings cache which is causing the problems (in particular, the consistent hash for the Infinispan cache is *possibly* not being set correctly).{quote}
{quote}
[...] the CHF setting is the problem. It should be either set to null or ReplicatedConsistentHashFactory. What was happening was that using DefaultConsistentHashFactory (aimed for DIST caches) with a REPL cache only writes entries to numOwners nodes, but the reader thinks that the entries will be available at all nodes, resulting in null values.
{quote}
> ejb client-mappings cache is missing entries
> --------------------------------------------
>
> Key: ISPN-8244
> URL: https://issues.jboss.org/browse/ISPN-8244
> Project: Infinispan
> Issue Type: Bug
> Reporter: Janine Eichler
>
> In JBoss EAP 7.0 (currently using 7.0.7) the client-mappings is missing some entries which can result in incomplete cluster topologies sent to the client.
> [~rachmato] already analysed (and fixed, at least locally) the problem:
> {quote}A little more detail. In the EAP config, there is a cache container called "ejb" and a defaultt cache called "dist" which is used to store SFSB sessions when they are created and make them available across the cluster. This cache has, by default, cache mode DIST. The client-mappings cache, which stores node -> IP:port information for the cluster nodes, is created internally but is based on the configuration of the "ejb"/"dist" cache but is set to cache mode REPL. There seems to be a problem with the configuration of the internally-created client-mappings cache which is causing the problems (in particular, the consistent hash for the Infinispan cache is *possibly* not being set correctly).{quote}
> {quote}
> [...] the CHF setting is the problem. It should be either set to null or ReplicatedConsistentHashFactory. What was happening was that using DefaultConsistentHashFactory (aimed for DIST caches) with a REPL cache only writes entries to numOwners nodes, but the reader thinks that the entries will be available at all nodes, resulting in null values.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 8 months
[JBoss JIRA] (ISPN-8244) ejb client-mappings cache is missing entries
by Janine Eichler (JIRA)
[ https://issues.jboss.org/browse/ISPN-8244?page=com.atlassian.jira.plugin.... ]
Janine Eichler updated ISPN-8244:
---------------------------------
Description:
In JBoss EAP 7.0 the client-mappings is missing some entries which can result in incomplete cluster topologies sent to the client.
[~rachmato] already analysed (and fixed, at least locally) the problem:
{quote}A little more detail. In the EAP config, there is a cache container called "ejb" and a defaultt cache called "dist" which is used to store SFSB sessions when they are created and make them available across the cluster. This cache has, by default, cache mode DIST. The client-mappings cache, which stores node -> IP:port information for the cluster nodes, is created internally but is based on the configuration of the "ejb"/"dist" cache but is set to cache mode REPL. There seems to be a problem with the configuration of the internally-created client-mappings cache which is causing the problems (in particular, the consistent hash for the Infinispan cache is *possibly* not being set correctly).{quote}
{quote}
[...] the CHF setting is the problem. It should be either set to null or ReplicatedConsistentHashFactory. What was happening was that using DefaultConsistentHashFactory (aimed for DIST caches) with a REPL cache only writes entries to numOwners nodes, but the reader thinks that the entries will be available at all nodes, resulting in null values.
{quote}
was:
In JBoss EAP 7.0 the client-mappings is missing some entries which can result in incomplete cluster topologies sent to the client.
[~rachmato] already analysed (and fixed, at least locally) the problem:
{code}
A little more detail. In the EAP config, there is a cache container called "ejb" and a defaultt cache called "dist" which is used to store SFSB sessions when they are created and make them available across the cluster. This cache has, by default, cache mode DIST. The client-mappings cache, which stores node -> IP:port information for the cluster nodes, is created internally but is based on the configuration of the "ejb"/"dist" cache but is set to cache mode REPL. There seems to be a problem with the configuration of the internally-created client-mappings cache which is causing the problems (in particular, the consistent hash for the Infinispan cache is *possibly* not being set correctly).
{code}
{code}
[...] the CHF setting is the problem. It should be either set to null or ReplicatedConsistentHashFactory. What was happening was that using DefaultConsistentHashFactory (aimed for DIST caches) with a REPL cache only writes entries to numOwners nodes, but the reader thinks that the entries will be available at all nodes, resulting in null values.
{code}
> ejb client-mappings cache is missing entries
> --------------------------------------------
>
> Key: ISPN-8244
> URL: https://issues.jboss.org/browse/ISPN-8244
> Project: Infinispan
> Issue Type: Bug
> Reporter: Janine Eichler
>
> In JBoss EAP 7.0 the client-mappings is missing some entries which can result in incomplete cluster topologies sent to the client.
> [~rachmato] already analysed (and fixed, at least locally) the problem:
> {quote}A little more detail. In the EAP config, there is a cache container called "ejb" and a defaultt cache called "dist" which is used to store SFSB sessions when they are created and make them available across the cluster. This cache has, by default, cache mode DIST. The client-mappings cache, which stores node -> IP:port information for the cluster nodes, is created internally but is based on the configuration of the "ejb"/"dist" cache but is set to cache mode REPL. There seems to be a problem with the configuration of the internally-created client-mappings cache which is causing the problems (in particular, the consistent hash for the Infinispan cache is *possibly* not being set correctly).{quote}
> {quote}
> [...] the CHF setting is the problem. It should be either set to null or ReplicatedConsistentHashFactory. What was happening was that using DefaultConsistentHashFactory (aimed for DIST caches) with a REPL cache only writes entries to numOwners nodes, but the reader thinks that the entries will be available at all nodes, resulting in null values.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 8 months
[JBoss JIRA] (ISPN-8244) ejb client-mappings cache is missing entries
by Janine Eichler (JIRA)
Janine Eichler created ISPN-8244:
------------------------------------
Summary: ejb client-mappings cache is missing entries
Key: ISPN-8244
URL: https://issues.jboss.org/browse/ISPN-8244
Project: Infinispan
Issue Type: Bug
Reporter: Janine Eichler
In JBoss EAP 7.0 the client-mappings is missing some entries which can result in incomplete cluster topologies sent to the client.
[~rachmato] already analysed (and fixed, at least locally) the problem:
{code}
A little more detail. In the EAP config, there is a cache container called "ejb" and a defaultt cache called "dist" which is used to store SFSB sessions when they are created and make them available across the cluster. This cache has, by default, cache mode DIST. The client-mappings cache, which stores node -> IP:port information for the cluster nodes, is created internally but is based on the configuration of the "ejb"/"dist" cache but is set to cache mode REPL. There seems to be a problem with the configuration of the internally-created client-mappings cache which is causing the problems (in particular, the consistent hash for the Infinispan cache is *possibly* not being set correctly).
{code}
{code}
[...] the CHF setting is the problem. It should be either set to null or ReplicatedConsistentHashFactory. What was happening was that using DefaultConsistentHashFactory (aimed for DIST caches) with a REPL cache only writes entries to numOwners nodes, but the reader thinks that the entries will be available at all nodes, resulting in null values.
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 8 months
[JBoss JIRA] (ISPN-8240) Coordinator sends REBALANCE_START command when there is already a rebalance in progress
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-8240?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-8240:
------------------------------------
This is affecting {{StateConsumerImpl}} more than I initially thought. When the second {{REBALANCE_START}} command arrives, {{SCI}} restarts the tracking of modified entries, and a write that happened during this part of state transfer can be undone by later a {{StateResponseCommand}}.
> Coordinator sends REBALANCE_START command when there is already a rebalance in progress
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-8240
> URL: https://issues.jboss.org/browse/ISPN-8240
> Project: Infinispan
> Issue Type: Bug
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
>
> Normally the {{REBALANCE_START}} command should only be sent at the start of a rebalance, and any topology updates sent before all the nodes confirm the rebalance phase should have {{CH_UPDATE}}.
> Since the change to 4 phases, this is no longer true: first {{ClusterCacheStatus.updateTopologyMembers}} first clears the {{RebalanceConfirmationCollector}}, then it broadcasts a {{CH_UPDATE}}. Then {{queueRebalance}} immediately creates a new {{RCC}} and broadcasts a {{REBALANCE_START}}, instead of waiting for the current rebalance to finish.
> I propose we remove {{REBALANCE_START}}, as it was just a crude version of {{CacheTopology.Phase}}. We should also remove the {{isRebalance}} parameter from {{StateConsumerImpl.onTopologyUpdate()}}.
> I'm still not sure if rebalancing the pending CH immediately is ok. On the one hand, I would like the rebalance to finish with {{updateMembers(union(currentCH, pendingCH))}} as the new pending CH, so that segments that were already transferred keep an extra copy. On the other hand, that would only help for segments that have at least on owner in the current CH: if the current CH has 0 owners and {{updateMembers}} allocates new ones, those new owners won't request data from the pending CH owners anyway. Fixing that case would require the coordinator to fetch the transfer status from all the nodes before removing a node from the topology. But if the coordinator knew exactly which segments were transferred, it could finish the rebalance immediately and start a new one -- so it would be more similar to the current approach.
> Note: the {{SyncConsistentHashFactory}} allocation is not 100% stable, even when nodes are not added, so A ∈ owners(segment) in topology ABCD does not guarantee that A ∈ owners(segment) in topology ABC. But it should be good enough to keep A an owner in 90% of the cases.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 8 months