June 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-8988) CacheLoader not works after expiration in JCache

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8988?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8988: -------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/6068 > CacheLoader not works after expiration in JCache > ------------------------------------------------ > > Key: ISPN-8988 > URL: https://issues.jboss.org/browse/ISPN-8988 > Project: Infinispan > Issue Type: Bug > Components: JCache > Affects Versions: 9.2.0.Final, 8.2.10.Final > Reporter: Andrei Arkaev > Assignee: William Burns > Priority: Blocker > Fix For: 9.3.0.Final > > Attachments: InfinispanCacheTest.java > > > In configuration "JCache + ExirationPolicy + CacheLoader" cache returns null after cache key expiration (CacheLoader not called after expiration) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9293) Convert Set<Integer> places to IntSet where appropriate

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-9293?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-9293: -------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/6070 (was: https://github.com/infinispan/infinispan/pull/6065) > Convert Set<Integer> places to IntSet where appropriate > ------------------------------------------------------- > > Key: ISPN-9293 > URL: https://issues.jboss.org/browse/ISPN-9293 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: William Burns > Assignee: William Burns > Fix For: 9.3.0.Final > > > The IntSet class was introduced a while back. It was used instead of Set<Integer> if possible. This has some benefits with storage and network overhead. There are quite a few places that are not using the new IntSet. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9296) Counter's remove shouldn't remove the listeners

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-9296?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-9296: ------------------------------ Description: When Counter.remove() is invoked, it is wrongly removing the listeners registered in the local node. However, the remaining nodes in the cluster (and HR clients) keep their listener. The listeners shouldn't be removed in this case! Also, the counter is recreated when it is access after the removal. > Counter's remove shouldn't remove the listeners > ----------------------------------------------- > > Key: ISPN-9296 > URL: https://issues.jboss.org/browse/ISPN-9296 > Project: Infinispan > Issue Type: Bug > Components: Clustered Counter > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > > When Counter.remove() is invoked, it is wrongly removing the listeners registered in the local node. However, the remaining nodes in the cluster (and HR clients) keep their listener. > The listeners shouldn't be removed in this case! Also, the counter is recreated when it is access after the removal. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9296) Counter's remove shouldn't remove the listeners

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-9296?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-9296: ------------------------------ Description: When {{Counter.remove()}} is invoked, it is wrongly removing the listeners registered in the local node. However, the remaining nodes in the cluster (and HR clients) keep their listener. The listeners shouldn't be removed in this case! Also, the counter is recreated when it is access after the removal. was: When Counter.remove() is invoked, it is wrongly removing the listeners registered in the local node. However, the remaining nodes in the cluster (and HR clients) keep their listener. The listeners shouldn't be removed in this case! Also, the counter is recreated when it is access after the removal. > Counter's remove shouldn't remove the listeners > ----------------------------------------------- > > Key: ISPN-9296 > URL: https://issues.jboss.org/browse/ISPN-9296 > Project: Infinispan > Issue Type: Bug > Components: Clustered Counter > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > > When {{Counter.remove()}} is invoked, it is wrongly removing the listeners registered in the local node. However, the remaining nodes in the cluster (and HR clients) keep their listener. > The listeners shouldn't be removed in this case! Also, the counter is recreated when it is access after the removal. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9296) Counter's remove shouldn't remove the listeners

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-9296: --------------------------------- Summary: Counter's remove shouldn't remove the listeners Key: ISPN-9296 URL: https://issues.jboss.org/browse/ISPN-9296 Project: Infinispan Issue Type: Bug Components: Clustered Counter Reporter: Pedro Ruivo Assignee: Pedro Ruivo -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9130) GetGroupKeysTest.testRemoveGroupKeysWithPersistence[NON_OWNER, SCATTERED_SYNC] random failure

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-9130?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-9130: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > GetGroupKeysTest.testRemoveGroupKeysWithPersistence[NON_OWNER, SCATTERED_SYNC] random failure > --------------------------------------------------------------------------------------------- > > Key: ISPN-9130 > URL: https://issues.jboss.org/browse/ISPN-9130 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.3.0.Alpha1 > Reporter: Dan Berindei > Assignee: Radim Vansa > Labels: testsuite_stability > Fix For: 9.3.0.Final > > Attachments: GetGroupKeysTest_ISPN-7977_NPE_during_shutdown_20180507.log.gz, ScatteredSyncStoreNotSharedTest_ISPN-7977_NPE_during_shutdown_20180507.log.gz > > > {{ScatteredDistributionInterceptor.handleWriteCommand}} sends the {{PrimaryAckCommand}} to the originator too soon. It takes care of committing the entry to the data container instead of waiting for {{EntryWrappingInterceptor}} to do it, but it doesn't do anything about the stores: > {noformat} > 16:02:40,630 TRACE (testng-Test:[]) [InvocationContextInterceptor] Invoked with command RemoveCommand{key=GroupKey{group='test-group', key=0}, value=null, metadata=null, flags=[IGNORE_RETURN_VALUES], commandInvocationId=CommandInvocation:Test-NodeB-46322:3254, valueMatcher=MATCH_ALWAYS, topologyId=-1} and InvocationContext [SingleKeyNonTxInvocationContext{isLocked=false, key=null, cacheEntry=null, origin=null, lockOwner=CommandInvocation:Test-NodeB-46322:3254}] > 16:02:40,631 TRACE (remote-thread-Test-NodeD-p5380-t5:[]) [ScatteredDistributionInterceptor] Committing entry RepeatableReadEntry(4631a022){key=GroupKey{group='test-group', key=0}, value=null, isCreated=false, isChanged=true, isRemoved=true, isExpired=false, skipLookup=true, metadata=EmbeddedExpirableMetadata{lifespan=-1, maxIdle=-1, version=SimpleClusteredVersion{topologyId=5, version=40}}}, replaced MetadataImmortalCacheEntry{key=GroupKey{group='test-group', key=0}, value=v0, metadata=EmbeddedExpirableMetadata{lifespan=-1, maxIdle=-1, version=SimpleClusteredVersion{topologyId=5, version=21}}} > 16:02:40,631 TRACE (remote-thread-Test-NodeD-p5380-t5:[]) [DefaultDataContainer] Store MetadataImmortalCacheEntry{key=GroupKey{group='test-group', key=0}, value=null, metadata=EmbeddedExpirableMetadata{lifespan=-1, maxIdle=-1, version=SimpleClusteredVersion{topologyId=5, version=40}}} in container > 16:02:40,633 TRACE (remote-thread-Test-NodeD-p5380-t5:[]) [JGroupsTransport] Test-NodeD-54637 sending command to Test-NodeB-46322: PrimaryAckCommand{id=3254, success=true, value=SimpleClusteredVersion{topologyId=5, version=40}, waitFor=[Test-NodeF-20476]} > 16:02:40,633 TRACE (jgroups-10,Test-NodeB-46322:[]) [DefaultDataContainer] Store MetadataImmortalCacheEntry{key=GroupKey{group='test-group', key=0}, value=null, metadata=EmbeddedMetadata{version=SimpleClusteredVersion{topologyId=5, version=40}}} in container > 16:02:40,634 TRACE (jgroups-10,Test-NodeB-46322:[]) [DistCacheWriterInterceptor] Stored entry null under key GroupKey{group='test-group', key=0} > --- > 16:02:40,634 TRACE (testng-Test:[]) [InvocationContextInterceptor] Invoked with command GetKeysInGroupCommand{groupName='test-group', flags=[]} and InvocationContext [org.infinispan.context.impl.NonTxInvocationContext@6314f4e7] > 16:02:40,635 TRACE (jgroups-4,Test-NodeD-54637:[]) [InvocationContextInterceptor] Invoked with command GetKeysInGroupCommand{groupName='test-group', flags=[]} and InvocationContext [org.infinispan.context.impl.NonTxInvocationContext@6dd409f2] > 16:02:40,635 TRACE (jgroups-4,Test-NodeD-54637:[]) [DummyInMemoryStore] Processing entries in store null with filter org.infinispan.filter.CompositeKeyFilter@196d8e49 and callback org.infinispan.interceptors.impl.CacheLoaderInterceptor$1@54df66d9 > 16:02:40,635 TRACE (jgroups-4,Test-NodeD-54637:[]) [EntryFactoryImpl] Creating new entry for key GroupKey{group='test-group', key=0} > 16:02:40,636 TRACE (jgroups-4,Test-NodeD-54637:[]) [JGroupsTransport] Test-NodeD-54637 sending response for request 21 to Test-NodeB-46322: SuccessfulResponse([MetadataImmortalCacheEntry{key=GroupKey{group='test-group', key=0}, value=v0, metadata=EmbeddedExpirableMetadata{lifespan=-1, maxIdle=-1, version=SimpleClusteredVersion{topologyId=5, version=21}}}]) > --- > 16:02:40,636 TRACE (remote-thread-Test-NodeD-p5380-t5:[]) [DummyInMemoryStore] Store MarshalledEntryImpl{keyBytes=null, valueBytes=null, metadataBytes=null, key=GroupKey{group='test-group', key=0}, value=null, metadata=InternalMetadataImpl{actual=EmbeddedExpirableMetadata{lifespan=-1, maxIdle=-1, version=SimpleClusteredVersion{topologyId=5, version=40}}, created=-1, lastUsed=-1}, marshaller=org.infinispan.marshall.core.GlobalMarshaller@26ecc0d1} in dummy map store@5d185974 > --- > 16:02:40,638 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.distribution.groups.GetGroupKeysTest.testRemoveGroupKeysWithPersistence[NON_OWNER, SCATTERED_SYNC] > java.lang.AssertionError: > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.9.9.jar:?] > at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24) ~[testng-6.9.9.jar:?] > at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:33) ~[testng-6.9.9.jar:?] > at org.infinispan.distribution.groups.GetGroupKeysTest.testRemoveGroupKeysWithPersistence(GetGroupKeysTest.java:162) ~[test-classes/:?] > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8431) ScatteredSplitAndMergeTest random failures

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-8431?page=com.atlassian.jira.plugin.... ] Radim Vansa edited comment on ISPN-8431 at 6/14/18 10:28 AM: ------------------------------------------------------------- It seems that this happens only when the node already has the {{RemoteMetadata}} with the proper version: -if it does not the command is retried as the value in DC has changed in the meantime, but if we have the metadata the version matches.- However it can happen even if the full value is not updated yet, as setting the value in put-from-prefetch does not call {{RepeatableReadEntry.updatePreviousValue()}} and this is what the command returns. was (Author: rvansa): It seems that this happens only when the node already has the {{RemoteMetadata}} with the proper version: -if it does not the command is retried as the value in DC has changed in the meantime, but if we have the metadata the version matches.- However it can happen even if the full value is not updated yet, as setting the value in put-from-prefetch does not call RepeatableReadEntry.updatePreviousValue() and this is what the command returns. > ScatteredSplitAndMergeTest random failures > ------------------------------------------ > > Key: ISPN-8431 > URL: https://issues.jboss.org/browse/ISPN-8431 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 9.2.0.Alpha1 > Environment: Jenkins > Reporter: Tristan Tarrant > Assignee: Radim Vansa > Labels: testsuite_stability > Attachments: ScatteredSplitAndMergeTest_20180129.log.gz, ScatteredSplitAndMergeTest_ISPN-7919_RpcManager_ResponseCollector_20171212.log.gz > > > http://ci.infinispan.org/job/Infinispan/job/master/214/testReport/junit/o... > java.lang.AssertionError: expected [null] but found [v0] > at org.infinispan.partitionhandling.ScatteredSplitAndMergeTest.testSplitAndMerge(ScatteredSplitAndMergeTest.java:80) > at org.infinispan.partitionhandling.ScatteredSplitAndMergeTest.testSplitAndMerge5(ScatteredSplitAndMergeTest.java:51) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > 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) > ... Removed 20 stack frames > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8431) ScatteredSplitAndMergeTest random failures

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-8431?page=com.atlassian.jira.plugin.... ] Radim Vansa edited comment on ISPN-8431 at 6/14/18 10:28 AM: ------------------------------------------------------------- It seems that this happens only when the node already has the {{RemoteMetadata}} with the proper version: -if it does not the command is retried as the value in DC has changed in the meantime, but if we have the metadata the version matches.- However it can happen even if the full value is not updated yet, as setting the value in put-from-prefetch does not call RepeatableReadEntry.updatePreviousValue() and this is what the command returns. was (Author: rvansa): It seems that this happens only when the node already has the {{RemoteMetadata}} with the proper version: if it does not the command is retried as the value in DC has changed in the meantime, but if we have the metadata the version matches. > ScatteredSplitAndMergeTest random failures > ------------------------------------------ > > Key: ISPN-8431 > URL: https://issues.jboss.org/browse/ISPN-8431 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 9.2.0.Alpha1 > Environment: Jenkins > Reporter: Tristan Tarrant > Assignee: Radim Vansa > Labels: testsuite_stability > Attachments: ScatteredSplitAndMergeTest_20180129.log.gz, ScatteredSplitAndMergeTest_ISPN-7919_RpcManager_ResponseCollector_20171212.log.gz > > > http://ci.infinispan.org/job/Infinispan/job/master/214/testReport/junit/o... > java.lang.AssertionError: expected [null] but found [v0] > at org.infinispan.partitionhandling.ScatteredSplitAndMergeTest.testSplitAndMerge(ScatteredSplitAndMergeTest.java:80) > at org.infinispan.partitionhandling.ScatteredSplitAndMergeTest.testSplitAndMerge5(ScatteredSplitAndMergeTest.java:51) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > 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) > ... Removed 20 stack frames > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8988) CacheLoader not works after expiration in JCache

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-8988?page=com.atlassian.jira.plugin.... ] Ryan Emerson resolved ISPN-8988. -------------------------------- Fix Version/s: 9.3.0.Final Assignee: William Burns (was: Galder Zamarreño) Resolution: Done > CacheLoader not works after expiration in JCache > ------------------------------------------------ > > Key: ISPN-8988 > URL: https://issues.jboss.org/browse/ISPN-8988 > Project: Infinispan > Issue Type: Bug > Components: JCache > Affects Versions: 9.2.0.Final, 8.2.10.Final > Reporter: Andrei Arkaev > Assignee: William Burns > Priority: Blocker > Fix For: 9.3.0.Final > > Attachments: InfinispanCacheTest.java > > > In configuration "JCache + ExirationPolicy + CacheLoader" cache returns null after cache key expiration (CacheLoader not called after expiration) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8431) ScatteredSplitAndMergeTest random failures

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-8431?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-8431: ----------------------------------- It seems that this happens only when the node already has the {{RemoteMetadata}} with the proper version: if it does not the command is retried as the value in DC has changed in the meantime, but if we have the metadata the version matches. > ScatteredSplitAndMergeTest random failures > ------------------------------------------ > > Key: ISPN-8431 > URL: https://issues.jboss.org/browse/ISPN-8431 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 9.2.0.Alpha1 > Environment: Jenkins > Reporter: Tristan Tarrant > Assignee: Radim Vansa > Labels: testsuite_stability > Attachments: ScatteredSplitAndMergeTest_20180129.log.gz, ScatteredSplitAndMergeTest_ISPN-7919_RpcManager_ResponseCollector_20171212.log.gz > > > http://ci.infinispan.org/job/Infinispan/job/master/214/testReport/junit/o... > java.lang.AssertionError: expected [null] but found [v0] > at org.infinispan.partitionhandling.ScatteredSplitAndMergeTest.testSplitAndMerge(ScatteredSplitAndMergeTest.java:80) > at org.infinispan.partitionhandling.ScatteredSplitAndMergeTest.testSplitAndMerge5(ScatteredSplitAndMergeTest.java:51) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > 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) > ... Removed 20 stack frames > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2018