January 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4568) DistSyncL1RepeatableReadFuncTest.testNoEntryInL1MultipleConcurrentGetsWithInvalidation random failures

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4568?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4568: ---------------------------------- Fix Version/s: (was: 7.1.0.CR1) > DistSyncL1RepeatableReadFuncTest.testNoEntryInL1MultipleConcurrentGetsWithInvalidation random failures > ------------------------------------------------------------------------------------------------------ > > Key: ISPN-4568 > URL: https://issues.jboss.org/browse/ISPN-4568 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 7.0.0.Alpha5 > Reporter: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > > Very likely related to ISPN-4564, as there seem to be 2 unjustified pauses ~ 3s and some log messages also appear to be delayed: > {noformat} > 08:23:48,443 TRACE (transport-thread-DistSyncL1RepeatableReadFuncTest-NodeAN-p28720-t1:) [InvocationContextInterceptor] Invoked with command PutKeyValueCommand{key=key-to-the-cache, value=second-put, flags=null, putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=null}, successful=true} and InvocationContext [org.infinispan.context.SingleKeyNonTxInvocationContext@e9a3538] > 08:23:48,470 TRACE (transport-thread-DistSyncL1RepeatableReadFuncTest-NodeAN-p28720-t1:) [JGroupsTransport] dests=[DistSyncL1RepeatableReadFuncTest-NodeAN-7764, DistSyncL1RepeatableReadFuncTest-NodeAM-739], command=SingleRpcCommand{cacheName='dist', command=PutKeyValueCommand{key=key-to-the-cache, value=second-put, flags=null, putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=null}, successful=true}}, mode=SYNCHRONOUS, timeout=60000 > 08:23:50,953 TRACE (remote-thread-DistSyncL1RepeatableReadFuncTest-NodeAM-p28701-t6:) [InvocationContextInterceptor] Invoked with command PutKeyValueCommand{key=key-to-the-cache, value=second-put, flags=null, putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=null}, successful=true} and InvocationContext [org.infinispan.context.impl.NonTxInvocationContext@62801f8c] > 08:23:50,953 TRACE (remote-thread-DistSyncL1RepeatableReadFuncTest-NodeAM-p28701-t6:) [L1ManagerImpl] Invalidating keys [key-to-the-cache] on nodes [DistSyncL1RepeatableReadFuncTest-NodeAK-9309]. Use multicast? false > 08:23:51,060 TRACE (transport-thread-DistSyncL1RepeatableReadFuncTest-NodeAM-p28700-t2:) [JGroupsTransport] dests=[DistSyncL1RepeatableReadFuncTest-NodeAK-9309], command=SingleRpcCommand{cacheName='dist', command=InvalidateL1Command{num keys=1, origin=DistSyncL1RepeatableReadFuncTest-NodeAN-7764}}, mode=SYNCHRONOUS_IGNORE_LEAVERS, timeout=60000 > 08:23:51,062 TRACE (remote-thread-DistSyncL1RepeatableReadFuncTest-NodeAK-p28661-t5:) [BaseRpcInvokingCommand] Invoking command InvalidateL1Command{num keys=1, origin=DistSyncL1RepeatableReadFuncTest-NodeAN-7764}, with originLocal flag set to false > 08:23:50,972 TRACE (remote-thread-DistSyncL1RepeatableReadFuncTest-NodeAM-p28701-t6:) [CallInterceptor] Executing command: PutKeyValueCommand{key=key-to-the-cache, value=second-put, flags=null, putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=null}, successful=true}. > 08:23:51,786 TRACE (remote-thread-DistSyncL1RepeatableReadFuncTest-NodeAK-p28661-t5:) [InboundInvocationHandlerImpl] About to send back response null for command SingleRpcCommand{cacheName='dist', command=InvalidateL1Command{num keys=1, origin=DistSyncL1RepeatableReadFuncTest-NodeAN-7764}} > 08:23:51,796 TRACE (transport-thread-DistSyncL1RepeatableReadFuncTest-NodeAM-p28700-t2:) [CommandAwareRpcDispatcher] Responses: [sender=DistSyncL1RepeatableReadFuncTest-NodeAK-9309, received=true, suspected=false] > 08:23:54,561 TRACE (transport-thread-DistSyncL1RepeatableReadFuncTest-NodeAM-p28700-t2:) [RpcManagerImpl] Response(s) to SingleRpcCommand{cacheName='dist', command=InvalidateL1Command{num keys=1, origin=DistSyncL1RepeatableReadFuncTest-NodeAN-7764}} is {} > 08:23:56,955 ERROR (testng-DistSyncL1RepeatableReadFuncTest:) [UnitTestTestNGListener] Test testNoEntryInL1MultipleConcurrentGetsWithInvalidation(org.infinispan.distribution.DistSyncL1RepeatableReadFuncTest) failed. > java.util.concurrent.TimeoutException > at java.util.concurrent.FutureTask.get(FutureTask.java:201) > at org.infinispan.commons.util.concurrent.NotifyingFutureImpl.get(NotifyingFutureImpl.java:84) > at org.infinispan.distribution.BaseDistSyncL1Test.testNoEntryInL1MultipleConcurrentGetsWithInvalidation(BaseDistSyncL1Test.java:217) > 08:23:54,578 TRACE (remote-thread-DistSyncL1RepeatableReadFuncTest-NodeAM-p28701-t6:) [L1NonTxInterceptor] Allowing entry to commit as local node is owner > 08:23:57,861 TRACE (remote-thread-DistSyncL1RepeatableReadFuncTest-NodeAM-p28701-t6:) [EntryWrappingInterceptor] About to commit entry RepeatableReadEntry(499752d9){key=key-to-the-cache, value=second-put, oldValue=first-put, isCreated=false, isChanged=true, isRemoved=false, isValid=true, skipRemoteGet=false, metadata=EmbeddedMetadata{version=null}} > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5134) Cluster Cache Loader returns null as a valid value

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5134?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5134: ------------------------------- Status: Open (was: New) > Cluster Cache Loader returns null as a valid value > -------------------------------------------------- > > Key: ISPN-5134 > URL: https://issues.jboss.org/browse/ISPN-5134 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 7.0.3.Final > Reporter: William Burns > > Found this at http://stackoverflow.com/questions/27840070/infinispan-cluster-in-invalid... > I tweaked the ClusterCacheLoaderTest to have a 3rd cache manager and I can see intermittent failures in either test due to using a null value from a different node. > Unfortunately this isn't as simple as tweaking ClusteredGetResponseValidityFilter to only say a valid response on a non null, since JGroups will throw an exception when there are no responses. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4020) Write a test for map/reduce with passivation enabled

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4020?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-4020: ------------------------------------- Assignee: Vladimir Blagojevic > Write a test for map/reduce with passivation enabled > ---------------------------------------------------- > > Key: ISPN-4020 > URL: https://issues.jboss.org/browse/ISPN-4020 > Project: Infinispan > Issue Type: Task > Components: Distributed Execution and Map/Reduce, Test Suite - Core > Reporter: Dan Berindei > Assignee: Vladimir Blagojevic > > If an entry is activated (i.e. removed from the store) during the mapping phase, between the iteration of the data container and the iteration of the cache store, it may be possible for that entry to be skipped. We need to write a test to confirm if this is the case. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4020) Write a test for map/reduce with passivation enabled

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4020?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4020: ---------------------------------- Fix Version/s: (was: 7.1.0.CR1) > Write a test for map/reduce with passivation enabled > ---------------------------------------------------- > > Key: ISPN-4020 > URL: https://issues.jboss.org/browse/ISPN-4020 > Project: Infinispan > Issue Type: Task > Components: Distributed Execution and Map/Reduce, Test Suite - Core > Reporter: Dan Berindei > Assignee: Vladimir Blagojevic > > If an entry is activated (i.e. removed from the store) during the mapping phase, between the iteration of the data container and the iteration of the cache store, it may be possible for that entry to be skipped. We need to write a test to confirm if this is the case. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3907) Define a Protobuf custom option for defining numeric IDs for types

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3907?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-3907: -------------------------------- Issue Type: Enhancement (was: Task) > Define a Protobuf custom option for defining numeric IDs for types > ------------------------------------------------------------------ > > Key: ISPN-3907 > URL: https://issues.jboss.org/browse/ISPN-3907 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Affects Versions: 6.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.1.0.CR1 > > > Currently the wire format of all Protobuf encoded keys and values contains a header/envelope that has some metadata information, like the fully qualified type name (that is protobuf type name, not java) of the object encoded in the message. This information is needed so that the other end can decode the message. And we added it because the Protobuf spec assumes both ends are aware of the message type, which is not the case most of the time. > While this approach solves the problem nicely, it becomes very inefficient is the FQN is long, which is usually the case, as people tend to stick the domain name of their company + package app name into it. > Solution: provide alternative unique numeric IDs to all types. The IDs can be added to message type definitions in the protobuf schema and the user is in charge of guaranteeing their uniqueness while the system must check and enforce the uniqueness when a schema is registered ib the ProtobufMetadataManager. To do this we define a custom Protobuf Message type option that accepts a numeric value. If such a numeric ID was assigned to the type then when it is serialized in protobuf the system has to use this id in the header rather that the FQN string. > This option should not be mandatory. Existing apps should work without requiring source code changes or recompiling providing that the relevant jars are upgraded in both client and server to support the new header encoding. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4585) Prioritize commands in the remote executor

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4585?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4585: ---------------------------------- Fix Version/s: (was: 7.1.0.CR1) > Prioritize commands in the remote executor > ------------------------------------------ > > Key: ISPN-4585 > URL: https://issues.jboss.org/browse/ISPN-4585 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 7.0.0.Alpha5 > Reporter: Dan Berindei > > The remote executor currently has an unlimited queue of blocked task, but the underlying executor cannot use a queue. With a queue, we wouldn't need to overflow remote commands to the OOB threads, and the OOB threads would be free to process response messages. > The problem is that {{ThreadPoolExecutor}} executes tasks in the order they are in the queue. If a node has a remote executor thread pool of 100 threads and receives a prepare(tx1, put(k, v1) comand, then 1000 prepare(tx_i, put(k, v_i)) commands, and finally a commit(tx1) command, the commit(tx1) command will block until all but 99 of the the prepare(tx_i, put(k, v_i)) commands have timed out. > I think we could help this by using a {{PriorityBlockingQueue}} for the underlying executor, with commands ordered so that state transfer commands < commit/tx completion notification < prepare/lock. The commit command would still have to wait for one of the prepare commands currently running to time out, but it wouldn't have to wait for all of them. > The current code, without a queue, would fill the remote executor and OOB thread pools, and it would discard the commit message (along with most of the prepare commands). The time it would take to process the commit successfully would depend on the timing of the retransmitted messages. > Another possible improvement would be to keep track of the commands currently being executed, and always keep some threads free for commands with higher priority. But I'm not sure how easy it would be to do that on top of an injected {{ExecutorService}}. > I believe there is also a problem with {{BlockingTaskAwareExecutorServiceImpl.checkForReadyTasks()}} after a topology change. Commands with the new topology id are all unblocked by submitting them to the underlying executor in FIFO order, on a single thread, so {{CallerRunsPolicy}} is not a valid rejection policy here. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4038) CustomFailurePolicyTxTest.testPrepareFailure random failures

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4038?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4038: ---------------------------------- Fix Version/s: (was: 7.1.0.CR1) > CustomFailurePolicyTxTest.testPrepareFailure random failures > ------------------------------------------------------------- > > Key: ISPN-4038 > URL: https://issues.jboss.org/browse/ISPN-4038 > Project: Infinispan > Issue Type: Bug > Components: Cross-Site Replication, Test Suite - Core > Affects Versions: 6.0.1.Final > Reporter: Dan Berindei > Labels: testsuite_stability > > http://ci.infinispan.org/viewLog.html?buildId=5935&tab=buildResultsDiv&bu... > {noformat} > java.lang.AssertionError: expected:<0> but was:<1> > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) > at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252) > at org.infinispan.xsite.backupfailure.tx.BaseBackupTxFailureTest.testPrepareFailure(BaseBackupTxFailureTest.java:45) > at org.infinispan.xsite.backupfailure.tx.CustomFailurePolicyTxTest.testPrepareFailure(CustomFailurePolicyTxTest.java:37) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4034) Cache RPCs should not wait for replies from nodes that have not joined the cache

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4034?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4034: ---------------------------------- Fix Version/s: (was: 7.1.0.CR1) > Cache RPCs should not wait for replies from nodes that have not joined the cache > -------------------------------------------------------------------------------- > > Key: ISPN-4034 > URL: https://issues.jboss.org/browse/ISPN-4034 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.1.Final > Reporter: Dan Berindei > Labels: 630 > > In a replicated cache, commands are broadcasted to the entire cluster and the originator waits for some kind of response from all the nodes in the cluster, even they are not members of the cache. > If a node doesn't have Infinispan's RpcDispatcher installed, it will never send any response, and replicated cache operations on the other nodes will all time out. See MissingRpcDispatcherTest for an example. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4033) ConcurrentInterceptorVisibilityTest.testGetVisibility random failures

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4033?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4033: ---------------------------------- Fix Version/s: (was: 7.1.0.CR1) > ConcurrentInterceptorVisibilityTest.testGetVisibility random failures > --------------------------------------------------------------------- > > Key: ISPN-4033 > URL: https://issues.jboss.org/browse/ISPN-4033 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 6.0.1.Final > Reporter: Dan Berindei > Labels: testsuite_stability > Attachments: ConcurrentInterceptorVisibilityTest.log > > > http://ci.infinispan.org/viewLog.html?buildId=5934&tab=buildResultsDiv&bu... > {noformat} > 17:28:43,212 ERROR (testng-ConcurrentInterceptorVisibilityTest:) [UnitTestTestNGListener] Test testGetVisibility(org.infinispan.interceptors.ConcurrentInterceptorVisibilityTest) failed. > java.lang.RuntimeException: java.util.concurrent.TimeoutException > at org.infinispan.interceptors.ConcurrentInterceptorVisibilityTest$1.call(ConcurrentInterceptorVisibilityTest.java:101) > at org.infinispan.test.TestingUtil.withCacheManager(TestingUtil.java:1243) > at org.infinispan.interceptors.ConcurrentInterceptorVisibilityTest.updateCache(ConcurrentInterceptorVisibilityTest.java:52) > at org.infinispan.interceptors.ConcurrentInterceptorVisibilityTest.testGetVisibility(ConcurrentInterceptorVisibilityTest.java:39) > Caused by: java.util.concurrent.TimeoutException > at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:228) > at java.util.concurrent.FutureTask.get(FutureTask.java:91) > at org.infinispan.interceptors.ConcurrentInterceptorVisibilityTest$1.call(ConcurrentInterceptorVisibilityTest.java:97) > ... 24 more > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4032) Listeners on originator node in DIST are notified even when not an owner

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4032?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4032: ---------------------------------- Fix Version/s: (was: 7.1.0.CR1) > Listeners on originator node in DIST are notified even when not an owner > ------------------------------------------------------------------------ > > Key: ISPN-4032 > URL: https://issues.jboss.org/browse/ISPN-4032 > Project: Infinispan > Issue Type: Bug > Components: Core, Listeners > Affects Versions: 6.0.1.Final > Reporter: William Burns > Labels: 630 > > Currently we notify listeners installed on the originator node when they perform a write command. This is done even when the originator node doesn't own the key. These notifications should only be fired by primary owner/backup owners normally and only primary if configured to do so. > The DistListenerTest currently even asserts this behavior around line ~85. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2015