November 2013 - infinispan-issues

[JBoss JIRA] (ISPN-2475) When L1.onRehash is enabled, L1 invalidations should be sent to the previous owners

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2475?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2475: ----------------------------------------------- Radim Vansa <rvansa(a)redhat.com> changed the Status of [bug 1025258|https://bugzilla.redhat.com/show_bug.cgi?id=1025258] from ON_QA to VERIFIED > When L1.onRehash is enabled, L1 invalidations should be sent to the previous owners > ----------------------------------------------------------------------------------- > > Key: ISPN-2475 > URL: https://issues.jboss.org/browse/ISPN-2475 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.1.0.FINAL, 6.0.0.CR1 > Reporter: Dan Berindei > Assignee: William Burns > Priority: Critical > Labels: 620 > Fix For: 6.0.0.Final > > > Copied from the parent: > {quote} > [...] we can keep track of the consistent hashes in the last 10 minutes (or whatever the L1 lifespan is) and the time of the last invalidation sent for each key. When we need to send a new invalidation, we add the owners in all the consistent hashes since the last invalidation to the invalidation command recipients. > {quote} -- 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

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3648) Inconsistent L1 in tx distributed cache

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3648?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3648: ----------------------------------------------- Radim Vansa <rvansa(a)redhat.com> changed the Status of [bug 1021362|https://bugzilla.redhat.com/show_bug.cgi?id=1021362] from ON_QA to VERIFIED > Inconsistent L1 in tx distributed cache > ---------------------------------------- > > Key: ISPN-3648 > URL: https://issues.jboss.org/browse/ISPN-3648 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > Labels: 620 > Fix For: 6.0.0.Final > > > In L1LastChance interceptor the CommitCommand sends invalidations only for those keys whose it is the primary owner. However, some key which is owned in backup way may be read when the command is replicated and this does not get invalidated after the command finishes. > This issue is very similar to https://issues.jboss.org/browse/ISPN-3617 -- 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

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3599) CommitCommand with replayed PrepareCommand executes rollback and then commit

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3599?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3599: ----------------------------------------------- Radim Vansa <rvansa(a)redhat.com> changed the Status of [bug 1016054|https://bugzilla.redhat.com/show_bug.cgi?id=1016054] from ON_QA to VERIFIED > CommitCommand with replayed PrepareCommand executes rollback and then commit > ---------------------------------------------------------------------------- > > Key: ISPN-3599 > URL: https://issues.jboss.org/browse/ISPN-3599 > Project: Infinispan > Issue Type: Bug > Components: State transfer, Transactions > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: Pedro Ruivo > Priority: Critical > Labels: 620 > Fix For: 6.0.0.Final > > > During state-transfer in tx cache, the node can receive {{CommitCommand}} from other node. After the node gets transaction data for affected segments, it creates the transaction with {{missingLookedUpEntries=true}} and the {{CommitCommand}} can be executed. > In this command's {{perform(...)}} the transaction is *first* marked as completed, then it enters the interceptor chain. There, the {{PrepareCommand}} is created in {{StateTransferInterceptor.visitCommitCommand}} but after this is processed the {{TxInterceptor}} finds out that the transaction is already completed and executes {{RollbackCommand}}, clearing locks etc. > Nevertheless, {{StateTransferInterceptor}} executes the initial {{CommitCommand}} afterwards. I suspect that this may be executed without the locks held. > Anyway, it is not correct to execute both commit and rollback on the same transaction. -- 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

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3744) TopologyAwareTwoNodesMapReduceTest random failures

by Dan Berindei (JIRA)

Dan Berindei created ISPN-3744: ---------------------------------- Summary: TopologyAwareTwoNodesMapReduceTest random failures Key: ISPN-3744 URL: https://issues.jboss.org/browse/ISPN-3744 Project: Infinispan Issue Type: Bug Components: Test Suite Affects Versions: 6.0.0.Final Reporter: Dan Berindei Assignee: Dan Berindei The static counter used in FailAfterSecondCallReducer in TopologyAwareTwoNodesMapReduceTest.testInvokeMapWithReduceExceptionPhaseInRemoteExecution and SimpleTwoNodesMapReduceTest.testInvokeMapWithReduceExceptionPhaseInRemoteExecution has several problems: 1. Both tests use the same counter, if they run in parallel one could reset the counter for the other. 2. The counter update is not atomic, so the async thread that executes the reducer on the originator and the remote executor thread that executes the reducer on the remote node can both see value 0. 3. There is no guarantee that the reducer is executed on the originator first, so the exception isn't always thrown on the remote node. -- 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

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3743) Silence "IllegalStateException: Default cache is in 'STOPPING' state" exceptions

