November 2014 - infinispan-issues

[JBoss JIRA] (ISPN-4340) Automatically setup shared indexes when indexing is enabled

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4340?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4340: ----------------------------------- Fix Version/s: 7.1.0.Alpha1 (was: 7.0.0.Final) > Automatically setup shared indexes when indexing is enabled > ----------------------------------------------------------- > > Key: ISPN-4340 > URL: https://issues.jboss.org/browse/ISPN-4340 > Project: Infinispan > Issue Type: Feature Request > Components: Embedded Querying > Reporter: Sanne Grinovero > Assignee: Gustavo Fernandes > Labels: 64QueryBlockers > Fix For: 7.1.0.Alpha1 > > > - on replicated Caches, we should create a default index on a FSDirectory and provide some appropriate default tuning, for example enabling NRT. > - distributed Caches will need the Infinispan Directory (shared) and a master/slave backend (Infinispan IndexManager, while NRT is not compatible in this case) > We want to keep the properties configuration structure as well as an "advanced tuning" and override capabilities of the default choices. > Some more common options like sync/async indexing should probably be promoted to be controlled by the XML elements and configuration DSL excplicitly. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4390) CHMv8 leaks ThreadLocal

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4390?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4390: ----------------------------------- Fix Version/s: 7.1.0.Alpha1 (was: 7.0.0.Final) > CHMv8 leaks ThreadLocal > ----------------------- > > Key: ISPN-4390 > URL: https://issues.jboss.org/browse/ISPN-4390 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Sanne Grinovero > Fix For: 7.1.0.Alpha1 > > > As discussed on: http://lists.jboss.org/pipermail/infinispan-dev/2014-June/015055.html -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4351) Clarify the behaviour of putForExternalRead in clustered caches

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4351?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4351: ----------------------------------- Fix Version/s: 7.1.0.Alpha1 (was: 7.0.0.Final) > Clarify the behaviour of putForExternalRead in clustered caches > --------------------------------------------------------------- > > Key: ISPN-4351 > URL: https://issues.jboss.org/browse/ISPN-4351 > Project: Infinispan > Issue Type: Task > Components: Core, Documentation-Core > Affects Versions: 6.0.2.Final > Reporter: Dan Berindei > Fix For: 7.1.0.Alpha1 > > > The {{putForExternal}} [documentation|http://infinispan.org/docs/7.0.x/user_guide/user_guide.html...] says > {quote} > putForExternalRead is consider to be a fast operation because regardless of whether it’s successful or not, it doesn’t wait for any locks, and so returns to the caller promptly. > {quote} > But the documentation doesn't say how {{putForExternalRead}} should behave in a clustered cache. Currently, the command is replicated to all the owners in distributed mode, and to all the cluster members in replicated mode. So the command may be delayed while waiting for the responses from those other nodes. The exception is invalidation mode, which doesn't replicate {{putForExternalRead}} commands - only regular {{put}}s generate invalidations. > The documentation also doesn't mention the interaction of {{putForExternalRead}} operations with transactions. Currently, {{PUT_FOR_EXTERNAL_READ}}-flagged commands are executed as non-transactional commands even when the cache is transactional, presumably to avoid the overhead of transactions. But this undermines the argument for wrapping regular write operations in an implicit transaction, when running in a transactional cache. > I propose changing {{putForExternalRead}} to only write on the local node (as it already does in invalidation mode), and documenting it as such. In distribution mode, it should be a no-op when the local node is not an owner. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4434) Replace Set<Integer> with BitSet in the ConsistentHash interface

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4434?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4434: ----------------------------------- Fix Version/s: 7.1.0.Alpha1 (was: 7.0.0.Final) > Replace Set<Integer> with BitSet in the ConsistentHash interface > ---------------------------------------------------------------- > > Key: ISPN-4434 > URL: https://issues.jboss.org/browse/ISPN-4434 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 7.0.0.Alpha4 > Reporter: Dan Berindei > Priority: Minor > Fix For: 7.1.0.Alpha1 > > > Memory-wise, BitSet should be more efficient, and iteration should be about the same. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4404) The coordinator leaving the cluster should not cancel state transfer

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4404?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4404: ----------------------------------- Fix Version/s: 7.1.0.Alpha1 (was: 7.0.0.Final) > The coordinator leaving the cluster should not cancel state transfer > -------------------------------------------------------------------- > > Key: ISPN-4404 > URL: https://issues.jboss.org/browse/ISPN-4404 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 6.0.2.Final > Reporter: Dan Berindei > Fix For: 7.1.0.Alpha1 > > > When the cluster coordinator changes or a merge view is received, the new coordinator tries to reconcile the cache topologies of the different partitions and cancels any state transfer in progress. > But most of the time, the coordinator changing doesn't mean that there are multiple partitions, just that the old coordinator died. In that case there is a single cache topology, so there is nothing to reconcile and no reason to cancel the pending ST. > We can't rely on the new coordinator receiving a MergeView, because the old coordinator might have received a MergeView and died soon afterwards. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4442) Package remoting jars for the embedded cli client

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4442?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4442: ----------------------------------- Fix Version/s: 7.1.0.Alpha1 (was: 7.0.0.Final) > Package remoting jars for the embedded cli client > ------------------------------------------------- > > Key: ISPN-4442 > URL: https://issues.jboss.org/browse/ISPN-4442 > Project: Infinispan > Issue Type: Bug > Components: CLI > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.1.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4463) AsyncAPITest.testAsyncMethodWithLifespanAndMaxIdle fails randomly

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4463?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4463: ----------------------------------- Fix Version/s: 7.1.0.Alpha1 (was: 7.0.0.Final) > AsyncAPITest.testAsyncMethodWithLifespanAndMaxIdle fails randomly > ----------------------------------------------------------------- > > Key: ISPN-4463 > URL: https://issues.jboss.org/browse/ISPN-4463 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Alpha4 > Reporter: Vitalii Chepeliuk > Priority: Blocker > Labels: testsuite_stability > Fix For: 7.1.0.Alpha1 > > Attachments: AsyncAPITest.log > > > {noformat} > java.lang.AssertionError: Entry evicted too soon! > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.infinispan.api.AsyncAPITest.verifyEviction(AsyncAPITest.java:356) > at org.infinispan.api.AsyncAPITest.testAsyncMethodWithLifespanAndMaxIdle(AsyncAPITest.java:279) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:94) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:619) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:714) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) > at org.testng.TestRunner.privateRun(TestRunner.java:767) > at org.testng.TestRunner.run(TestRunner.java:617) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:37) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368) > at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) > at java.util.concurrent.FutureTask.run(FutureTask.java:273) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1176) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) > at java.lang.Thread.run(Thread.java:853) > {noformat} > Jenkins failer here > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4444) After state transfer, a node is able to read keys it no longer owns from its data container

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4444?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4444: ----------------------------------- Fix Version/s: 7.1.0.Alpha1 (was: 7.0.0.Final) > After state transfer, a node is able to read keys it no longer owns from its data container > ------------------------------------------------------------------------------------------- > > Key: ISPN-4444 > URL: https://issues.jboss.org/browse/ISPN-4444 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.0.0.Alpha4 > Reporter: Dan Berindei > Priority: Critical > Fix For: 7.1.0.Alpha1 > > > When state transfer ends and each node receives a CH_UPDATE command from the coordinator, it first installs the new topology and then it starts invalidating entries it no longer owns. > However, there are two cases when the node can still read its stale values: > 1. If L1 is enabled, it will look in the local DataContainer first, regardless of the key's location. > 2. If L1 is disabled, but the key was removed on the new owners, the node will still look up the key in the local DataContainer after receiving a null response. > The problem can be reproduced with {{TxReadAfterLosingOwnershipTest}} and its subclasses, by replacing the {{operation.update(cache(1));}} line with {{operation.update(cache(0));}} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4560) FD_SOCK client socket connection timeout in the test suite

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4560?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4560: ----------------------------------- Fix Version/s: 7.1.0.Alpha1 (was: 7.0.0.Final) > FD_SOCK client socket connection timeout in the test suite > ---------------------------------------------------------- > > Key: ISPN-4560 > URL: https://issues.jboss.org/browse/ISPN-4560 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 7.0.0.Alpha5 > Reporter: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 7.1.0.Alpha1 > > > At least some of the {{createBeforeMethod}} failures in the test suite seem to be caused by FD_SOCK, which is not able to connect to its peer: > {noformat} > 08:28:08,144 DEBUG (testng-L1StateTransferOverwriteTest:) [FD_SOCK] L1StateTransferOverwriteTest-NodeBC-2827: VIEW_CHANGE received: [L1StateTransferOverwriteTest-NodeBC-2827] > 08:28:12,558 DEBUG (Incoming-1,L1StateTransferOverwriteTest-NodeBC-2827:) [FD_SOCK] L1StateTransferOverwriteTest-NodeBC-2827: VIEW_CHANGE received: [L1StateTransferOverwriteTest-NodeBC-2827, L1StateTransferOverwriteTest-NodeBD-12942] > 08:28:12,631 DEBUG (FD_SOCK pinger,L1StateTransferOverwriteTest-NodeBC-2827:) [FD_SOCK] L1StateTransferOverwriteTest-NodeBC-2827: ping_dest is L1StateTransferOverwriteTest-NodeBD-12942, pingable_mbrs=[L1StateTransferOverwriteTest-NodeBC-2827, L1StateTransferOverwriteTest-NodeBD-12942] > 08:28:12,716 DEBUG (testng-L1StateTransferOverwriteTest:) [FD_SOCK] L1StateTransferOverwriteTest-NodeBD-12942: VIEW_CHANGE received: [L1StateTransferOverwriteTest-NodeBC-2827, L1StateTransferOverwriteTest-NodeBD-12942] > 08:28:12,719 DEBUG (ViewHandler,NodeBC-2827:) [STABLE] resuming message garbage collection > 08:28:20,213 WARN (FD_SOCK pinger,L1StateTransferOverwriteTest-NodeBC-2827:) [FD_SOCK] L1StateTransferOverwriteTest-NodeBC-2827: creating the client socket failed: java.net.SocketTimeoutException > 08:28:20,230 DEBUG (FD_SOCK pinger,L1StateTransferOverwriteTest-NodeBC-2827:) [FD_SOCK] L1StateTransferOverwriteTest-NodeBC-2827: could not create socket to L1StateTransferOverwriteTest-NodeBD-12942 (pinger thread is running) > 08:28:20,230 DEBUG (FD_SOCK pinger,L1StateTransferOverwriteTest-NodeBC-2827:) [FD_SOCK] L1StateTransferOverwriteTest-NodeBC-2827: suspecting L1StateTransferOverwriteTest-NodeBD-12942 > 08:28:20,230 DEBUG (FD_SOCK pinger,L1StateTransferOverwriteTest-NodeBC-2827:) [FD_SOCK] L1StateTransferOverwriteTest-NodeBC-2827: ping_dest is null, pingable_mbrs=[L1StateTransferOverwriteTest-NodeBC-2827] > 08:28:20,232 DEBUG (INT-1,L1StateTransferOverwriteTest-NodeBC-2827:) [FD_SOCK] L1StateTransferOverwriteTest-NodeBC-2827: suspecting [L1StateTransferOverwriteTest-NodeBD-12942] > 08:28:20,241 DEBUG (Incoming-1,L1StateTransferOverwriteTest-NodeBC-2827:) [FD_SOCK] L1StateTransferOverwriteTest-NodeBC-2827: VIEW_CHANGE received: [L1StateTransferOverwriteTest-NodeBC-2827] > 08:28:21,442 DEBUG (FD_SOCK pinger,L1StateTransferOverwriteTest-NodeBD-12942:) [FD_SOCK] L1StateTransferOverwriteTest-NodeBD-12942: ping_dest is L1StateTransferOverwriteTest-NodeBC-2827, pingable_mbrs=[L1StateTransferOverwriteTest-NodeBC-2827, L1StateTransferOverwriteTest-NodeBD-12942] > 08:28:21,442 DEBUG (FD_SOCK pinger,NodeBD-12942:) [FD_SOCK] NodeBD-12942: ping_dest is NodeBC-2827, pingable_mbrs=[NodeBC-2827, NodeBD-12942] > {noformat} > There is no message in the log for about 8 seconds (at least for this test), so the timeout could be caused by a GC and/or StateTransferFunctionalTest using too much CPU. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4546) Possible stale lock when the primary owner leaves during rebalance

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4546?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4546: ----------------------------------- Fix Version/s: 7.1.0.Alpha1 (was: 7.0.0.Final) > Possible stale lock when the primary owner leaves during rebalance > ------------------------------------------------------------------ > > Key: ISPN-4546 > URL: https://issues.jboss.org/browse/ISPN-4546 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.0.0.Alpha5 > Reporter: Dan Berindei > Fix For: 7.1.0.Alpha1 > > > Topology T: coordinator = A, owners(k) = [C, D], pending_owners(k) = null > B sends prepareCommand(tx1, put(k, v)) to C, D > D adds backup locks and replies > C acquires lock, ready to send reply to B > A starts installing topology T+1: owners(k) = [C, D], pending_owners(k) = [C, E] > A, C and E install topology T+1, B and D do not > E requests and receives tx data from C, including tx1 > C leaves > B sees a SuspectException, sends rollbackCommand(tx1) to C, D > D removes tx1 > C has left, but is ignored > B reports to the user that the tx has been rolled back > B and D install topology T+1 (optional) > A starts installing topology T+2: owners(k) = [D], pending_owners(k) = [E] > A, B, D, E all install topology T+2 > E requests and receives state from D, but it does not remove tx1 > A starts installing topology T+3: owners(k) = [E], pending_owners(k) = null > E now has a stale backup lock on k > It seems very hard to reproduce in production: C would have to leave soon enough so that B and D haven't received the T+1 topology yet, but late enough for it to send its transaction data to E. > A possible solution would be to catch any SuspectException during prepare/commit/rollback (without ignoring leavers), wait for a new topology, and replicate the command again on the new owners. Obviously, this wouldn't work with asynchronous prepare/commit/rollback. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2014