August 2015 - infinispan-issues - Jboss List Archives

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

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5453?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5453: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > 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.1.0.Final > > > 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.3.15#6346)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5367) Cache putMap/getAll usage of SegmentAwareMap/Set performance investigation

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5367?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5367: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > Cache putMap/getAll usage of SegmentAwareMap/Set performance investigation > -------------------------------------------------------------------------- > > Key: ISPN-5367 > URL: https://issues.jboss.org/browse/ISPN-5367 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: William Burns > Assignee: William Burns > Fix For: 8.1.0.Final > > > With the putAll method I introduced a SegmentAwareMap and SegmentAwareSet in thoughts that not copying all the elements would help performance. Thinking more it may be better to just make a new shallow copy map for each target instead. Need to do some testing to make sure if one is clearly better than the other. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 3 months

1
0
0 / 0

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

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5454?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5454: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > 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.1.0.Final > > > {{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.3.15#6346)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5424) SemaphoreCompletionService improvements

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5424?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5424: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > SemaphoreCompletionService improvements > --------------------------------------- > > Key: ISPN-5424 > URL: https://issues.jboss.org/browse/ISPN-5424 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 7.2.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.1.0.Final > > > Turns out the {{CompletionService}} features aren't that necessary, and it makes the use of {{Runnable}} more cumbersome. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5340) Expose mutable configuration attributes over JMX

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5340?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5340: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > Expose mutable configuration attributes over JMX > ------------------------------------------------ > > Key: ISPN-5340 > URL: https://issues.jboss.org/browse/ISPN-5340 > Project: Infinispan > Issue Type: Feature Request > Components: JMX, reporting and management > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.1.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5343) Make eviction max-entries parameter configurable at runtime

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5343?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5343: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > Make eviction max-entries parameter configurable at runtime > ----------------------------------------------------------- > > Key: ISPN-5343 > URL: https://issues.jboss.org/browse/ISPN-5343 > Project: Infinispan > Issue Type: Feature Request > Components: Eviction > Affects Versions: 7.2.0.Beta2 > Environment: Infinispan 7/ JDG > Reporter: Duncan Doyle > Assignee: Sebastian Łaskawiec > Fix For: 8.1.0.Final > > > I've got a use-case where I would like to be able to dynamically (at runtime) configure the max-entries parameter of my eviction configuration. This would allow to, for example, decrease the max-entries dynamically when my system starts running oom. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5333) Delete methods which have long been deprecated in Infinispan Query

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5333?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5333: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > Delete methods which have long been deprecated in Infinispan Query > ------------------------------------------------------------------ > > Key: ISPN-5333 > URL: https://issues.jboss.org/browse/ISPN-5333 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Blocker > Fix For: 8.1.0.Final > > > For example: > - {{org.infinispan.query.SearchManager.getQueryFactory()}} > - {{org.infinispan.query.SearchManager.getSearchFactory()}} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5241) Cache topology updates should use the NO_FC flag

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5241?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5241: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > Cache topology updates should use the NO_FC flag > ------------------------------------------------ > > Key: ISPN-5241 > URL: https://issues.jboss.org/browse/ISPN-5241 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.1.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 8.1.0.Final > > > Topology updates are sent while holding the ClusterCacheStatus lock, so they should never block. However, when MFC is present, the topology update can block waiting for enough credits. As most CacheTopologyControlCommands need to acquire the ClusterCacheStatus lock, this can easily lead to a full remote-executor pool (and OOB pool) and the appearance of a deadlock. > What's more, if one node is not responsive, it can block all the other nodes from receiving further topology updates. Topology updates should be as prompt as possible, so we should use the NO_FC flag to ensure that each node receives topology updates as soon as possible. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 3 months

1
0
0 / 0

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

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5506?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5506: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > 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.1.0.Final > > 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.3.15#6346)

10 years, 3 months

1
0
0 / 0

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

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5507?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5507: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > 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.1.0.Final > > > 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.3.15#6346)

10 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues August 2015