by Dan Berindei (JIRA)

Dan Berindei created ISPN-3743: ---------------------------------- Summary: Silence "IllegalStateException: Default cache is in 'STOPPING' state" exceptions Key: ISPN-3743 URL: https://issues.jboss.org/browse/ISPN-3743 Project: Infinispan Issue Type: Feature Request Components: RPC Affects Versions: 6.0.0.Final Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 7.0.0.Final When a cache in STOPPING state receives a command, the exception is propagated all the way to the caller: {noformat} 09:33:02,005 ERROR (testng-NonTxPutIfAbsentDuringLeaveStressTest:) [UnitTestTestNGListener] Test testNodeLeavingDuringPutIfAbsent(org.infinispan.distribution.rehash.NonTxPutIfAbsentDuringLeaveStressTest) failed. java.util.concurrent.ExecutionException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from NodeC-25987, see cause for remote stack trace at java.util.concurrent.FutureTask.report(FutureTask.java:122) Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from NodeC-25987, see cause for remote stack trace at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:41) Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from NodeD-57301, see cause for remote stack trace at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:41) Caused by: java.lang.IllegalStateException: Default cache is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:93) {noformat} This causes random failures in NonTxPutIfAbsentDuringLeaveStressTest.testNodeLeavingDuringPutIfAbsent. The originator should either ignore the IllegalStateException or wait for a new cache topology and retry the operation, just like it should for SuspectExceptions (ISPN-2577). -- 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

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3742) StateTransferReplicationQueueTest random failures

by Dan Berindei (JIRA)

