February 2016 - infinispan-issues

[JBoss JIRA] (ISPN-5469) Remote-executor threads should not block during RPCs

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5469?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5469: ---------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.2.0.Beta2) > Remote-executor threads should not block during RPCs > ---------------------------------------------------- > > Key: ISPN-5469 > URL: https://issues.jboss.org/browse/ISPN-5469 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 7.2.1.Final > Reporter: Dan Berindei > Fix For: 8.2.0.CR1 > > > This is particularly important in non-transactional caches, where the primary owner has to forward a command to the backup owners. The remote-executor thread on the primary should not be blocked while waiting for the backup responses, and instead process other commands. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5468) Change the interceptors to move the new sequential interfaces

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5468?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5468: ---------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.2.0.Beta2) > Change the interceptors to move the new sequential interfaces > ------------------------------------------------------------- > > Key: ISPN-5468 > URL: https://issues.jboss.org/browse/ISPN-5468 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 7.2.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.2.0.CR1 > > > The first step is to move all interceptors to the new sequential interfaces, without actually allowing the command execution to be suspended and resumed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5467) Design new interceptor interfaces for sequential invocation

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5467?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5467: ---------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.2.0.Beta2) > Design new interceptor interfaces for sequential invocation > ----------------------------------------------------------- > > Key: ISPN-5467 > URL: https://issues.jboss.org/browse/ISPN-5467 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 7.2.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.2.0.CR1 > > > We need the interceptors to execute in sequence instead of using a stack in order to allow interrupting the execution of a command on one thread and continuing the execution on another thread. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5427) Change getAll to return ordered map

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5427?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5427: ---------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.2.0.Beta2) > Change getAll to return ordered map > ----------------------------------- > > Key: ISPN-5427 > URL: https://issues.jboss.org/browse/ISPN-5427 > Project: Infinispan > Issue Type: Enhancement > Components: Core, Remote Protocols > Reporter: William Burns > Assignee: William Burns > Fix For: 8.2.0.CR1 > > > Currently our getAll returns a map of entries that exist in the cache in any order. We could enhance this to return a map where the entries are in the same iteration order of the Set (important when the user uses a LinkedHashSet). We could even do something like List<V> getAll(List<K>) to show better ordering as an option too. > This has 2 immediate advantages. > 1. Remote getAll no longer requires to serialize all the keys in the response since it knows which values map to which keys based on what it sent. > 2. Query results need ordered List as well. See query/src/main/java/org/infinispan/query/impl/EntityLoader.java -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5454) XSite: RetryMechanismTest random failures

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5454?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5454: ---------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.2.0.Beta2) > XSite: RetryMechanismTest random failures > ----------------------------------------- > > Key: ISPN-5454 > URL: https://issues.jboss.org/browse/ISPN-5454 > Project: Infinispan > Issue Type: Bug > Components: Cross-Site Replication > Affects Versions: 7.2.1.Final > Reporter: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 8.2.0.CR1 > > > {{ClusteredCacheBackupReceiver.awaitRemoteTask()}} doesn't respect the state push command's timeout, at least when it's smaller than the sync replication timeout in the target cache. When that happens, the state provider will resend the state, and there will be 2 state push commands executing at the same time. > RetryMechanismTest changes the state push timeout to 2 seconds, but the sync replication timeout stays at 15 seconds. This causes failures in {{testRetryLocally}} and {{testFailRetryLocally}}, if it takes more than 2 seconds to suspect the killed node. > {noformat} > 10:02:13,007 TRACE (asyncTransportThread-8,NodeN:) [RetryOnFailureXSiteCommand] Sending XSiteStatePushCommand{cacheName=___defaultcache, timeout=2000 (1 keys)} to [NYC (sync, timeout=2000)] > 10:02:16,008 TRACE (asyncTransportThread-8,NodeN:) [RetryOnFailureXSiteCommand] Sending XSiteStatePushCommand{cacheName=___defaultcache, timeout=2000 (1 keys)} to [NYC (sync, timeout=2000)] > 10:02:16,040 TRACE (asyncTransportThread-4,NodeP:) [RpcManagerImpl] replication exception: > org.infinispan.remoting.transport.jgroups.SuspectException: Node NodeQ-56809 was suspected > 10:02:16,040 TRACE (asyncTransportThread-0,NodeP:) [RpcManagerImpl] replication exception: > org.infinispan.remoting.transport.jgroups.SuspectException: Node NodeQ-56809 was suspected > 10:02:19,147 ERROR (testng-RetryMechanismTest:) [UnitTestTestNGListener] Test testFailRetryLocally(org.infinispan.xsite.statetransfer.failures.RetryMechanismTest) failed. > java.lang.AssertionError: expected:<2> but was:<3> > 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.statetransfer.failures.RetryMechanismTest.testFailRetryLocally(RetryMechanismTest.java:227) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5426) Create a remote query tutorial

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5426?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5426: ---------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.2.0.Beta2) > Create a remote query tutorial > ------------------------------ > > Key: ISPN-5426 > URL: https://issues.jboss.org/browse/ISPN-5426 > Project: Infinispan > Issue Type: Feature Request > Components: Documentation-Query, Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.2.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5453) X-site state transfer: retry locally if local state push throws a SuspectException

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5453?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5453: ---------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.2.0.Beta2) > X-site state transfer: retry locally if local state push throws a SuspectException > ---------------------------------------------------------------------------------- > > Key: ISPN-5453 > URL: https://issues.jboss.org/browse/ISPN-5453 > Project: Infinispan > Issue Type: Bug > Components: Core, Cross-Site Replication > Affects Versions: 7.2.1.Final > Reporter: Dan Berindei > Priority: Minor > Fix For: 8.2.0.CR1 > > > When the local state push command throws a {{SuspectException}}, we currently retry remotely unless the target node was already removed from the cache topology. This will fail with another {{SuspectException}}, so it would be better to retry locally the first time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5507) Transactions committed immediately before cache stop can block shutdown

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5507?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5507: ---------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.2.0.Beta2) > Transactions committed immediately before cache stop can block shutdown > ----------------------------------------------------------------------- > > Key: ISPN-5507 > URL: https://issues.jboss.org/browse/ISPN-5507 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 7.2.1.Final, 8.0.0.Alpha1 > Reporter: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 8.2.0.CR1 > > > This is causing random failures in {{DistributedEntryRetrieverTxTest.verifyNodeLeavesBeforeGettingData}}. > The test inserts some values into the cache, starts an iteration, and then kills one of the nodes. In rare instances, the killed cache only receives the TxCompletionCommand for one of the writes after it started the shutdown, and ignores it. That leaves the remote tx on-going, and {{TransactionTable.shutDownGracefully()}} blocks for 30 seconds - causing a {{TimeoutException}} elsewhere in the test. > {noformat} > 10:52:18,129 TRACE (remote-thread-NodeAM-p12133-t6:) [CommandAwareRpcDispatcher] About to send back response SuccessfulResponse{responseValue=null} for command CommitCommand {gtx=GlobalTransaction:<NodeAL-45757>:22325:remote, cacheName='org.infinispan.iteration.DistributedEntryRetrieverTxTest', topologyId=4} > 10:52:18,129 TRACE (testng-DistributedEntryRetrieverTxTest:) [JGroupsTransport] dests=[NodeAM-45518, NodeAL-45757], command=TxCompletionNotificationCommand{ xid=null, internalId=0, topologyId=4, gtx=GlobalTransaction:<NodeAL-45757>:22325:local, cacheName=org.infinispan.iteration.DistributedEntryRetrieverTxTest} , mode=ASYNCHRONOUS, timeout=15000 > 10:52:18,133 DEBUG (testng-DistributedEntryRetrieverTxTest:) [CacheImpl] Stopping cache org.infinispan.iteration.DistributedEntryRetrieverTxTest on NodeAM-45518 > 10:52:18,133 TRACE (OOB-2,NodeAM-45518:) [GlobalInboundInvocationHandler] Attempting to execute CacheRpcCommand: TxCompletionNotificationCommand{ xid=null, internalId=0, topologyId=4, gtx=GlobalTransaction:<NodeAL-45757>:22325:local, cacheName=org.infinispan.iteration.DistributedEntryRetrieverTxTest} [sender=NodeAL-45757] > 10:52:18,133 TRACE (OOB-2,NodeAM-45518:) [GlobalInboundInvocationHandler] Silently ignoring that org.infinispan.iteration.DistributedEntryRetrieverTxTest cache is not defined > 10:52:18,133 DEBUG (testng-DistributedEntryRetrieverTxTest:) [TransactionTable] Wait for on-going transactions to finish for 30 seconds. > 10:52:48,139 WARN (testng-DistributedEntryRetrieverTxTest:) [TransactionTable] ISPN000100: Stopping, but there are 0 local transactions and 1 remote transactions that did not finish in time. > 10:52:48,386 ERROR (testng-DistributedEntryRetrieverTxTest:) [UnitTestTestNGListener] Test verifyNodeLeavesBeforeGettingData(org.infinispan.iteration.DistributedEntryRetrieverTxTest) failed. > java.lang.IllegalStateException: Thread already timed out waiting for event pre_send_response_released > at org.infinispan.test.fwk.CheckPoint.trigger(CheckPoint.java:131) > at org.infinispan.test.fwk.CheckPoint.trigger(CheckPoint.java:116) > at org.infinispan.iteration.DistributedEntryRetrieverTest.verifyNodeLeavesBeforeGettingData(DistributedEntryRetrieverTest.java:105) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5499) SizeTest.testPersistentDistributedCacheSize random failures

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5499?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5499: ---------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.2.0.Beta2) > SizeTest.testPersistentDistributedCacheSize random failures > ----------------------------------------------------------- > > Key: ISPN-5499 > URL: https://issues.jboss.org/browse/ISPN-5499 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 7.2.1.Final > Reporter: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 8.2.0.CR1 > > > {noformat} > 16:04:28,678 ERROR (testng-SizeTest:) [UnitTestTestNGListener] Test testPersistentDistributedCacheSize(org.infinispan.client.hotrod.SizeTest) failed. > java.lang.AssertionError: expected:<20> but was:<38> > 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.client.hotrod.SizeTest.testPersistentDistributedCacheSize(SizeTest.java:59) > {noformat} > I have been able to make the test fail reliably by replacing the assertion on line 57 with this: > {code} > for (int i = 0; i < SIZE; i++) { > assertEquals(SIZE, clients.get(0).getCache(cacheName).size()); > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5506) Dist/ReplEmbeddedRestHotRodTest failing randomly with "java.net.SocketException: Socket closed"

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5506?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5506: ---------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.2.0.Beta2) > Dist/ReplEmbeddedRestHotRodTest failing randomly with "java.net.SocketException: Socket closed" > ----------------------------------------------------------------------------------------------- > > Key: ISPN-5506 > URL: https://issues.jboss.org/browse/ISPN-5506 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 7.2.1.Final, 8.0.0.Alpha1 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 8.2.0.CR1 > > Attachments: infinispan_5506.tgz > > > {code} > testEmbeddedPutRestHotRodGet(org.infinispan.it.compatibility.DistEmbeddedRestHotRodTest) Time elapsed: 0.002 sec <<< FAILURE! > java.net.SocketException: Socket closed > at java.net.PlainSocketImpl.socketConnect(Native Method) > at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) > at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) > at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) > at java.net.Socket.connect(Socket.java:589) > at java.net.Socket.connect(Socket.java:538) > at java.net.Socket.<init>(Socket.java:434) > at java.net.Socket.<init>(Socket.java:286) > at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:80) > at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:122) > at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707) > at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387) > at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171) > at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397) > at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323) > at org.infinispan.it.compatibility.ReplEmbeddedRestHotRodTest.testEmbeddedPutRestHotRodGet(ReplEmbeddedRestHotRodTest.java:80) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2016