[JBoss JIRA] (ISPN-2575) KeyTransformer registration is required on all nodes of the cluster, in case of custom keys
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2575?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2575:
--------------------------------
Assignee: Adrian Nistor (was: Sanne Grinovero)
> KeyTransformer registration is required on all nodes of the cluster, in case of custom keys
> -------------------------------------------------------------------------------------------
>
> Key: ISPN-2575
> URL: https://issues.jboss.org/browse/ISPN-2575
> Project: Infinispan
> Issue Type: Enhancement
> Components: Querying
> Affects Versions: 5.2.0.Beta5
> Reporter: Anna Manukyan
> Assignee: Adrian Nistor
> Attachments: ClusteredCacheTest.java
>
>
> The case is the following:
> I have a clustered cache on which I want to perform a search. I'm doing the following:
> I'm initializing SearchManager on node1, I'm registering a custom key transformer for my key using the created searchmanager, but then when I'm trying to put data into the cache on node1 (which is in REPL_SYNC mode with cache on node2), I'm getting the exception:
> java.lang.IllegalArgumentException: Indexing only works with entries keyed on Strings, primitives and classes that have the @Transformable annotation - you passed in a class org.infinispan.query.test.CustomKey3. Alternatively, see org.infinispan.query.SearchManager#registerKeyTransformer
> When I'm initializing the SearchManager using node2 cache and register the keyTransformer on it as well, then everything works perfectly, even though I am not using the second created SearchManager.
> The test which reproduces the issue is attached to the jira. Please see the test case: testSearchKeyTransformer()
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
5 days, 23 hours
[Red Hat JIRA] (ISPN-12667) GlobalState incompatibility between 11.x and 12.x
by Pedro Ruivo (Jira)
[ https://issues.redhat.com/browse/ISPN-12667?page=com.atlassian.jira.plugi... ]
Pedro Ruivo updated ISPN-12667:
-------------------------------
Resolution: Done
Status: Resolved (was: Pull Request Sent)
> GlobalState incompatibility between 11.x and 12.x
> -------------------------------------------------
>
> Key: ISPN-12667
> URL: https://issues.redhat.com/browse/ISPN-12667
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 12.0.0.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 12.1.0.Final, 12.0.1.Final
>
>
> ISPN-12221 added two additional properties to the GlobalState, however when loading these values it does not take into account that the properties may not exist. This results in the following exception in the operator when upgrading a cluster from 11.x to 12.x
> {code:java}
> 09:57:37,933 FATAL (main) [org.infinispan.SERVER] ISPN080028: Infinispan Server failed to start java.util.concurrent.ExecutionException: org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheConfigurationException: Error starting component org.infinispan.statetransfer.StateTransferManager
> at java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395)
> at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1999)
> at org.infinispan.server.Bootstrap.runInternal(Bootstrap.java:158)
> at org.infinispan.server.tool.Main.run(Main.java:98)
> at org.infinispan.server.Bootstrap.main(Bootstrap.java:46)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.infinispan.server.loader.Loader.run(Loader.java:103)
> at org.infinispan.server.loader.Loader.main(Loader.java:48)
> Caused by: org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheConfigurationException: Error starting component org.infinispan.statetransfer.StateTransferManager
> at org.infinispan.manager.DefaultCacheManager.internalStart(DefaultCacheManager.java:751)
> at org.infinispan.manager.DefaultCacheManager.start(DefaultCacheManager.java:717)
> at org.infinispan.server.SecurityActions.lambda$startCacheManager$1(SecurityActions.java:67)
> at org.infinispan.security.Security.doPrivileged(Security.java:45)
> at org.infinispan.server.SecurityActions.doPrivileged(SecurityActions.java:39)
> at org.infinispan.server.SecurityActions.startCacheManager(SecurityActions.java:70)
> at org.infinispan.server.Server.run(Server.java:347)
> ... 9 more
> Caused by: org.infinispan.commons.CacheConfigurationException: Error starting component org.infinispan.statetransfer.StateTransferManager
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.startWrapper(BasicComponentRegistryImpl.java:572)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.access$700(BasicComponentRegistryImpl.java:30)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl$ComponentWrapper.running(BasicComponentRegistryImpl.java:787)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:341)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:237)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:213)
> at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:1014)
> at org.infinispan.cache.impl.AbstractDelegatingCache.start(AbstractDelegatingCache.java:512)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:697)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:643)
> at org.infinispan.manager.DefaultCacheManager.internalGetCache(DefaultCacheManager.java:532)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:510)
> at org.infinispan.security.actions.GetCacheAction.run(GetCacheAction.java:26)
> at org.infinispan.security.actions.GetCacheAction.run(GetCacheAction.java:14)
> at org.infinispan.security.Security.doPrivileged(Security.java:50)
> at org.infinispan.globalstate.impl.SecurityActions.doPrivileged(SecurityActions.java:29)
> at org.infinispan.globalstate.impl.SecurityActions.getCache(SecurityActions.java:38)
> at org.infinispan.globalstate.impl.GlobalConfigurationManagerImpl.start(GlobalConfigurationManagerImpl.java:94)
> at org.infinispan.globalstate.impl.CorePackageImpl$2.start(CorePackageImpl.java:59)
> at org.infinispan.globalstate.impl.CorePackageImpl$2.start(CorePackageImpl.java:48)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.invokeStart(BasicComponentRegistryImpl.java:604)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.doStartWrapper(BasicComponentRegistryImpl.java:595)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.startWrapper(BasicComponentRegistryImpl.java:564)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.access$700(BasicComponentRegistryImpl.java:30)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl$ComponentWrapper.running(BasicComponentRegistryImpl.java:787)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:341)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:237)
> at org.infinispan.manager.DefaultCacheManager.internalStart(DefaultCacheManager.java:746)
> ... 15 more
> Caused by: java.util.concurrent.CompletionException: java.lang.NumberFormatException: null
> at org.infinispan.util.concurrent.CompletionStages.join(CompletionStages.java:81)
> at org.infinispan.statetransfer.StateTransferManagerImpl.start(StateTransferManagerImpl.java:134)
> at org.infinispan.statetransfer.CorePackageImpl$2.start(CorePackageImpl.java:104)
> at org.infinispan.statetransfer.CorePackageImpl$2.start(CorePackageImpl.java:83)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.invokeStart(BasicComponentRegistryImpl.java:604)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.doStartWrapper(BasicComponentRegistryImpl.java:595)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.startWrapper(BasicComponentRegistryImpl.java:564)
> ... 42 more
> Caused by: java.lang.NumberFormatException: null
> at java.base/java.lang.Integer.parseInt(Integer.java:614)
> at java.base/java.lang.Integer.parseInt(Integer.java:770)
> at org.infinispan.distribution.ch.impl.ReplicatedConsistentHash.parseMembers(ReplicatedConsistentHash.java:128)
> at org.infinispan.distribution.ch.impl.ReplicatedConsistentHash.<init>(ReplicatedConsistentHash.java:112)
> at org.infinispan.distribution.ch.impl.SyncReplicatedConsistentHashFactory.fromPersistentState(SyncReplicatedConsistentHashFactory.java:43)
> at org.infinispan.distribution.ch.impl.SyncReplicatedConsistentHashFactory.fromPersistentState(SyncReplicatedConsistentHashFactory.java:26)
> at org.infinispan.topology.ClusterCacheStatus.restoreCacheTopology(ClusterCacheStatus.java:731)
> at org.infinispan.topology.ClusterCacheStatus.doJoin(ClusterCacheStatus.java:693)
> at org.infinispan.topology.ClusterTopologyManagerImpl.lambda$handleJoin$3(ClusterTopologyManagerImpl.java:231)
> at java.base/java.util.concurrent.CompletableFuture.uniApplyNow(CompletableFuture.java:680)
> at java.base/java.util.concurrent.CompletableFuture.uniApplyStage(CompletableFuture.java:658)
> at java.base/java.util.concurrent.CompletableFuture.thenApply(CompletableFuture.java:2094)
> at java.base/java.util.concurrent.CompletableFuture.thenApply(CompletableFuture.java:143)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleJoin(ClusterTopologyManagerImpl.java:224)
> at org.infinispan.commands.topology.CacheJoinCommand.invokeAsync(CacheJoinCommand.java:42)
> at org.infinispan.topology.TopologyManagementHelper.invokeAsync(TopologyManagementHelper.java:151)
> at org.infinispan.topology.TopologyManagementHelper.executeOnCoordinator(TopologyManagementHelper.java:88)
> at org.infinispan.topology.LocalTopologyManagerImpl.sendJoinRequest(LocalTopologyManagerImpl.java:167)
> at org.infinispan.topology.LocalTopologyManagerImpl.lambda$sendJoinRequest$2(LocalTopologyManagerImpl.java:207)
> at org.infinispan.util.concurrent.CompletionStages.lambda$schedule$2(CompletionStages.java:162)
> at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
4 years, 9 months
[Red Hat JIRA] (ISPN-12538) Clustered Locks with zero-capacity throws ClassCastException
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-12538?page=com.atlassian.jira.plugi... ]
Dan Berindei resolved ISPN-12538.
---------------------------------
Resolution: Explained
The {{ClassCastException}} appears because the {{org.infinispan.LOCKS}} is not configured with the same cache mode on all the cluster members:
* Regular members have {{clustered-locks num-owners > 0}}, so they define a {{DIST_SYNC}} locks cache.
* The zero-capacity node has {{clustered-locks num-owners = -1}}, so it defines a {{REPL_SYNC}} locks cache.
We should have a better error message when a node joins with a different cache mode, but I'm not sure we need a new JIRA as we already have ISPN-4879.
> Clustered Locks with zero-capacity throws ClassCastException
> ------------------------------------------------------------
>
> Key: ISPN-12538
> URL: https://issues.redhat.com/browse/ISPN-12538
> Project: Infinispan
> Issue Type: Bug
> Components: Clustered Locks
> Affects Versions: 12.0.0.Dev07
> Reporter: Ryan Emerson
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 12.1.0.Final
>
>
> When creating a cluster with no explicit clustered-locks configuration, i.e. num_Owners is not defined, a `ClassCastException` is thrown if a zero-capacity node joins the cluster and attempts to use a lock:
> {code:java}
> 10:10:36,564 ERROR (non-blocking-thread--p2-t2) [org.infinispan.topology.LocalTopologyManagerImpl] ISPN000230: Failed to start rebalance for cache org.infinispan.LOCKS java.util.concurrent.CompletionException: java.lang.ClassCastException: class org.infinispan.distribution.ch.impl.ReplicatedConsistentHash cannot be cast to class org.infinispan.distribution.ch.impl.DefaultConsistentHash (org.infinispan.distribution.ch.impl.ReplicatedConsistentHash and org.infinispan.distribution.ch.impl.DefaultConsistentHash are in unnamed module of loader java.net.URLClassLoader @6d03e736)
> at java.base/java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:367)
> at java.base/java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:376)
> at java.base/java.util.concurrent.CompletableFuture$UniRelay.tryFire(CompletableFuture.java:1019)
> at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at org.infinispan.util.concurrent.ActionSequencer$SequenceEntry.accept(ActionSequencer.java:213)
> at org.infinispan.util.concurrent.ActionSequencer$SequenceEntry.accept(ActionSequencer.java:179)
> at java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
> at java.base/java.util.concurrent.CompletableFuture.uniWhenCompleteStage(CompletableFuture.java:883)
> at java.base/java.util.concurrent.CompletableFuture.whenComplete(CompletableFuture.java:2251)
> at java.base/java.util.concurrent.CompletableFuture.whenComplete(CompletableFuture.java:143)
> at org.infinispan.util.concurrent.ActionSequencer$SequenceEntry.run(ActionSequencer.java:227)
> at org.infinispan.util.concurrent.ActionSequencer$SequenceEntry.apply(ActionSequencer.java:219)
> at org.infinispan.util.concurrent.ActionSequencer$SequenceEntry.apply(ActionSequencer.java:179)
> at java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> at java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
> at java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.ClassCastException: class org.infinispan.distribution.ch.impl.ReplicatedConsistentHash cannot be cast to class org.infinispan.distribution.ch.impl.DefaultConsistentHash (org.infinispan.distribution.ch.impl.ReplicatedConsistentHash and org.infinispan.distribution.ch.impl.DefaultConsistentHash are in unnamed module of loader java.net.URLClassLoader @6d03e736)
> at org.infinispan.distribution.ch.impl.SyncConsistentHashFactory.union(SyncConsistentHashFactory.java:58)
> at org.infinispan.topology.LocalTopologyManagerImpl.doHandleRebalance(LocalTopologyManagerImpl.java:562)
> at org.infinispan.topology.LocalTopologyManagerImpl.lambda$handleRebalance$16(LocalTopologyManagerImpl.java:531)
> at org.infinispan.topology.LocalTopologyManagerImpl.lambda$orderOnCache$24(LocalTopologyManagerImpl.java:736)
> at org.infinispan.util.concurrent.ActionSequencer.safeNonBlockingCall(ActionSequencer.java:57)
> at org.infinispan.util.concurrent.ActionSequencer.access$400(ActionSequencer.java:32)
> at org.infinispan.util.concurrent.ActionSequencer$SequenceEntry.run(ActionSequencer.java:226)
> ... 8 more
> {code}
> Previously zero-capacity node was not supported with replicated-caches, however this is no longer the case so it should be possible for clustered-locks to work with a replicated cache without defining num_owners.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
4 years, 9 months
[Red Hat JIRA] (ISPN-12662) Functional commands break in replicated caches on zero-capacity nodes
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-12662?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-12662:
--------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/9024
Status: Pull Request Sent (was: Open)
> Functional commands break in replicated caches on zero-capacity nodes
> ---------------------------------------------------------------------
>
> Key: ISPN-12662
> URL: https://issues.redhat.com/browse/ISPN-12662
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 12.0.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 12.1.0.Final, 12.0.1.Final
>
>
> In replicated embedded caches, {{BaseDistributionInterceptor}} on the primary owner sends write commands (including functional write commands) to all the other cache members, using {{RpcManager.invokeCommandOnAll()}}. The write commands will execute on all the cache members, including zero-capacity nodes, and an exception response from any cache member will fail the operation.
> Functional commands like {{ReadWriteKeyCommand}} assume they can read the previous value for the affected key on any node where they execute. A zero-capacity node doesn't have the previous value, so it should ignore the command and pretend it was applied, but instead it wraps a {{null}} value in the invocation context and tries to invoke the lambda anyway.
> Clustered locks are affected by this issue, but it's hidden because of ISPN-12548.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
4 years, 9 months
[Red Hat JIRA] (ISPN-12671) JdbcStringBasedStore remove class variables only used in start()
by Ryan Emerson (Jira)
Ryan Emerson created ISPN-12671:
-----------------------------------
Summary: JdbcStringBasedStore remove class variables only used in start()
Key: ISPN-12671
URL: https://issues.redhat.com/browse/ISPN-12671
Project: Infinispan
Issue Type: Enhancement
Components: Loaders and Stores
Affects Versions: 12.0.0.Final
Reporter: Ryan Emerson
Assignee: Ryan Emerson
Fix For: 12.1.0.Final
The following methods are only used in the start() method and can be obtained from ctx and it saves some memory:
* globalConfiguration
* cacheName
* isDistributedCache
Saving (computed by JOL plugin):
compressed oops: 64 bytes => 56 bytes
8bytes align: 120 bytes => 96 bytes
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
4 years, 9 months
[Red Hat JIRA] (ISPN-12666) ReplicationIndexTest random failures
by Katia Aresti (Jira)
[ https://issues.redhat.com/browse/ISPN-12666?page=com.atlassian.jira.plugi... ]
Katia Aresti updated ISPN-12666:
--------------------------------
Fix Version/s: 12.0.1.Final
Resolution: Done
Status: Resolved (was: Pull Request Sent)
> ReplicationIndexTest random failures
> ------------------------------------
>
> Key: ISPN-12666
> URL: https://issues.redhat.com/browse/ISPN-12666
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 12.0.0.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Major
> Fix For: 12.0.1.Final
>
>
> {noformat}
> java.lang.AssertionError: expected:<2> but was:<0>
> at org.infinispan.client.hotrod.query.ReplicationIndexTest.assertIndexed(ReplicationIndexTest.java:149)
> at org.infinispan.client.hotrod.query.ReplicationIndexTest.testIndexingDuringStateTransfer(ReplicationIndexTest.java:145)
> at org.infinispan.commons.test.TestNGLongTestsHook.run(TestNGLongTestsHook.java:24)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> ... Removed 23 stack frames
> {noformat}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
4 years, 9 months