[JBoss JIRA] (ISPN-8721) Clustered 2nd level cache sometimes throws NullPointerException when new node starts up
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-8721?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-8721:
-----------------------------------
Description:
There is a race condition in PutFromLoadValidator as it registers itself in the component registry before it is fully initialised. You can reproduce this by running the contained app against h2 server db. First start this app with default port. Then start the app on port '8080' and make a few requests to '/add' to create data. After that send continuous requests to '/update' in order change data and trigger the cache:
for i in
{code}
{1..1000}
; do sleep 0.01; curl http://localhost:8080/update -X POST; done
{code}
Then start another instance of the app on port 8090:
{code}
java -jar test-app-0.0.1-SNAPSHOT.jar --server.port=8090
{code}
Most of the time one of the updates will fail and the logs will show the following:
{code}
2018-01-23 15:36:46 [main] DEBUG o.h.c.i.access.PutFromLoadValidator - Interceptor chain was: [org.infinispan.interceptors.InvocationContextInterceptor@407a7f2a, org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor@4ea5b703, org.infinispan.interceptors.EntryWrappingInterceptor@2a7ed1f, org.infinispan.interceptors.InvalidationInterceptor@3fa247d1, org.infinispan.interceptors.CallInterceptor@2cb2fc20]
2018-01-23 15:36:46 [main] DEBUG o.h.c.i.access.PutFromLoadValidator - New interceptor chain is: [org.infinispan.interceptors.InvocationContextInterceptor@407a7f2a, org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor@4ea5b703, org.hibernate.cache.infinispan.access.NonTxPutFromLoadInterceptor@495ee280, org.infinispan.interceptors.EntryWrappingInterceptor@2a7ed1f, org.hibernate.cache.infinispan.access.NonTxInvalidationInterceptor@4fa1c212, org.infinispan.interceptors.CallInterceptor@2cb2fc20]
2018-01-23 15:36:46 [main] TRACE o.i.manager.DefaultCacheManager - About to wire and start cache test.app.data.User-pending-puts
2018-01-23 15:36:46 [remote-thread--p2-t1] ERROR o.i.i.InvocationContextInterceptor - ISPN000136: Error executing command BeginInvalidationCommand, writing keys test.app.data.User#2
java.lang.NullPointerException: null
at org.hibernate.cache.infinispan.access.PutFromLoadValidator.beginInvalidatingWithPFER(PutFromLoadValidator.java:561)
at org.hibernate.cache.infinispan.access.PutFromLoadValidator.beginInvalidatingKey(PutFromLoadValidator.java:555)
at org.hibernate.cache.infinispan.access.NonTxPutFromLoadInterceptor.visitInvalidateCommand(NonTxPutFromLoadInterceptor.java:70)
at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:114)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitInvalidateCommand(AbstractLockingInterceptor.java:112)
at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:114)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:79)
at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:127)
at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:114)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:335)
at org.infinispan.commands.remote.BaseRpcInvokingCommand.processVisitableCommand(BaseRpcInvokingCommand.java:43)
at org.infinispan.commands.remote.SingleRpcCommand.perform(SingleRpcCommand.java:51)
at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokePerform(BasePerCacheInboundInvocationHandler.java:92)
at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:34)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
2018-01-23 15:36:47 [main] TRACE o.i.manager.DefaultCacheManager - Closing latch for cache test.app.data.User-pending-puts
{code}
was:
There is a race condition in PutFromLoadValidator as it registers itself in the component registry before it is fully initialised. You can reproduce this by running the contained app against h2 server db. First start this app with default port. Then start the app on port '8080' and make a few requests to '/add' to create data. After that send continuous requests to '/update' in order change data and trigger the cache:
for i in
{1..1000}
; do sleep 0.01; curl http://localhost:8080/update -X POST; done
Then start another instance of the app on port 8090:
java -jar test-app-0.0.1-SNAPSHOT.jar --server.port=8090
Most of the time one of the updates will fail and the logs will show the following:
2018-01-23 15:36:46 [main] DEBUG o.h.c.i.access.PutFromLoadValidator - Interceptor chain was: [org.infinispan.interceptors.InvocationContextInterceptor@407a7f2a, org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor@4ea5b703, org.infinispan.interceptors.EntryWrappingInterceptor@2a7ed1f, org.infinispan.interceptors.InvalidationInterceptor@3fa247d1, org.infinispan.interceptors.CallInterceptor@2cb2fc20]
2018-01-23 15:36:46 [main] DEBUG o.h.c.i.access.PutFromLoadValidator - New interceptor chain is: [org.infinispan.interceptors.InvocationContextInterceptor@407a7f2a, org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor@4ea5b703, org.hibernate.cache.infinispan.access.NonTxPutFromLoadInterceptor@495ee280, org.infinispan.interceptors.EntryWrappingInterceptor@2a7ed1f, org.hibernate.cache.infinispan.access.NonTxInvalidationInterceptor@4fa1c212, org.infinispan.interceptors.CallInterceptor@2cb2fc20]
2018-01-23 15:36:46 [main] TRACE o.i.manager.DefaultCacheManager - About to wire and start cache test.app.data.User-pending-puts
2018-01-23 15:36:46 [remote-thread--p2-t1] ERROR o.i.i.InvocationContextInterceptor - ISPN000136: Error executing command BeginInvalidationCommand, writing keys test.app.data.User#2
java.lang.NullPointerException: null
at org.hibernate.cache.infinispan.access.PutFromLoadValidator.beginInvalidatingWithPFER(PutFromLoadValidator.java:561)
at org.hibernate.cache.infinispan.access.PutFromLoadValidator.beginInvalidatingKey(PutFromLoadValidator.java:555)
at org.hibernate.cache.infinispan.access.NonTxPutFromLoadInterceptor.visitInvalidateCommand(NonTxPutFromLoadInterceptor.java:70)
at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:114)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitInvalidateCommand(AbstractLockingInterceptor.java:112)
at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:114)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:79)
at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:127)
at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:114)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:335)
at org.infinispan.commands.remote.BaseRpcInvokingCommand.processVisitableCommand(BaseRpcInvokingCommand.java:43)
at org.infinispan.commands.remote.SingleRpcCommand.perform(SingleRpcCommand.java:51)
at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokePerform(BasePerCacheInboundInvocationHandler.java:92)
at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:34)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
2018-01-23 15:36:47 [main] TRACE o.i.manager.DefaultCacheManager - Closing latch for cache test.app.data.User-pending-puts
Fix Version/s: 9.2.0.Final
9.2.0.CR2
> Clustered 2nd level cache sometimes throws NullPointerException when new node starts up
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-8721
> URL: https://issues.jboss.org/browse/ISPN-8721
> Project: Infinispan
> Issue Type: Bug
> Components: Hibernate Cache
> Affects Versions: 9.1.4.Final
> Environment: jvm 1.8
> Reporter: Tom Dearman
> Assignee: Tom Dearman
> Fix For: 9.2.0.Final, 9.2.0.CR2
>
> Attachments: sample-app.cache.tar.gz
>
>
> There is a race condition in PutFromLoadValidator as it registers itself in the component registry before it is fully initialised. You can reproduce this by running the contained app against h2 server db. First start this app with default port. Then start the app on port '8080' and make a few requests to '/add' to create data. After that send continuous requests to '/update' in order change data and trigger the cache:
> for i in
> {code}
> {1..1000}
> ; do sleep 0.01; curl http://localhost:8080/update -X POST; done
> {code}
> Then start another instance of the app on port 8090:
> {code}
> java -jar test-app-0.0.1-SNAPSHOT.jar --server.port=8090
> {code}
> Most of the time one of the updates will fail and the logs will show the following:
> {code}
> 2018-01-23 15:36:46 [main] DEBUG o.h.c.i.access.PutFromLoadValidator - Interceptor chain was: [org.infinispan.interceptors.InvocationContextInterceptor@407a7f2a, org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor@4ea5b703, org.infinispan.interceptors.EntryWrappingInterceptor@2a7ed1f, org.infinispan.interceptors.InvalidationInterceptor@3fa247d1, org.infinispan.interceptors.CallInterceptor@2cb2fc20]
> 2018-01-23 15:36:46 [main] DEBUG o.h.c.i.access.PutFromLoadValidator - New interceptor chain is: [org.infinispan.interceptors.InvocationContextInterceptor@407a7f2a, org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor@4ea5b703, org.hibernate.cache.infinispan.access.NonTxPutFromLoadInterceptor@495ee280, org.infinispan.interceptors.EntryWrappingInterceptor@2a7ed1f, org.hibernate.cache.infinispan.access.NonTxInvalidationInterceptor@4fa1c212, org.infinispan.interceptors.CallInterceptor@2cb2fc20]
> 2018-01-23 15:36:46 [main] TRACE o.i.manager.DefaultCacheManager - About to wire and start cache test.app.data.User-pending-puts
> 2018-01-23 15:36:46 [remote-thread--p2-t1] ERROR o.i.i.InvocationContextInterceptor - ISPN000136: Error executing command BeginInvalidationCommand, writing keys test.app.data.User#2
> java.lang.NullPointerException: null
> at org.hibernate.cache.infinispan.access.PutFromLoadValidator.beginInvalidatingWithPFER(PutFromLoadValidator.java:561)
> at org.hibernate.cache.infinispan.access.PutFromLoadValidator.beginInvalidatingKey(PutFromLoadValidator.java:555)
> at org.hibernate.cache.infinispan.access.NonTxPutFromLoadInterceptor.visitInvalidateCommand(NonTxPutFromLoadInterceptor.java:70)
> at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:114)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitInvalidateCommand(AbstractLockingInterceptor.java:112)
> at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:114)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:79)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:127)
> at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:114)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:335)
> at org.infinispan.commands.remote.BaseRpcInvokingCommand.processVisitableCommand(BaseRpcInvokingCommand.java:43)
> at org.infinispan.commands.remote.SingleRpcCommand.perform(SingleRpcCommand.java:51)
> at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokePerform(BasePerCacheInboundInvocationHandler.java:92)
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:34)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> 2018-01-23 15:36:47 [main] TRACE o.i.manager.DefaultCacheManager - Closing latch for cache test.app.data.User-pending-puts
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (ISPN-8721) Clustered 2nd level cache sometimes throws NullPointerException when new node starts up
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-8721?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-8721:
-----------------------------------
Status: Open (was: New)
> Clustered 2nd level cache sometimes throws NullPointerException when new node starts up
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-8721
> URL: https://issues.jboss.org/browse/ISPN-8721
> Project: Infinispan
> Issue Type: Bug
> Components: Hibernate Cache
> Affects Versions: 9.1.4.Final
> Environment: jvm 1.8
> Reporter: Tom Dearman
> Attachments: sample-app.cache.tar.gz
>
>
> There is a race condition in PutFromLoadValidator as it registers itself in the component registry before it is fully initialised. You can reproduce this by running the contained app against h2 server db. First start this app with default port. Then start the app on port '8080' and make a few requests to '/add' to create data. After that send continuous requests to '/update' in order change data and trigger the cache:
> for i in
> {1..1000}
> ; do sleep 0.01; curl http://localhost:8080/update -X POST; done
> Then start another instance of the app on port 8090:
> java -jar test-app-0.0.1-SNAPSHOT.jar --server.port=8090
> Most of the time one of the updates will fail and the logs will show the following:
> 2018-01-23 15:36:46 [main] DEBUG o.h.c.i.access.PutFromLoadValidator - Interceptor chain was: [org.infinispan.interceptors.InvocationContextInterceptor@407a7f2a, org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor@4ea5b703, org.infinispan.interceptors.EntryWrappingInterceptor@2a7ed1f, org.infinispan.interceptors.InvalidationInterceptor@3fa247d1, org.infinispan.interceptors.CallInterceptor@2cb2fc20]
> 2018-01-23 15:36:46 [main] DEBUG o.h.c.i.access.PutFromLoadValidator - New interceptor chain is: [org.infinispan.interceptors.InvocationContextInterceptor@407a7f2a, org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor@4ea5b703, org.hibernate.cache.infinispan.access.NonTxPutFromLoadInterceptor@495ee280, org.infinispan.interceptors.EntryWrappingInterceptor@2a7ed1f, org.hibernate.cache.infinispan.access.NonTxInvalidationInterceptor@4fa1c212, org.infinispan.interceptors.CallInterceptor@2cb2fc20]
> 2018-01-23 15:36:46 [main] TRACE o.i.manager.DefaultCacheManager - About to wire and start cache test.app.data.User-pending-puts
> 2018-01-23 15:36:46 [remote-thread--p2-t1] ERROR o.i.i.InvocationContextInterceptor - ISPN000136: Error executing command BeginInvalidationCommand, writing keys test.app.data.User#2
> java.lang.NullPointerException: null
> at org.hibernate.cache.infinispan.access.PutFromLoadValidator.beginInvalidatingWithPFER(PutFromLoadValidator.java:561)
> at org.hibernate.cache.infinispan.access.PutFromLoadValidator.beginInvalidatingKey(PutFromLoadValidator.java:555)
> at org.hibernate.cache.infinispan.access.NonTxPutFromLoadInterceptor.visitInvalidateCommand(NonTxPutFromLoadInterceptor.java:70)
> at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:114)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitInvalidateCommand(AbstractLockingInterceptor.java:112)
> at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:114)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:79)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:127)
> at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:114)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:335)
> at org.infinispan.commands.remote.BaseRpcInvokingCommand.processVisitableCommand(BaseRpcInvokingCommand.java:43)
> at org.infinispan.commands.remote.SingleRpcCommand.perform(SingleRpcCommand.java:51)
> at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokePerform(BasePerCacheInboundInvocationHandler.java:92)
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:34)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> 2018-01-23 15:36:47 [main] TRACE o.i.manager.DefaultCacheManager - Closing latch for cache test.app.data.User-pending-puts
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (ISPN-7599) Add Jolokia to the server
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-7599?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes commented on ISPN-7599:
-----------------------------------------
[~vblagojevic] There were quite a few PRs attached to this JIRA, so I left it opened.
> Add Jolokia to the server
> -------------------------
>
> Key: ISPN-7599
> URL: https://issues.jboss.org/browse/ISPN-7599
> Project: Infinispan
> Issue Type: Feature Request
> Components: Cloud, Server
> Reporter: Sebastian Łaskawiec
> Assignee: Vladimir Blagojevic
> Priority: Critical
> Fix For: 9.2.0.Final
>
>
> The server should support exposing [Jolokia|https://jolokia.org] endpoints. The support should be disabled by default and there should be possibility to enable it using an environmental variable.
> OpenShift has special Administration Console for Jolokia-enabled endpoints.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (ISPN-8724) HotRodRemoteStreamingIT hangs
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-8724?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes commented on ISPN-8724:
-----------------------------------------
[~pruivo] [~NadirX] Looks like a race between the Counter Lifecycle manager and the internal registry cleanup during server stops
> HotRodRemoteStreamingIT hangs
> -----------------------------
>
> Key: ISPN-8724
> URL: https://issues.jboss.org/browse/ISPN-8724
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.2.0.CR1
> Reporter: Gustavo Fernandes
> Priority: Critical
> Attachments: s1, s2, test
>
>
> This was observed during the execution of test {{HotRodRemoteStreamingIT}}, Line 499 on method stopServer().
> The surefire process waits forever for the two servers to stop.
> One of the servers is waiting for the initial state transfer to complete:
> {noformat}
> "Thread-48" #95 prio=5 os_prio=0 tid=0x00007fdaf48f69f0 nid=0x590a waiting on condition [0x00007fdae1a26000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000ee8cfc00> (a java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:231)
> 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.SecurityActions.lambda$invokeAccessibly$0(SecurityActions.java:79)
> at org.infinispan.commons.util.SecurityActions$$Lambda$170/1509149284.run(Unknown Source)
> at org.infinispan.commons.util.SecurityActions.doPrivileged(SecurityActions.java:71)
> at org.infinispan.commons.util.SecurityActions.invokeAccessibly(SecurityActions.java:76)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:968)
> at org.infinispan.factories.AbstractComponentRegistry.lambda$invokePrioritizedMethods$6(AbstractComponentRegistry.java:703)
> at org.infinispan.factories.AbstractComponentRegistry$$Lambda$175/1225674479.run(Unknown Source)
> at org.infinispan.factories.SecurityActions.lambda$run$1(SecurityActions.java:72)
> at org.infinispan.factories.SecurityActions$$Lambda$176/1784470267.run(Unknown Source)
> at org.infinispan.security.Security.doPrivileged(Security.java:76)
> at org.infinispan.factories.SecurityActions.run(SecurityActions.java:71)
> at org.infinispan.factories.AbstractComponentRegistry.invokePrioritizedMethods(AbstractComponentRegistry.java:696)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:689)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:607)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:228)
> at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:962)
> at org.infinispan.cache.impl.AbstractDelegatingCache.start(AbstractDelegatingCache.java:411)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:637)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:582)
> at org.infinispan.manager.DefaultCacheManager.internalGetCache(DefaultCacheManager.java:468)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:454)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:440)
> at org.infinispan.counter.impl.CounterModuleLifecycle.lambda$startCaches$0(CounterModuleLifecycle.java:132)
> at org.infinispan.counter.impl.CounterModuleLifecycle$$Lambda$194/218224883.run(Unknown Source)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The other server is running a series of operations after the server stops, such
> as {{EmbeddedCacheManager#undefineConfiguration}}, this can be seen on 3 threads:
> MSC service thread 1-1, MSC service thread 1-2 and MSC service thread 1-3
> {noformat}
> "MSC service thread 1-1" #12 prio=5 os_prio=0 tid=0x00007fd4e86720a0 nid=0x56f1 waiting on condition [0x00007fd4bc8f2000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000fb922a18> (a java.util.concurrent.CompletableFuture$Signaller)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.CompletableFuture$Signaller.block(CompletableFuture.java:1693)
> at java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3323)
> at java.util.concurrent.CompletableFuture.waitingGet(CompletableFuture.java:1729)
> at java.util.concurrent.CompletableFuture.join(CompletableFuture.java:1934)
> at org.infinispan.manager.DefaultCacheManager.undefineConfiguration(DefaultCacheManager.java:394)
> at org.infinispan.security.actions.UndefineConfigurationAction.run(UndefineConfigurationAction.java:25)
> at org.infinispan.security.actions.UndefineConfigurationAction.run(UndefineConfigurationAction.java:13)
> at org.infinispan.security.Security.doPrivileged(Security.java:76)
> at org.infinispan.registry.impl.SecurityActions.undefineConfiguration(SecurityActions.java:39)
> at org.infinispan.registry.impl.InternalCacheRegistryImpl.unregisterInternalCache(InternalCacheRegistryImpl.java:77)
> - locked <0x00000000ee2e1420> (a org.infinispan.registry.impl.InternalCacheRegistryImpl)
> at org.infinispan.server.hotrod.HotRodServer.stop(HotRodServer.java:486)
> at org.infinispan.server.endpoint.subsystem.ProtocolServerService.doStop(ProtocolServerService.java:216)
> at org.infinispan.server.endpoint.subsystem.ProtocolServerService.stop(ProtocolServerService.java:206)
> - locked <0x00000000edd0eae0> (a org.infinispan.server.endpoint.subsystem.ProtocolServerService)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> For some reason, also in the other server, the CounterModule lifecycle is reacting to a
> cache manager start event, and it's hanged as well:
> {noformat}
> "Thread-48" #95 prio=5 os_prio=0 tid=0x00007fd4986a2090 nid=0x575b waiting on condition [0x00007fd48f2f4000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000ee91b048> (a java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:231)
> 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.SecurityActions.lambda$invokeAccessibly$0(SecurityActions.java:79)
> at org.infinispan.commons.util.SecurityActions$$Lambda$170/1758042552.run(Unknown Source)
> at org.infinispan.commons.util.SecurityActions.doPrivileged(SecurityActions.java:71)
> at org.infinispan.commons.util.SecurityActions.invokeAccessibly(SecurityActions.java:76)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:968)
> at org.infinispan.factories.AbstractComponentRegistry.lambda$invokePrioritizedMethods$6(AbstractComponentRegistry.java:703)
> at org.infinispan.factories.AbstractComponentRegistry$$Lambda$175/1042194083.run(Unknown Source)
> at org.infinispan.factories.SecurityActions.lambda$run$1(SecurityActions.java:72)
> at org.infinispan.factories.SecurityActions$$Lambda$176/2118421355.run(Unknown Source)
> at org.infinispan.security.Security.doPrivileged(Security.java:76)
> at org.infinispan.factories.SecurityActions.run(SecurityActions.java:71)
> at org.infinispan.factories.AbstractComponentRegistry.invokePrioritizedMethods(AbstractComponentRegistry.java:696)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:689)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:607)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:228)
> at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:962)
> at org.infinispan.cache.impl.AbstractDelegatingCache.start(AbstractDelegatingCache.java:411)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:637)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:582)
> at org.infinispan.manager.DefaultCacheManager.internalGetCache(DefaultCacheManager.java:468)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:454)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:440)
> at org.infinispan.counter.impl.CounterModuleLifecycle.lambda$startCaches$0(CounterModuleLifecycle.java:132)
> at org.infinispan.counter.impl.CounterModuleLifecycle$$Lambda$194/1023465788.run(Unknown Source)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (ISPN-8724) HotRodRemoteStreamingIT hangs
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-8724?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-8724:
------------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/5699, https://github.com/infinispan/infinispan/pull/5702 (was: https://github.com/infinispan/infinispan/pull/5699)
> HotRodRemoteStreamingIT hangs
> -----------------------------
>
> Key: ISPN-8724
> URL: https://issues.jboss.org/browse/ISPN-8724
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.2.0.CR1
> Reporter: Gustavo Fernandes
> Priority: Critical
> Attachments: s1, s2, test
>
>
> This was observed during the execution of test {{HotRodRemoteStreamingIT}}, Line 499 on method stopServer().
> The surefire process waits forever for the two servers to stop.
> One of the servers is waiting for the initial state transfer to complete:
> {noformat}
> "Thread-48" #95 prio=5 os_prio=0 tid=0x00007fdaf48f69f0 nid=0x590a waiting on condition [0x00007fdae1a26000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000ee8cfc00> (a java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:231)
> 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.SecurityActions.lambda$invokeAccessibly$0(SecurityActions.java:79)
> at org.infinispan.commons.util.SecurityActions$$Lambda$170/1509149284.run(Unknown Source)
> at org.infinispan.commons.util.SecurityActions.doPrivileged(SecurityActions.java:71)
> at org.infinispan.commons.util.SecurityActions.invokeAccessibly(SecurityActions.java:76)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:968)
> at org.infinispan.factories.AbstractComponentRegistry.lambda$invokePrioritizedMethods$6(AbstractComponentRegistry.java:703)
> at org.infinispan.factories.AbstractComponentRegistry$$Lambda$175/1225674479.run(Unknown Source)
> at org.infinispan.factories.SecurityActions.lambda$run$1(SecurityActions.java:72)
> at org.infinispan.factories.SecurityActions$$Lambda$176/1784470267.run(Unknown Source)
> at org.infinispan.security.Security.doPrivileged(Security.java:76)
> at org.infinispan.factories.SecurityActions.run(SecurityActions.java:71)
> at org.infinispan.factories.AbstractComponentRegistry.invokePrioritizedMethods(AbstractComponentRegistry.java:696)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:689)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:607)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:228)
> at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:962)
> at org.infinispan.cache.impl.AbstractDelegatingCache.start(AbstractDelegatingCache.java:411)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:637)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:582)
> at org.infinispan.manager.DefaultCacheManager.internalGetCache(DefaultCacheManager.java:468)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:454)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:440)
> at org.infinispan.counter.impl.CounterModuleLifecycle.lambda$startCaches$0(CounterModuleLifecycle.java:132)
> at org.infinispan.counter.impl.CounterModuleLifecycle$$Lambda$194/218224883.run(Unknown Source)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The other server is running a series of operations after the server stops, such
> as {{EmbeddedCacheManager#undefineConfiguration}}, this can be seen on 3 threads:
> MSC service thread 1-1, MSC service thread 1-2 and MSC service thread 1-3
> {noformat}
> "MSC service thread 1-1" #12 prio=5 os_prio=0 tid=0x00007fd4e86720a0 nid=0x56f1 waiting on condition [0x00007fd4bc8f2000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000fb922a18> (a java.util.concurrent.CompletableFuture$Signaller)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.CompletableFuture$Signaller.block(CompletableFuture.java:1693)
> at java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3323)
> at java.util.concurrent.CompletableFuture.waitingGet(CompletableFuture.java:1729)
> at java.util.concurrent.CompletableFuture.join(CompletableFuture.java:1934)
> at org.infinispan.manager.DefaultCacheManager.undefineConfiguration(DefaultCacheManager.java:394)
> at org.infinispan.security.actions.UndefineConfigurationAction.run(UndefineConfigurationAction.java:25)
> at org.infinispan.security.actions.UndefineConfigurationAction.run(UndefineConfigurationAction.java:13)
> at org.infinispan.security.Security.doPrivileged(Security.java:76)
> at org.infinispan.registry.impl.SecurityActions.undefineConfiguration(SecurityActions.java:39)
> at org.infinispan.registry.impl.InternalCacheRegistryImpl.unregisterInternalCache(InternalCacheRegistryImpl.java:77)
> - locked <0x00000000ee2e1420> (a org.infinispan.registry.impl.InternalCacheRegistryImpl)
> at org.infinispan.server.hotrod.HotRodServer.stop(HotRodServer.java:486)
> at org.infinispan.server.endpoint.subsystem.ProtocolServerService.doStop(ProtocolServerService.java:216)
> at org.infinispan.server.endpoint.subsystem.ProtocolServerService.stop(ProtocolServerService.java:206)
> - locked <0x00000000edd0eae0> (a org.infinispan.server.endpoint.subsystem.ProtocolServerService)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> For some reason, also in the other server, the CounterModule lifecycle is reacting to a
> cache manager start event, and it's hanged as well:
> {noformat}
> "Thread-48" #95 prio=5 os_prio=0 tid=0x00007fd4986a2090 nid=0x575b waiting on condition [0x00007fd48f2f4000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000ee91b048> (a java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:231)
> 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.SecurityActions.lambda$invokeAccessibly$0(SecurityActions.java:79)
> at org.infinispan.commons.util.SecurityActions$$Lambda$170/1758042552.run(Unknown Source)
> at org.infinispan.commons.util.SecurityActions.doPrivileged(SecurityActions.java:71)
> at org.infinispan.commons.util.SecurityActions.invokeAccessibly(SecurityActions.java:76)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:968)
> at org.infinispan.factories.AbstractComponentRegistry.lambda$invokePrioritizedMethods$6(AbstractComponentRegistry.java:703)
> at org.infinispan.factories.AbstractComponentRegistry$$Lambda$175/1042194083.run(Unknown Source)
> at org.infinispan.factories.SecurityActions.lambda$run$1(SecurityActions.java:72)
> at org.infinispan.factories.SecurityActions$$Lambda$176/2118421355.run(Unknown Source)
> at org.infinispan.security.Security.doPrivileged(Security.java:76)
> at org.infinispan.factories.SecurityActions.run(SecurityActions.java:71)
> at org.infinispan.factories.AbstractComponentRegistry.invokePrioritizedMethods(AbstractComponentRegistry.java:696)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:689)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:607)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:228)
> at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:962)
> at org.infinispan.cache.impl.AbstractDelegatingCache.start(AbstractDelegatingCache.java:411)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:637)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:582)
> at org.infinispan.manager.DefaultCacheManager.internalGetCache(DefaultCacheManager.java:468)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:454)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:440)
> at org.infinispan.counter.impl.CounterModuleLifecycle.lambda$startCaches$0(CounterModuleLifecycle.java:132)
> at org.infinispan.counter.impl.CounterModuleLifecycle$$Lambda$194/1023465788.run(Unknown Source)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (ISPN-8722) Impossible to create replicated/distributed cache configuration based on scattered cache configuration
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-8722?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated ISPN-8722:
-------------------------------
Description:
Consider an existing scattered cache configuration.
Configuration scatteredConfig = ...;
ConfigurationBuilder builder = new ConfigurationBuilder().read(scatteredConfig);
builder.clustering().cacheMode(CacheMode.DIST_SYNC);
Configuration distConfig = builder.build();
This throws:
{noformat}
org.infinispan.commons.CacheConfigurationException: ISPN000468: Invalidation batch size configuration options applies only to scattered caches.
at org.infinispan.configuration.cache.ClusteringConfigurationBuilder.validate(ClusteringConfigurationBuilder.java:135)
at org.infinispan.configuration.cache.ConfigurationBuilder.validate(ConfigurationBuilder.java:226)
at org.infinispan.configuration.cache.ConfigurationBuilder.build(ConfigurationBuilder.java:283)
at org.infinispan.configuration.cache.ConfigurationBuilder.build(ConfigurationBuilder.java:273)
{noformat}
The validation logic of ClusteringConfigurationBuilder specifically requires the invalidationBatchSize attribute to be unset. However, there is no way to "unset" an attribute.
https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o...
The same issue applies to the biasAcquisition and biasLifespan attributes in 9.2.x.
Any reason not to expose an public AttributeSet attributes() method to all configuration builders? It looks like the AttributeDefintions are all public, as are the Attribute and AttributeSet objects. That way any configuration builder can easily reset a configuration attribute to its default. WDYT?
was:
Consider an existing scattered cache configuration.
Configuration scatteredConfig = ...;
ConfigurationBuilder builder = new ConfigurationBuilder().read(scatteredConfig);
builder.clustering().cacheMode(CacheMode.DIST_SYNC);
Configuration distConfig = builder.build();
This throws:
{noformat}
org.infinispan.commons.CacheConfigurationException: ISPN000468: Invalidation batch size configuration options applies only to scattered caches.
at org.infinispan.configuration.cache.ClusteringConfigurationBuilder.validate(ClusteringConfigurationBuilder.java:135)
at org.infinispan.configuration.cache.ConfigurationBuilder.validate(ConfigurationBuilder.java:226)
at org.infinispan.configuration.cache.ConfigurationBuilder.build(ConfigurationBuilder.java:283)
at org.infinispan.configuration.cache.ConfigurationBuilder.build(ConfigurationBuilder.java:273)
{noformat}
The validation logic of ClusteringConfigurationBuilder specifically requires the invalidationBatchSize attribute to be unset. However, there is no way to "unset" an attribute.
https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o...
The same issue applies to the biasAcquisition and biasLifespan attributes in 9.2.x.
> Impossible to create replicated/distributed cache configuration based on scattered cache configuration
> ------------------------------------------------------------------------------------------------------
>
> Key: ISPN-8722
> URL: https://issues.jboss.org/browse/ISPN-8722
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.2.0.CR1, 9.1.4.Final
> Reporter: Paul Ferraro
>
> Consider an existing scattered cache configuration.
> Configuration scatteredConfig = ...;
> ConfigurationBuilder builder = new ConfigurationBuilder().read(scatteredConfig);
> builder.clustering().cacheMode(CacheMode.DIST_SYNC);
> Configuration distConfig = builder.build();
> This throws:
> {noformat}
> org.infinispan.commons.CacheConfigurationException: ISPN000468: Invalidation batch size configuration options applies only to scattered caches.
> at org.infinispan.configuration.cache.ClusteringConfigurationBuilder.validate(ClusteringConfigurationBuilder.java:135)
> at org.infinispan.configuration.cache.ConfigurationBuilder.validate(ConfigurationBuilder.java:226)
> at org.infinispan.configuration.cache.ConfigurationBuilder.build(ConfigurationBuilder.java:283)
> at org.infinispan.configuration.cache.ConfigurationBuilder.build(ConfigurationBuilder.java:273)
> {noformat}
> The validation logic of ClusteringConfigurationBuilder specifically requires the invalidationBatchSize attribute to be unset. However, there is no way to "unset" an attribute.
> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o...
> The same issue applies to the biasAcquisition and biasLifespan attributes in 9.2.x.
> Any reason not to expose an public AttributeSet attributes() method to all configuration builders? It looks like the AttributeDefintions are all public, as are the Attribute and AttributeSet objects. That way any configuration builder can easily reset a configuration attribute to its default. WDYT?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months