Dan Berindei created ISPN-3742: ---------------------------------- Summary: StateTransferReplicationQueueTest random failures Key: ISPN-3742 URL: https://issues.jboss.org/browse/ISPN-3742 Project: Infinispan Issue Type: Bug Components: Test Suite Affects Versions: 6.0.0.Final Reporter: Dan Berindei Assignee: Mircea Markus The writer thread in StateTransferReplicationQueueTest is too fast, and sometimes it generates so many writes that it takes more than 5 seconds for the second node to apply all of them. We should use a much smaller limit for the replication queue, and the test should wait until all the commands have been replicated instead of using an arbitrary timeout. -- 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

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3633) InvalidateL1Command during ST should not cancel writing the entry by ST

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3633?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3633: ----------------------------------------------- Radim Vansa <rvansa(a)redhat.com> changed the Status of [bug 1019348|https://bugzilla.redhat.com/show_bug.cgi?id=1019348] from ON_QA to ASSIGNED > InvalidateL1Command during ST should not cancel writing the entry by ST > ----------------------------------------------------------------------- > > Key: ISPN-3633 > URL: https://issues.jboss.org/browse/ISPN-3633 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.3.0.Final > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > Labels: 620 > Fix For: 6.0.0.Final > > > When a node which is about to receive the entries for some segment receives InvalidateL1Command, this puts the key into StateConsumer.updatedKeys. After the entries for ST are received, the entry which was invalidated is not updated -> this result in losing the entry. > Btw., in EntryWrappingInterceptor.visitInvalidateL1Command the trace logs all looked up entries for each entry - this causes some performance problems when tracing is on and there are many invalidated entries. Please, do this only once. -- 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

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3633) InvalidateL1Command during ST should not cancel writing the entry by ST

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-3633?page=com.atlassian.jira.plugin.... ] Radim Vansa reopened ISPN-3633: ------------------------------- This issue still is not fixed for non-transactional cache: When topology changes so that owners [A, B] -> [A, C], C has the entry in L1 cache: 1. D executes PUT -> sends command to A 2. A executes the PUT, sends invalidation to C 3. ST from A to C begins 4. C receives InvalidateL1 and puts this key into updateKeys 5. C receives state but ignores the updated key > InvalidateL1Command during ST should not cancel writing the entry by ST > ----------------------------------------------------------------------- > > Key: ISPN-3633 > URL: https://issues.jboss.org/browse/ISPN-3633 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.3.0.Final > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > Labels: 620 > Fix For: 6.0.0.Final > > > When a node which is about to receive the entries for some segment receives InvalidateL1Command, this puts the key into StateConsumer.updatedKeys. After the entries for ST are received, the entry which was invalidated is not updated -> this result in losing the entry. > Btw., in EntryWrappingInterceptor.visitInvalidateL1Command the trace logs all looked up entries for each entry - this causes some performance problems when tracing is on and there are many invalidated entries. Please, do this only once. -- 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

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3316) CDI Cache interceptor tests are failing while running in EAP container

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3316?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3316: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2232 > CDI Cache interceptor tests are failing while running in EAP container > ---------------------------------------------------------------------- > > Key: ISPN-3316 > URL: https://issues.jboss.org/browse/ISPN-3316 > Project: Infinispan > Issue Type: Bug > Components: CDI integration > Affects Versions: 5.3.0.Final, 6.0.0.Final > Reporter: Anna Manukyan > Assignee: Galder Zamarreño > Labels: 620 > Fix For: 6.1.0.Final > > > While migration of the CDI related tests to work under EAP container (at the moment using 6.0.GA), it was found that the tests related to interceptors are failing. The issue relates to > org.infinispan.cdi.test.interceptor.CachePutInterceptorTest, org.infinispan.cdi.test.interceptor.CacheRemoveAllInterceptorTest, org.infinispan.cdi.test.interceptor.CacheRemoveInterceptorTest, org.infinispan.cdi.test.interceptor.CacheResultInterceptorTest. > The failure relates to assertions. The thing is that all actions which are done using javax.cache.cache-api annotations, work properly (I've added some logs e.g. in CachePutInterceptor, and it shows that the data is put to the cache properly). > But later when the test wants to verify that the data is really put to the data, retrieves the cache from the injected CacheContainer, the cache is empty - the data is not there. > The issue appeared since the latest changes to the Infinispan-CDI module, and split to infinispan-jcache module. For the previous version, the tests are passed under EAP container. > The example above was given for the CachePutInterceptorTest, but the same refers to the rest of them. > The git repo for the sources, will be provided later. -- 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

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3316) CDI Cache interceptor tests are failing while running in EAP container

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3316?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-3316: ---------------------------------------- We're adding Wildfly CDI/JCache integration tests with this. > CDI Cache interceptor tests are failing while running in EAP container > ---------------------------------------------------------------------- > > Key: ISPN-3316 > URL: https://issues.jboss.org/browse/ISPN-3316 > Project: Infinispan > Issue Type: Bug > Components: CDI integration > Affects Versions: 5.3.0.Final, 6.0.0.Final > Reporter: Anna Manukyan > Assignee: Galder Zamarreño > Labels: 620 > Fix For: 6.1.0.Final > > > While migration of the CDI related tests to work under EAP container (at the moment using 6.0.GA), it was found that the tests related to interceptors are failing. The issue relates to > org.infinispan.cdi.test.interceptor.CachePutInterceptorTest, org.infinispan.cdi.test.interceptor.CacheRemoveAllInterceptorTest, org.infinispan.cdi.test.interceptor.CacheRemoveInterceptorTest, org.infinispan.cdi.test.interceptor.CacheResultInterceptorTest. > The failure relates to assertions. The thing is that all actions which are done using javax.cache.cache-api annotations, work properly (I've added some logs e.g. in CachePutInterceptor, and it shows that the data is put to the cache properly). > But later when the test wants to verify that the data is really put to the data, retrieves the cache from the injected CacheContainer, the cache is empty - the data is not there. > The issue appeared since the latest changes to the Infinispan-CDI module, and split to infinispan-jcache module. For the previous version, the tests are passed under EAP container. > The example above was given for the CachePutInterceptorTest, but the same refers to the rest of them. > The git repo for the sources, will be provided later. -- 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

11 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2013