December 2015 - infinispan-issues

[JBoss JIRA] (ISPN-5665) Query should not rely on the results of return values of write commands

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5665?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5665: -------------------------------- Fix Version/s: 8.2.0.Alpha1 (was: 8.1.0.Final) > Query should not rely on the results of return values of write commands > ----------------------------------------------------------------------- > > Key: ISPN-5665 > URL: https://issues.jboss.org/browse/ISPN-5665 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 8.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Gustavo Fernandes > Fix For: 8.2.0.Alpha1 > > > The query interceptor relies on the return value of the write commands to know the previous value of the modified entries. This is not correct, because some write commands do not return the previous value, e.g. {{remove(key, value)}}, {{replace(key, oldValue, newValue)}}, and {{putAll(map)}}. > The query interceptor should instead look up the previous values in the invocation context, and also force the loading of old values in the invocation context if the command doesn't do it explicitly (e.g. {{putAll(map)}}, or {{put(k, v)}} with the {{IGNORE_RETURN_VALUES}} flag). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5657) Add missing embedded configuration elements to server schema

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5657?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5657: -------------------------------- Fix Version/s: 8.2.0.Alpha1 (was: 8.1.0.Final) > Add missing embedded configuration elements to server schema > ------------------------------------------------------------ > > Key: ISPN-5657 > URL: https://issues.jboss.org/browse/ISPN-5657 > Project: Infinispan > Issue Type: Bug > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.2.0.Alpha1 > > > The embedded and server schema, while mostly compatible with each other, still differ in a number of aspects, e.g. store-as-binary, unsafe, etc. > The server should be able to parse these additional elements. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5654) Make DeadlockDetectingLockManager aware of single-node locking

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5654?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5654: -------------------------------- Fix Version/s: 8.2.0.Alpha1 (was: 8.1.0.Final) > Make DeadlockDetectingLockManager aware of single-node locking > -------------------------------------------------------------- > > Key: ISPN-5654 > URL: https://issues.jboss.org/browse/ISPN-5654 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 8.0.0.Beta2 > Reporter: Dan Berindei > Fix For: 8.2.0.Alpha1 > > > {{DeadlockDetectingLockManager}} seems to assume that the node that started a transaction acquires a local lock before replicating, which is wrong since we switched to locking only on the primary owner. > In particular, {{isSameKeyDeadlock}} can probably be removed altogether. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5642) Reduce contention in the RPC timeout handling

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5642?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5642: -------------------------------- Fix Version/s: 8.2.0.Alpha1 (was: 8.1.0.Final) > Reduce contention in the RPC timeout handling > --------------------------------------------- > > Key: ISPN-5642 > URL: https://issues.jboss.org/browse/ISPN-5642 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 8.0.0.Beta2 > Reporter: Dan Berindei > Priority: Minor > Labels: help_wanted > Fix For: 8.2.0.Alpha1 > > > Most of the RPC timeout tasks are cancelled way before their timeout expires. This means the scheduler spends a lot of time reordering the elements of its DelayQueue. > It should be possible to store the tasks with a long timeout (e.g. 1s) in a queue and only move them to the scheduler's priority queue when they have less than 1s to expiration (e.g. by a worker thread that runs every 0.5s) > Storing all the tasks in a single queue may be impractical because the worker thread would have more and work to do as load increases and the RPCs take longer to finish, so a [hashed timing wheel|http://www.cse.wustl.edu/~cdgill/courses/cs6874/TimingWheels.ppt] may be needed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5636) Test server modules against WildFly 10 Alpha

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5636?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5636: -------------------------------- Fix Version/s: 8.2.0.Alpha1 (was: 8.1.0.Final) > Test server modules against WildFly 10 Alpha > -------------------------------------------- > > Key: ISPN-5636 > URL: https://issues.jboss.org/browse/ISPN-5636 > Project: Infinispan > Issue Type: Component Upgrade > Components: WildFly modules > Affects Versions: 8.0.0.Beta2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.2.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5955) FAIL_SILENTLY doesn't always prevent rollback with pessimistic transactions

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5955?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5955: -------------------------------- Fix Version/s: 8.2.0.Alpha1 (was: 8.1.0.Final) > FAIL_SILENTLY doesn't always prevent rollback with pessimistic transactions > --------------------------------------------------------------------------- > > Key: ISPN-5955 > URL: https://issues.jboss.org/browse/ISPN-5955 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.0.1.Final, 8.1.0.Beta1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 8.2.0.Alpha1 > > > The {{FAIL_SILENTLY}} should "prevent a failing operation from affecting any ongoing JTA transactions", but sometimes this doesn't work properly. > {{FlagsReplicationTest}} has a transaction using both {{FAIL_SILENTLY}} and {{SKIP_LOCKING}} in the same transaction: > # A {{lock(FAIL_SILENTLY)(key)}} operation fails. > Both on the primary owner and on the originator, PessimisticLockingInterceptor sends a TxCompletionNotificationCommand to all the nodes affected by the tx so far, to release the locks. This marks the transaction as completed, but doesn't mark it as rolled back. > # A {{remove(SKIP_LOCKING)(key)}} operation should then succeed. > But the operation will invoke a {{ClusteredGetCommand(key, acquireRemoteLock=true, SKIP_LOCKING)}} on both owners, which will in turn invoke locally a {{LockControlCommand(key, SKIP_LOCKING)}}. > At this point, {{TxInterceptor}} sees that the transaction is already completed, and invokes a {{RollbackCommand}} to mark it as rolled back, then remove it from the transaction table. The command still succeeds. > # The test then tries to commit the transaction. Usually, the {{PrepareCommand}} doesn't find the remote transaction in the transaction table, and it succeeds. > But some of the time, because the {{ClusteredGetCommand}} command only uses the first response, the remote transaction is not removed from the transaction table by the time the {{PrepareCommand}} is executed on one of the owners. > If that happens, the {{PrepareCommand}} executes with a remote transaction instance that's already marked for rollback, and fails when trying to put the key in the context. > {noformat} > 15:42:56,736 ERROR (remote-thread-NodeF-p1112-t5:GlobalTx:NodeG-6318:216) [InvocationContextInterceptor] ISPN000136: Error executing command LockControlCommand, writing keys [] > org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 0 milliseconds for key replication.FlagsReplicationTest and requestor GlobalTx:NodeG-6318:216. Lock is held by GlobalTx:NodeG-6318:215 > 15:42:56,802 TRACE (OOB-1,NodeF-64741:) [NonTotalOrderTxPerCacheInboundInvocationHandler] Calling perform() on ClusteredGetCommand{key=replication.FlagsReplicationTest, flags=[SKIP_LOCKING]} > 15:42:56,803 TRACE (OOB-1,NodeF-64741:GlobalTx:NodeG-6318:216) [InvocationContextInterceptor] Invoked with command LockControlCommand{cache=dist, keys=[replication.FlagsReplicationTest], flags=[SKIP_LOCKING], unlock=false, gtx=GlobalTx:NodeG-6318:216} and InvocationContext [org.infinispan.context.impl.RemoteTxInvocationContext@75bf6da7] > 15:42:56,822 TRACE (remote-thread-NodeF-p1112-t6:GlobalTx:NodeG-6318:216) [InvocationContextInterceptor] Invoked with command PrepareCommand {modifications=[RemoveCommand{key=replication.FlagsReplicationTest, value=null, flags=[SKIP_LOCKING], valueMatcher=MATCH_ALWAYS}], onePhaseCommit=true, gtx=GlobalTx:NodeG-6318:216, cacheName='dist', topologyId=6} and InvocationContext [org.infinispan.context.impl.RemoteTxInvocationContext@75bf6da7] > 15:42:56,832 TRACE (OOB-1,NodeF-64741:GlobalTx:NodeG-6318:216) [TxInterceptor] Rolling back remote transaction GlobalTx:NodeG-6318:216 because either already completed (true) or originator no longer in the cluster (false). > 15:42:56,864 TRACE (remote-thread-NodeF-p1112-t6:GlobalTx:NodeG-6318:216) [EntryFactoryImpl] Creating new entry for key replication.FlagsReplicationTest > 15:42:56,864 TRACE (remote-thread-NodeF-p1112-t6:GlobalTx:NodeG-6318:216) [BaseSequentialInvocationContext] Interceptor class org.infinispan.interceptors.EntryWrappingInterceptor threw exception org.infinispan.transaction.xa.InvalidTransactionException: This remote transaction GlobalTx:NodeG-6318:216 is already rolled back > 15:42:56,873 TRACE (remote-thread-NodeF-p1112-t6:GlobalTx:NodeG-6318:216) [TxInterceptor] invokeNextInterceptorAndVerifyTransaction :: originatorMissing=false, alreadyCompleted=true > 15:42:56,873 TRACE (remote-thread-NodeF-p1112-t6:GlobalTx:NodeG-6318:216) [TxInterceptor] Rolling back remote transaction GlobalTx:NodeG-6318:216 because either already completed (true) or originator no longer in the cluster (false). > {noformat} > Possible actions: > * Never try to release locks from a {{LockControlCommand}}, wait for the {{RollbackCommand}} instead. This could cause problems if the primary owner dies, the transaction tries to lock the same entry again, and the backup owner that became primary wrongfully assumes that it is a proper owner. > * Use a {{LockControlCommand(unlock=true)}} instead of a {{TxCompletionNotificationCommand}} to release the backup locks after an operation with {{FAIL_SILENTLY}} failed. > * Don't set {{acquireRemoteLock=true}} when the {{SKIP_LOCKING}} flag has been set. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5937) HotRod client ExpiryTest.testGlobalExpiryPutWithFlag random failures

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5937?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5937: -------------------------------- Fix Version/s: 8.2.0.Alpha1 (was: 8.1.0.Final) > HotRod client ExpiryTest.testGlobalExpiryPutWithFlag random failures > -------------------------------------------------------------------- > > Key: ISPN-5937 > URL: https://issues.jboss.org/browse/ISPN-5937 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 8.1.0.Beta1 > Reporter: Dan Berindei > Priority: Critical > Labels: testsuite_stability > Fix For: 8.2.0.Alpha1 > > > The put operation succeeds, but the get immediately afterwards doesn't find the entry: > {noformat} > java.lang.AssertionError: expected:<v1> but was:<null> > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:101) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:108) > at org.infinispan.client.hotrod.ExpiryTest.expectCachedThenExpired(ExpiryTest.java:103) > at org.infinispan.client.hotrod.ExpiryTest.expectExpiryAfterRequest(ExpiryTest.java:99) > at org.infinispan.client.hotrod.ExpiryTest.testGlobalExpiryPutWithFlag(ExpiryTest.java:46){noformat} > http://ci.infinispan.org/viewLog.html?buildId=31770&tab=buildResultsDiv&b... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5929) InfinispanQueryIT.testQueryOnFirstNode random failures

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5929?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5929: -------------------------------- Fix Version/s: 8.2.0.Alpha1 (was: 8.1.0.Final) > InfinispanQueryIT.testQueryOnFirstNode random failures > ------------------------------------------------------ > > Key: ISPN-5929 > URL: https://issues.jboss.org/browse/ISPN-5929 > Project: Infinispan > Issue Type: Bug > Components: Integration , Test Suite - Query > Affects Versions: 8.1.0.Alpha2 > Reporter: Dan Berindei > Assignee: Adrian Nistor > Priority: Blocker > Fix For: 8.2.0.Alpha1 > > > {{InfinispanQueryIT.testQueryOnFirstNode()}} and {{InfinispanQueryIT.testQueryOnSecondNode()}} fail randomly in CI with this assertion: > {noformat} > java.lang.AssertionError: expected:<3> but was:<2> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:743) > at org.junit.Assert.assertEquals(Assert.java:118) > at org.junit.Assert.assertEquals(Assert.java:555) > at org.junit.Assert.assertEquals(Assert.java:542) > at org.infinispan.test.integration.as.query.InfinispanQueryIT.testQueryOnFirstNode(InfinispanQueryIT.java:99) > {noformat} > Example: http://ci.infinispan.org/viewLog.html?buildId=31810&tab=buildResultsDiv&b... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5894) Move near cache demo from source to a separate repo

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5894?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5894: -------------------------------- Fix Version/s: 8.2.0.Alpha1 (was: 8.1.0.Final) > Move near cache demo from source to a separate repo > --------------------------------------------------- > > Key: ISPN-5894 > URL: https://issues.jboss.org/browse/ISPN-5894 > Project: Infinispan > Issue Type: Task > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 8.2.0.Alpha1 > > > Move near cache demo from source to a separate repo. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5892) XML configuration should include number of segments for replicated caches

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5892?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5892: -------------------------------- Fix Version/s: 8.2.0.Alpha1 (was: 8.1.0.Final) > XML configuration should include number of segments for replicated caches > ------------------------------------------------------------------------- > > Key: ISPN-5892 > URL: https://issues.jboss.org/browse/ISPN-5892 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 8.0.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.2.0.Alpha1 > > > The primary owner of a key is determined based on the segment, so for remote caches it's good to increase the number of segments when there are many nodes in the cluster. Groups configuration may be useful as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2015