December 2015 - infinispan-issues

[JBoss JIRA] (ISPN-5704) Enhancements for Functional Map API

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5704?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5704: -------------------------------- Fix Version/s: 8.2.0.Alpha1 (was: 8.1.0.Final) > Enhancements for Functional Map API > ----------------------------------- > > Key: ISPN-5704 > URL: https://issues.jboss.org/browse/ISPN-5704 > Project: Infinispan > Issue Type: Enhancement > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 8.2.0.Alpha1 > > > List of enhancements that didn't make it into 8.0: > * Transaction support. > * Verify locks are acquired for all operations (once tx is in place, locks can be checked easily) > * Complete persistence support (remove many returning previous, put many returning previous, remove many) > * Replication of per-invocation parameters. > * Port mode *Becoming*Test to functional APIs, and expand on testing other functional APIs. > * Test interoperability with cache, e.g. cache put with lifespan can be retrieved via functional map with lifespan, and viceversa > * Test compatibility mode > * Add more listener events: activation, passivation and expiration. > * Use check isLocal instead of `e == null` in command impls > * Fix branch skip issue (see previous PR: https://github.com/infinispan/infinispan/pull/3571) > * Add externalizers for primitive versions of Optional. > * ValueMatcherMode indexes in MarshallableFunctionExternalizers should be based on {{ordinal()}} calls to annotation. Also, could the core's enumeration use the annotations defined in commons? > * Add AdvancedExternalizer version for functions that takes value matcher > * Complete support for MetaCreated and MetaLastUsed (which should be separated into MetaLastModified and MetaLastAccessed) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[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)

10 years, 4 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)

10 years, 4 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)

10 years, 4 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)

10 years, 4 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)

10 years, 4 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)

10 years, 4 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)

10 years, 4 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)

10 years, 4 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)

10 years, 4 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 December 2015