[Red Hat JIRA] (ISPN-12710) IllegalArgumentException in VoidResponseCollector: Self-suppression not permitted
by Ryan Emerson (Jira)
[ https://issues.redhat.com/browse/ISPN-12710?page=com.atlassian.jira.plugi... ]
Ryan Emerson updated ISPN-12710:
--------------------------------
Fix Version/s: 12.0.1.Final
> IllegalArgumentException in VoidResponseCollector: Self-suppression not permitted
> ---------------------------------------------------------------------------------
>
> Key: ISPN-12710
> URL: https://issues.redhat.com/browse/ISPN-12710
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 12.1.0.Final, 12.0.1.Final
>
>
> Since the ISPN-12662 fix {{ConsistentReliabilitySplitBrainTest.testLockUseAfterPartitionWithMajority}} is failing in CI:
> {noformat}
> 16:24:32,401 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.lock.ConsistentReliabilitySplitBrainTest.testAutoReleaseIfLockIsAcquiredFromAMinorityPartition[DENY_READ_WRITES]
> java.lang.Error: java.util.concurrent.ExecutionException: org.infinispan.lock.exception.ClusteredLockException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from Test-NodeD, see cause for remote stack trace
> at org.infinispan.functional.FunctionalTestUtils.await(FunctionalTestUtils.java:67) ~[infinispan-core-12.1.0-SNAPSHOT-tests.jar:12.1.0-SNAPSHOT]
> at org.infinispan.lock.ConsistentReliabilitySplitBrainTest.testAutoReleaseIfLockIsAcquiredFromAMinorityPartition(ConsistentReliabilitySplitBrainTest.java:133) ~[test-classes/:?]
> {noformat}
> That fix replaced a usage of {{MapResponseCollector}} with {{VoidResponseCollector}}, which makes sense because the response values are ignored. The problem is that {{VoidResponseCollector}} tries to keep track of the exceptions received from all the targets by adding them as suppressed exceptions to the first received exception, and {{ThrowableExternalizer}} reuses {{OutdatedTopologyException}} instances, causing an {{IllegalArgumentException}}:
> {noformat}
> 16:24:32,380 ERROR (jgroups-12,Test-NodeD:[]) [InvocationContextInterceptor] ISPN000136: Error executing command ReadWriteKeyCommand on Cache 'org.infinispan.LOCKS', writing keys [ClusteredLockKey{name=Test}]
> java.lang.IllegalArgumentException: Self-suppression not permitted
> at java.lang.Throwable.addSuppressed(Throwable.java:1066) ~[?:?]
> at org.infinispan.remoting.transport.impl.VoidResponseCollector.recordException(VoidResponseCollector.java:54) ~[infinispan-core-12.1.0-SNAPSHOT.jar:12.1.0-SNAPSHOT]
> at org.infinispan.remoting.transport.impl.VoidResponseCollector.addException(VoidResponseCollector.java:46) ~[infinispan-core-12.1.0-SNAPSHOT.jar:12.1.0-SNAPSHOT]
> at org.infinispan.remoting.transport.impl.VoidResponseCollector.addException(VoidResponseCollector.java:18) ~[infinispan-core-12.1.0-SNAPSHOT.jar:12.1.0-SNAPSHOT]
> at org.infinispan.remoting.transport.ValidResponseCollector.addResponse(ValidResponseCollector.java:29) ~[infinispan-core-12.1.0-SNAPSHOT.jar:12.1.0-SNAPSHOT]
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onResponse(MultiTargetRequest.java:92) [infinispan-core-12.1.0-SNAPSHOT.jar:12.1.0-SNAPSHOT]
> at org.infinispan.remoting.transport.impl.RequestRepository.addResponse(RequestRepository.java:51) [infinispan-core-12.1.0-SNAPSHOT.jar:12.1.0-SNAPSHOT]
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.processResponse(JGroupsTransport.java:1407) [infinispan-core-12.1.0-SNAPSHOT.jar:12.1.0-SNAPSHOT]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 10 months
[Red Hat JIRA] (ISPN-12715) Conflict resolution failure logged at debug level
by Dan Berindei (Jira)
Dan Berindei created ISPN-12715:
-----------------------------------
Summary: Conflict resolution failure logged at debug level
Key: ISPN-12715
URL: https://issues.redhat.com/browse/ISPN-12715
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 12.0.0.Final, 11.0.9.Final
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 12.1.0.Final, 11.0.10.Final
When conflict resolution fails, an ambiguous error message is logged, and the details are only logged at the debug level:
{noformat}
13:11:27,305+0100 ERROR [org.infinispan.conflict.impl.DefaultConflictManager] (non-blocking-thread--p2-t1) Cache org.infinispan.AdvancedCache encountered exception whilst trying to resolve conflicts on merge: java.util.concurrent.CompletionException: java.lang.IllegalArgumentException: Cannot create a transactional context without a valid Transaction instance.
13:11:27,307+0100 DEBUG [org.infinispan.CLUSTER] (non-blocking-thread--p2-t1) ISPN000524: Conflict resolution failed for cache C with topology CacheTopology{id=50, phase=CONFLICT_RESOLUTION, rebalanceId=15, currentCH=DefaultConsistentHash{ns=256, owners = (3)[D-32271: 128+128, C-48322: 64+64, A-7433: 64+64]}, pendingCH=null, unionCH=null, actualMembers=[D-32271, C-48322, A-7433], persistentUUIDs=[00355068-c9b0-465f-9be8-3bb214f7af74, 8a353c3d-8d9f-41b4-a3ae-81cb15336e0a, 07936251-a5c8-480b-ad24-fa6b804c60c5]}: java.lang.IllegalArgumentException: Cannot create a transactional context without a valid Transaction instance.
at org.infinispan.context.impl.TransactionalInvocationContextFactory.createInvocationContext(TransactionalInvocationContextFactory.java:63) [infinispan-core-11.0.9.Final-redhat-00001.jar:11.0.9.Final-redhat-00001]
at org.infinispan.cache.impl.InvocationHelper.createInvocationContextWithImplicitTransaction(InvocationHelper.java:174) [infinispan-core-11.0.9.Final-redhat-00001.jar:11.0.9.Final-redhat-00001]
at org.infinispan.cache.impl.InvocationHelper.lambda$new$0(InvocationHelper.java:47) [infinispan-core-11.0.9.Final-redhat-00001.jar:11.0.9.Final-redhat-00001]
at org.infinispan.cache.impl.DecoratedCache.writeContext(DecoratedCache.java:740) [infinispan-core-11.0.9.Final-redhat-00001.jar:11.0.9.Final-redhat-00001]
at org.infinispan.cache.impl.InvocationHelper.invokeAsync(InvocationHelper.java:129) [infinispan-core-11.0.9.Final-redhat-00001.jar:11.0.9.Final-redhat-00001]
at org.infinispan.cache.impl.CacheImpl.putAsync(CacheImpl.java:1398) [infinispan-core-11.0.9.Final-redhat-00001.jar:11.0.9.Final-redhat-00001]
at org.infinispan.cache.impl.DecoratedCache.putAsync(DecoratedCache.java:683) [infinispan-core-11.0.9.Final-redhat-00001.jar:11.0.9.Final-redhat-00001]
at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.putAsync(AbstractDelegatingAdvancedCache.java:338) [infinispan-core-11.0.9.Final-redhat-00001.jar:11.0.9.Final-redhat-00001]
at org.infinispan.cache.impl.EncoderCache.putAsync(EncoderCache.java:456) [infinispan-core-11.0.9.Final-redhat-00001.jar:11.0.9.Final-redhat-00001]
at org.infinispan.conflict.impl.DefaultConflictManager.lambda$doResolveConflicts$7(DefaultConflictManager.java:324) [infinispan-core-11.0.9.Final-redhat-00001.jar:11.0.9.Final-redhat-00001]
at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183) [rt.jar:1.8.0_275]
at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) [rt.jar:1.8.0_275]
at org.infinispan.conflict.impl.DefaultConflictManager$ReplicaSpliterator.tryAdvance(DefaultConflictManager.java:498) [infinispan-core-11.0.9.Final-redhat-00001.jar:11.0.9.Final-redhat-00001]
at java.util.Spliterator.forEachRemaining(Spliterator.java:326) [rt.jar:1.8.0_275]
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482) [rt.jar:1.8.0_275]
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472) [rt.jar:1.8.0_275]
at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150) [rt.jar:1.8.0_275]
at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173) [rt.jar:1.8.0_275]
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) [rt.jar:1.8.0_275]
at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485) [rt.jar:1.8.0_275]
at org.infinispan.conflict.impl.DefaultConflictManager.doResolveConflicts(DefaultConflictManager.java:282) [infinispan-core-11.0.9.Final-redhat-00001.jar:11.0.9.Final-redhat-00001]
at org.infinispan.conflict.impl.DefaultConflictManager.lambda$resolveConflicts$1(DefaultConflictManager.java:249) [infinispan-core-11.0.9.Final-redhat-00001.jar:11.0.9.Final-redhat-00001]
{noformat}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 10 months
[Red Hat JIRA] (ISPN-12710) IllegalArgumentException in VoidResponseCollector: Self-suppression not permitted
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-12710?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-12710:
--------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/9042
Status: Pull Request Sent (was: Open)
> IllegalArgumentException in VoidResponseCollector: Self-suppression not permitted
> ---------------------------------------------------------------------------------
>
> Key: ISPN-12710
> URL: https://issues.redhat.com/browse/ISPN-12710
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 12.1.0.Final
>
>
> Since the ISPN-12662 fix {{ConsistentReliabilitySplitBrainTest.testLockUseAfterPartitionWithMajority}} is failing in CI:
> {noformat}
> 16:24:32,401 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.lock.ConsistentReliabilitySplitBrainTest.testAutoReleaseIfLockIsAcquiredFromAMinorityPartition[DENY_READ_WRITES]
> java.lang.Error: java.util.concurrent.ExecutionException: org.infinispan.lock.exception.ClusteredLockException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from Test-NodeD, see cause for remote stack trace
> at org.infinispan.functional.FunctionalTestUtils.await(FunctionalTestUtils.java:67) ~[infinispan-core-12.1.0-SNAPSHOT-tests.jar:12.1.0-SNAPSHOT]
> at org.infinispan.lock.ConsistentReliabilitySplitBrainTest.testAutoReleaseIfLockIsAcquiredFromAMinorityPartition(ConsistentReliabilitySplitBrainTest.java:133) ~[test-classes/:?]
> {noformat}
> That fix replaced a usage of {{MapResponseCollector}} with {{VoidResponseCollector}}, which makes sense because the response values are ignored. The problem is that {{VoidResponseCollector}} tries to keep track of the exceptions received from all the targets by adding them as suppressed exceptions to the first received exception, and {{ThrowableExternalizer}} reuses {{OutdatedTopologyException}} instances, causing an {{IllegalArgumentException}}:
> {noformat}
> 16:24:32,380 ERROR (jgroups-12,Test-NodeD:[]) [InvocationContextInterceptor] ISPN000136: Error executing command ReadWriteKeyCommand on Cache 'org.infinispan.LOCKS', writing keys [ClusteredLockKey{name=Test}]
> java.lang.IllegalArgumentException: Self-suppression not permitted
> at java.lang.Throwable.addSuppressed(Throwable.java:1066) ~[?:?]
> at org.infinispan.remoting.transport.impl.VoidResponseCollector.recordException(VoidResponseCollector.java:54) ~[infinispan-core-12.1.0-SNAPSHOT.jar:12.1.0-SNAPSHOT]
> at org.infinispan.remoting.transport.impl.VoidResponseCollector.addException(VoidResponseCollector.java:46) ~[infinispan-core-12.1.0-SNAPSHOT.jar:12.1.0-SNAPSHOT]
> at org.infinispan.remoting.transport.impl.VoidResponseCollector.addException(VoidResponseCollector.java:18) ~[infinispan-core-12.1.0-SNAPSHOT.jar:12.1.0-SNAPSHOT]
> at org.infinispan.remoting.transport.ValidResponseCollector.addResponse(ValidResponseCollector.java:29) ~[infinispan-core-12.1.0-SNAPSHOT.jar:12.1.0-SNAPSHOT]
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onResponse(MultiTargetRequest.java:92) [infinispan-core-12.1.0-SNAPSHOT.jar:12.1.0-SNAPSHOT]
> at org.infinispan.remoting.transport.impl.RequestRepository.addResponse(RequestRepository.java:51) [infinispan-core-12.1.0-SNAPSHOT.jar:12.1.0-SNAPSHOT]
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.processResponse(JGroupsTransport.java:1407) [infinispan-core-12.1.0-SNAPSHOT.jar:12.1.0-SNAPSHOT]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 10 months
[Red Hat JIRA] (ISPN-12714) Cluster locks can stay locked by crashed nodes
by Dan Berindei (Jira)
Dan Berindei created ISPN-12714:
-----------------------------------
Summary: Cluster locks can stay locked by crashed nodes
Key: ISPN-12714
URL: https://issues.redhat.com/browse/ISPN-12714
Project: Infinispan
Issue Type: Bug
Components: Clustered Locks
Affects Versions: 12.0.0.Final
Reporter: Dan Berindei
Fix For: 12.1.0.Final
When the node that owns a clustered lock leaves the cluster, {{ClusteredLockImpl.ClusterChangeListener}} is supposed to release the lock. But if the {{org.infinispan.LOCKS}} cache is in DEGRADED mode, the lock release fails and an error is logged:
{noformat}
22:01:29,500 ERROR (jgroups-9,Test-NodeD:[]) [CacheManagerNotifierImpl] ISPN000405: Caught exception while invoking a cache manager listener!
org.infinispan.commons.CacheListenerException: ISPN000280: Caught exception [org.infinispan.partitionhandling.AvailabilityException] while invoking method [public void org.infinispan.lock.impl.lock.ClusteredLockImpl$ClusterChangeListener.viewChange(org.infinispan.notifications.cachemanagerlistener.event.ViewChangedEvent)] on listener instance: org.infinispan.lock.impl.lock.ClusteredLockImpl$ClusterChangeListener@3c91530d
at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.lambda$invoke$1(AbstractListenerImpl.java:430)
at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:450)
at org.infinispan.notifications.cachemanagerlistener.CacheManagerNotifierImpl.invokeListener(CacheManagerNotifierImpl.java:157)
at org.infinispan.notifications.cachemanagerlistener.CacheManagerNotifierImpl.invokeListeners(CacheManagerNotifierImpl.java:84)
at org.infinispan.notifications.cachemanagerlistener.CacheManagerNotifierImpl.notifyViewChange(CacheManagerNotifierImpl.java:103)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.receiveClusterView(JGroupsTransport.java:737)
...
Caused by: org.infinispan.partitionhandling.AvailabilityException: ISPN000306: Key 'ClusteredLockKey{name=ConsistentReliabilitySplitBrainTest}' is not available. Not all owners are in this partition
at org.infinispan.partitionhandling.impl.PartitionHandlingManagerImpl.doCheck(PartitionHandlingManagerImpl.java:272)
at org.infinispan.partitionhandling.impl.PartitionHandlingManagerImpl.checkRead(PartitionHandlingManagerImpl.java:114)
at org.infinispan.factories.InternalCacheFactory$PartitionHandlingCache.get(InternalCacheFactory.java:308)
at org.infinispan.factories.InternalCacheFactory$PartitionHandlingCache.get(InternalCacheFactory.java:306)
at org.infinispan.factories.InternalCacheFactory$AbstractGetAdvancedCache.containsKey(InternalCacheFactory.java:257)
at org.infinispan.cache.impl.AbstractDelegatingCache.containsKey(AbstractDelegatingCache.java:384)
at org.infinispan.cache.impl.EncoderCache.containsKey(EncoderCache.java:618)
at org.infinispan.lock.impl.manager.EmbeddedClusteredLockManager.isDefined(EmbeddedClusteredLockManager.java:157)
at org.infinispan.lock.impl.lock.ClusteredLockImpl$ClusterChangeListener.viewChange(ClusteredLockImpl.java:335)
at jdk.internal.reflect.GeneratedMethodAccessor29.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.lambda$invoke$1(AbstractListenerImpl.java:424)
{noformat}
When the cache goes back to AVAILABLE mode, there is no other check to see if the lock owner has come back into the cluster or not, so the lock may stay forever owned by a crashed node.
E.g. the initial cluster is ABCD, D owns clustered lock L
# The cluster splits into 3 partitions: AB, C, D
# LOCKS cache enters DEGRADED mode
# A and B try to unlock L, but fail
# D crashes
# C merges back with AB
# LOCKS cache becomes AVAILABLE
# L remains owned by D
Unlocking the locks on cluster view changes is also problematic. Because the LOCKS cache enters DEGRADED mode *after* the cluster view change, if the LOCKS cache is distributed, then it is theoretically possible for a lock to be unlocked and then for its owner to merge back:
E.g. the initial cluster is ABCD, D owns clustered lock L
# The cluster splits into 2 partitions: AB and CD
# A and B are the 2 owners of L, and A unlocks L
# The LOCKS cache enters DEGRADED mode
# The partitions merge back
# The LOCKS cache becomes AVAILABLE again
# D thinks it still owns L, but other nodes are able to acquire it
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 10 months
[Red Hat JIRA] (ISPN-12713) WELD-001417: Enabled interceptor class org.infinispan.jcache.annotation.CacheResultInterceptor
by Diego Lovison (Jira)
[ https://issues.redhat.com/browse/ISPN-12713?page=com.atlassian.jira.plugi... ]
Diego Lovison commented on ISPN-12713:
--------------------------------------
When WF is using modules, we don't have the issue.
> WELD-001417: Enabled interceptor class org.infinispan.jcache.annotation.CacheResultInterceptor
> ----------------------------------------------------------------------------------------------
>
> Key: ISPN-12713
> URL: https://issues.redhat.com/browse/ISPN-12713
> Project: Infinispan
> Issue Type: Bug
> Components: CDI
> Reporter: Diego Lovison
> Priority: Critical
>
> The reproducer is on the PR https://github.com/infinispan/infinispan/pull/9041
> {noformat}
> [INFO] Running org.infinispan.test.integration.thirdparty.cdi.GreetingServiceIT
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.045 s <<< FAILURE! - in org.infinispan.test.integration.thirdparty.cdi.GreetingServiceIT
> [ERROR] org.infinispan.test.integration.thirdparty.cdi.GreetingServiceIT Time elapsed: 0.006 s <<< ERROR!
> org.jboss.arquillian.container.spi.client.container.DeploymentException:
> Cannot deploy infinispan-server-integration.war: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"infinispan-server-integration.war\".WeldStartService" => "Failed to start service
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001417: Enabled interceptor class org.infinispan.jcache.annotation.CacheResultInterceptor (<{http://xmlns.jcp.org/xml/ns/javaee}class>org.infinispan.jcache.annotation.CacheResultInterceptor</{http://xmlns.jcp.org/xml/ns/javaee}class> in vfs:/content/infinispan-server-integration.war/WEB-INF/lib/infinispan-jcache-12.1.0-SNAPSHOT.jar/META-INF/beans.xml@8) does not match an interceptor bean: the class is not found, or not annotated with @Interceptor and still not registered through a portable extension, or not annotated with @Dependent inside an implicit bean archive"}}}}
> {noformat}
> I was not able to understand the root cause. Once we have more details, we can update the description and title.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 10 months
[Red Hat JIRA] (ISPN-12713) WELD-001417: Enabled interceptor class org.infinispan.jcache.annotation.CacheResultInterceptor
by Diego Lovison (Jira)
Diego Lovison created ISPN-12713:
------------------------------------
Summary: WELD-001417: Enabled interceptor class org.infinispan.jcache.annotation.CacheResultInterceptor
Key: ISPN-12713
URL: https://issues.redhat.com/browse/ISPN-12713
Project: Infinispan
Issue Type: Bug
Components: CDI
Reporter: Diego Lovison
The reproducer is on the PR https://github.com/infinispan/infinispan/pull/9041
{noformat}
[INFO] Running org.infinispan.test.integration.thirdparty.cdi.GreetingServiceIT
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.045 s <<< FAILURE! - in org.infinispan.test.integration.thirdparty.cdi.GreetingServiceIT
[ERROR] org.infinispan.test.integration.thirdparty.cdi.GreetingServiceIT Time elapsed: 0.006 s <<< ERROR!
org.jboss.arquillian.container.spi.client.container.DeploymentException:
Cannot deploy infinispan-server-integration.war: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"infinispan-server-integration.war\".WeldStartService" => "Failed to start service
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001417: Enabled interceptor class org.infinispan.jcache.annotation.CacheResultInterceptor (<{http://xmlns.jcp.org/xml/ns/javaee}class>org.infinispan.jcache.annotation.CacheResultInterceptor</{http://xmlns.jcp.org/xml/ns/javaee}class> in vfs:/content/infinispan-server-integration.war/WEB-INF/lib/infinispan-jcache-12.1.0-SNAPSHOT.jar/META-INF/beans.xml@8) does not match an interceptor bean: the class is not found, or not annotated with @Interceptor and still not registered through a portable extension, or not annotated with @Dependent inside an implicit bean archive"}}}}
{noformat}
I was not able to understand the root cause. Once we have more details, we can update the description and title.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 10 months
[Red Hat JIRA] (ISPN-12712) Cache created in runtime via CDI configuration is not visible for Cache Manager
by Diego Lovison (Jira)
Diego Lovison created ISPN-12712:
------------------------------------
Summary: Cache created in runtime via CDI configuration is not visible for Cache Manager
Key: ISPN-12712
URL: https://issues.redhat.com/browse/ISPN-12712
Project: Infinispan
Issue Type: Bug
Components: CDI
Affects Versions: 12.0.0.Final
Reporter: Diego Lovison
The reproducer for this error is on the PR https://github.com/infinispan/infinispan/pull/9041
I am pasting here a reference
{code:java}
@Produces
public Configuration defaultCacheConfiguration() {
return new ConfigurationBuilder()
.expiration().lifespan(60000l)
.build();
}
@Produces
@ApplicationScoped
public org.infinispan.manager.EmbeddedCacheManager defaultEmbeddedCacheManager() {
return new DefaultCacheManager();
}
@Inject
private AdvancedCache<Object, Object> greetingCache;
/**
* Creates new {@link DefaultCacheManager}.
* This test will fail if CDI Extension registers and won't set Cache Manager's name.
*/
@Test
public void testIfCreatingDefaultCacheManagerSucceeds() {
greetingCache.put("test-key", "test-value");
DefaultCacheManager cacheManager = new DefaultCacheManager();
assertEquals("test-value", cacheManager.getCache("default").get("test-key"));
cacheManager.stop();
}
{code}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 10 months
[Red Hat JIRA] (ISPN-12711) Collect exceptions from all targets in MultiTargetRequest
by Dan Berindei (Jira)
Dan Berindei created ISPN-12711:
-----------------------------------
Summary: Collect exceptions from all targets in MultiTargetRequest
Key: ISPN-12711
URL: https://issues.redhat.com/browse/ISPN-12711
Project: Infinispan
Issue Type: Enhancement
Components: Core
Affects Versions: 12.0.0.Final
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 12.1.0.Final
If a {{ResponseCollector}} throws an exception while processing a response from a target, the request is immediately completed exceptionally with that exception. But for most requests, we don't want to continue immediately: instead we want to wait until all the targets have replied, either with an exception or with a success response, so we can then release locks or retry the command.
This means each {{ResponseCollector}} implementation has to implement its own mechanism for collecting exceptions from all the targets and throwing the exception only during {{finish()}}.
Of course, some of our {{ResponseCollector}} implementations don't do it, and throw an exception from {{addResponse()}} instead.
It would be best if {{MultiTargetRequest}} collected exceptions itself, and {{ResponseCollectors}} would only have to throw the exception from {{addResponse()}}.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 10 months
[Red Hat JIRA] (IPROTO-187) Add support for marshalling null elements in collections/arrays
by Nistor Adrian (Jira)
[ https://issues.redhat.com/browse/IPROTO-187?page=com.atlassian.jira.plugi... ]
Nistor Adrian updated IPROTO-187:
---------------------------------
Status: Open (was: New)
> Add support for marshalling null elements in collections/arrays
> ---------------------------------------------------------------
>
> Key: IPROTO-187
> URL: https://issues.redhat.com/browse/IPROTO-187
> Project: Infinispan ProtoStream
> Issue Type: Enhancement
> Affects Versions: 4.4.0.Alpha1
> Reporter: Nistor Adrian
> Priority: Major
>
> So far, protostream has minimal support for nulls. A top level null object is marshalled as the empty (zero bytes) message.
>
> For the sake of backward compatibility we'll keep this behavior for top level, but we need a different approach for elements of an array or collection. In this case we need to use a null token. A new field will be added in WappedMessage to represent the null.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 10 months