[JBoss JIRA] (ISPN-2543) org.infinispan.server.memcached.MemcachedClusteredStatsTest.testSingleConnectionPerServer fails periodically on all environments
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2543?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2543:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 879545|https://bugzilla.redhat.com/show_bug.cgi?id=879545] from ASSIGNED to ON_QA
> org.infinispan.server.memcached.MemcachedClusteredStatsTest.testSingleConnectionPerServer fails periodically on all environments
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2543
> URL: https://issues.jboss.org/browse/ISPN-2543
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.0.Beta4
> Reporter: Anna Manukyan
> Assignee: Tristan Tarrant
> Labels: testsuite_stability
>
> org.infinispan.server.memcached.MemcachedClusteredStatsTest.testSingleConnectionPerServer test fails periodically on RHEL6_x86 and RHEL6_x86_64 - JDK7, IBM JDK7 & OpenJDK7. The test also fails on Windows 2008 64 bit with Oracle JDK 7.
> The exception is:
> {code}
> Error Message
> Unknown attribute 'NumberOfGlobalConnections'. Known attributes names are: [port, numberWorkerThreads, receiveBufferSize, totalBytesRead, numberOfGlobalConnections, idleTimeout, totalBytesWritten, hostName, numberOfLocalConnections, sendBufferSize, tpcNoDelay]
> Stacktrace
> javax.management.AttributeNotFoundException: Unknown attribute 'NumberOfGlobalConnections'. Known attributes names are: [port, numberWorkerThreads, receiveBufferSize, totalBytesRead, numberOfGlobalConnections, idleTimeout, totalBytesWritten, hostName, numberOfLocalConnections, sendBufferSize, tpcNoDelay]
> at org.infinispan.jmx.ResourceDMBean.getAttribute(ResourceDMBean.java:201)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:668)
> at org.infinispan.server.core.ConnectionStatsTests$.testGlobalConnections(ConnectionStatsTests.scala:68)
> at org.infinispan.server.memcached.MemcachedClusteredStatsTest.testSingleConnectionPerServer(MemcachedClusteredStatsTest.scala:61)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> 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$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 4 months
[JBoss JIRA] (ISPN-2187) Pre-Invocation flag PUT_FOR_EXTERNAL_READ throws exception
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2187?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2187:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 847062|https://bugzilla.redhat.com/show_bug.cgi?id=847062] from ASSIGNED to ON_QA
> Pre-Invocation flag PUT_FOR_EXTERNAL_READ throws exception
> ----------------------------------------------------------
>
> Key: ISPN-2187
> URL: https://issues.jboss.org/browse/ISPN-2187
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Reporter: Anna Manukyan
> Assignee: Galder Zamarreño
> Labels: jdg6
> Fix For: 5.2.0.Alpha3, 5.2.0.Final
>
>
> Hi,
> While writing tests for Infinispan Flag.PUT_FOR_EXTERNAL_READ the following issue has been found.
> In documentation it is said:
> PUT_FOR_EXTERNAL_READ
> Flags the invocation as a Cache.putForExternalRead(Object, Object) call, as opposed to a regular Map.put(Object, Object).
> And the documentation for Cache.putForExternalRead(Object, Object) says:
> void putForExternalRead(K key,
> V value)
> ...................
> Errors and exceptions are 'silent' - logged at a much lower level than normal, and this method does not throw exceptions
> The issue is the following:
> when trying to perform operation using PUT_FOR_EXTERNAL_READ flag, the exception is thrown, it is not 'silent'.
> cache1.getAdvancedCache().withFlags(Flag.PUT_FOR_EXTERNAL_READ).put(key, value);
> The test is the following:
> {code}
> public void testExceptionSuppression() throws Exception {
> Cache cache1 = cache(0, "replSync");
> Cache cache2 = cache(1, "replSync");
> Transport mockTransport = mock(Transport.class);
> RpcManagerImpl rpcManager = (RpcManagerImpl) TestingUtil.extractComponent(cache1, RpcManager.class);
> Transport originalTransport = TestingUtil.extractComponent(cache1, Transport.class);
> try {
> Address mockAddress1 = mock(Address.class);
> Address mockAddress2 = mock(Address.class);
> List<Address> memberList = new ArrayList<Address>(2);
> memberList.add(mockAddress1);
> memberList.add(mockAddress2);
> rpcManager.setTransport(mockTransport);
> when(mockTransport.getMembers()).thenReturn(memberList);
> when(mockTransport.getViewId()).thenReturn(originalTransport.getViewId());
> when(mockTransport.invokeRemotely(anyAddresses(), (CacheRpcCommand) anyObject(), anyResponseMode(),
> anyLong(), anyBoolean(), (ResponseFilter) anyObject()))
> .thenThrow(new RuntimeException("Barf!"));
> try {
> cache1.put(key, value);
> fail("Should have barfed");
> }
> catch (RuntimeException re) {
> }
> // clean up any indeterminate state left over
> try {
> cache1.remove(key);
> fail("Should have barfed");
> }
> catch (RuntimeException re) {
> }
> assertNull("Should have cleaned up", cache1.get(key));
> // should not barf
> cache1.putForExternalRead(key, value);
> /** ------------------- Testing the same feature with Flag.PUT_FOR_EXTERNAL_READ **/
> try {
> cache1.remove(key);
> fail("Should have barfed");
> }
> catch (RuntimeException re) {
> }
> cache1.getAdvancedCache().withFlags(Flag.PUT_FOR_EXTERNAL_READ).put(key, value);
> }
> finally {
> if (rpcManager != null) rpcManager.setTransport(originalTransport);
> }
> }
> {code}
> Best regards,
> Anna.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 4 months
[JBoss JIRA] (ISPN-2566) TopologyAwareConsistentHashFactory rebalance doesn't redistribute data properly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2566?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2566:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 868832|https://bugzilla.redhat.com/show_bug.cgi?id=868832] from MODIFIED to ON_QA
> TopologyAwareConsistentHashFactory rebalance doesn't redistribute data properly
> -------------------------------------------------------------------------------
>
> Key: ISPN-2566
> URL: https://issues.jboss.org/browse/ISPN-2566
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 5.2.0.Beta4
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 5.2.0.Beta6, 5.2.0.Final
>
>
> Say we have a topology-aware cache with numOwners = 2 and two nodes: A(machine=m1) and B(machine=m1). When node C(machine=m2) joins, it should own every key, either as a primary or as a backup owner. This doesn't happen, node C owns just as many segments as nodes A and B.
> Example:
> {noformat}
> 19:21:17,295 TRACE [org.infinispan.topology.ClusterTopologyManagerImpl] (undefined) Updating cache topology topology for rebalance:
> CacheTopology{id=3, currentCH=DefaultConsistentHash{numSegments=80, numOwners=2,
> members=[node0/default(primary), node1/default(primary)],
> owners={0: 0 1, 1: 0 1, 2: 0 1, 3: 0 1, 4: 0 1, 5: 0 1, 6: 0 1, 7: 0 1,
> 8: 0 1, 9: 0 1, 10: 0 1, 11: 0 1, 12: 0 1, 13: 0 1, 14: 0 1, 15: 0 1,
> 16: 0 1, 17: 0 1, 18: 0 1, 19: 0 1, 20: 0 1, 21: 0 1, 22: 0 1, 23: 0 1,
> 24: 0 1, 25: 0 1, 26: 0 1, 27: 0 1, 28: 0 1, 29: 0 1, 30: 0 1, 31: 0 1,
> 32: 0 1, 33: 0 1, 34: 0 1, 35: 0 1, 36: 0 1, 37: 0 1, 38: 0 1, 39: 0 1,
> 40: 1 0, 41: 1 0, 42: 1 0, 43: 1 0, 44: 1 0, 45: 1 0, 46: 1 0, 47: 1 0,
> 48: 1 0, 49: 1 0, 50: 1 0, 51: 1 0, 52: 1 0, 53: 1 0, 54: 1 0, 55: 1 0,
> 56: 1 0, 57: 1 0, 58: 1 0, 59: 1 0, 60: 1 0, 61: 1 0, 62: 1 0, 63: 1 0,
> 64: 1 0, 65: 1 0, 66: 1 0, 67: 1 0, 68: 1 0, 69: 1 0, 70: 1 0, 71: 1 0,
> 72: 1 0, 73: 1 0, 74: 1 0, 75: 1 0, 76: 1 0, 77: 1 0, 78: 1 0, 79: 1 0},
> pendingCH=DefaultConsistentHash{numSegments=80, numOwners=2,
> members=[node0/default(primary), node1/default(primary), node2/default(secondary)],
> owners={0: 0 1, 1: 0 1, 2: 0 1, 3: 0 1, 4: 0 1, 5: 0 1, 6: 0 1, 7: 0 1,
> 8: 0 1, 9: 0 1, 10: 0 1, 11: 0 1, 12: 0 1, 13: 0 1, 14: 0 1, 15: 0 1,
> 16: 0 1, 17: 0 1, 18: 0 1, 19: 0 1, 20: 0 1, 21: 0 1, 22: 0 1, 23: 0 1,
> 24: 0 1, 25: 0 1, 26: 0 1, 27: 2 0, 28: 2 0, 29: 2 0, 30: 2 0, 31: 2 0,
> 32: 2 0, 33: 2 0, 34: 2 0, 35: 2 0, 36: 2 0, 37: 2 0, 38: 2 0, 39: 2 0,
> 40: 1 0, 41: 1 0, 42: 1 0, 43: 1 0, 44: 1 0, 45: 1 0, 46: 1 0, 47: 1 0,
> 48: 1 0, 49: 1 0, 50: 1 0, 51: 1 0, 52: 1 0, 53: 1 0, 54: 1 0, 55: 1 0,
> 56: 1 0, 57: 1 0, 58: 1 0, 59: 1 0, 60: 1 0, 61: 1 0, 62: 1 0, 63: 1 0,
> 64: 1 0, 65: 1 0, 66: 1 0, 67: 2 1, 68: 2 1, 69: 2 1, 70: 2 1, 71: 2 1,
> 72: 2 1, 73: 2 1, 74: 2 1, 75: 2 1, 76: 2 1, 77: 2 1, 78: 2 1, 79: 2 1}}
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 4 months
[JBoss JIRA] (ISPN-2410) A command forwarded back to the originator can time out waiting on a key already locked by itself
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2410?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2410:
--------------------------------
Fix Version/s: 5.2.0.CR1
(was: 5.2.0.Beta6)
> A command forwarded back to the originator can time out waiting on a key already locked by itself
> -------------------------------------------------------------------------------------------------
>
> Key: ISPN-2410
> URL: https://issues.jboss.org/browse/ISPN-2410
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.0.Beta2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Blocker
> Fix For: 5.2.0.CR1
>
>
> If a rebalance happens while a prepare command is executing on a remote node, and the originator has become an owner, it makes sense to forward the command back to the originator to lock the keys (or just add them to the backup locks list).
> However, we don't keep the old consistent hashes around, so we don't know if the originator became an owner after invoking the remote command or was already an owner. So if the topology changed, we always forward the prepare back to the owner.
> Back on the originator, minTxTopologyId < currentTopologyId, so the prepare command has to wait for all the backup locks from pending transactions to be released. The problem is that we wait for the current transaction as well, causing a deadlock.
> Seen in OnePhaseXATest:
> {noformat}
> 18:07:46,873 TRACE (testng-OnePhaseXATest:TestCache) [RpcManagerImpl] NodeA-46125 broadcasting call PrepareCommand {modifications=[PutKeyValueCommand{key=key0, value=value, flags=null, putIfAbsent=false, lifespanMillis=-1, maxIdleTimeMillis=-1}], onePhaseCommit=false, gtx=GlobalTransaction:<NodeA-46125>:4353:local, cacheName='TestCache', topologyId=-1} to recipient list null
> 18:07:46,873 DEBUG (transport-thread-2,NodeA:TestCache) [LocalTopologyManagerImpl] Updating local consistent hash(es) for cache TestCache: new topology = CacheTopology{id=2, currentCH=ReplicatedConsistentHash{members=[NodeA-46125, NodeB-49450]}, pendingCH=null}
> 18:07:46,894 TRACE (OOB-1,ISPN,NodeB-49450:TestCache) [StateTransferManagerImpl] Forwarding command PrepareCommand {modifications=[PutKeyValueCommand{key=key0, value=value, flags=null, putIfAbsent=false, lifespanMillis=-1, maxIdleTimeMillis=-1}], onePhaseCommit=false, gtx=GlobalTransaction:<NodeA-46125>:4353:remote, cacheName='TestCache', topologyId=2} to new targets [NodeA-46125]
> 18:07:46,935 TRACE (OOB-3,ISPN,NodeA-46125:TestCache) [StateTransferInterceptor] handleTopologyAffectedCommand for command PrepareCommand {modifications=[PutKeyValueCommand{key=key0, value=value, flags=null, putIfAbsent=false, lifespanMillis=-1, maxIdleTimeMillis=-1}], onePhaseCommit=false, gtx=GlobalTransaction:<NodeA-46125>:4353:remote, cacheName='TestCache', topologyId=2}, originLocal=false
> 18:07:46,935 TRACE (OOB-3,ISPN,NodeA-46125:TestCache) [AbstractCacheTransaction] Transaction gtx=GlobalTransaction:<NodeA-46125>:4353:local potentially locks key key0? true
> 18:08:16,874 TRACE (testng-OnePhaseXATest:TestCache) [RpcManagerImpl] replication exception:
> org.infinispan.CacheException: org.jgroups.TimeoutException: timeout sending message to NodeB-49450
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 4 months
[JBoss JIRA] (ISPN-2459) Rollback not preceded by Prepare sent to remote site
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2459?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2459:
--------------------------------
Fix Version/s: 5.2.0.CR1
(was: 5.2.0.Beta6)
> Rollback not preceded by Prepare sent to remote site
> ----------------------------------------------------
>
> Key: ISPN-2459
> URL: https://issues.jboss.org/browse/ISPN-2459
> Project: Infinispan
> Issue Type: Bug
> Components: Cross-Site Replication, Transactions
> Affects Versions: 5.2.0.Beta3
> Reporter: Radim Vansa
> Assignee: Mircea Markus
> Priority: Critical
> Fix For: 5.2.0.CR1, 5.2.0.Final
>
>
> When a {{TransactionManager.rollback()}} is called under optimistic locking, the {{RollbackCommand}} is sent to the remote site with backup cache. This makes no sense as there are no changes to roll back, and furthermore, the command fails in the remote site as the transaction which is rolled back is not known:
> {code}
> 05:37:00,727 WARN [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (Incoming-2,global,_edg-perf01-58034:LON) Problems invoking command SingleRpcCommand{cacheName='nycCache', command=RollbackCommand {gtx=GlobalTransaction:<c25cba86-1e90-e190-b101-155e93063c9c[T]>:5:local, cacheName='nycCache', topologyId=-1}}
> org.infinispan.CacheException: Couldn't find a local transaction corresponding to remote transaction GlobalTransaction:<c25cba86-1e90-e190-b101-155e93063c9c[T]>:5:local
> at org.infinispan.xsite.BackupReceiver$BackupCacheUpdater.completeTransaction(BackupReceiver.java:187)
> at org.infinispan.xsite.BackupReceiver$BackupCacheUpdater.visitRollbackCommand(BackupReceiver.java:178)
> at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:61)
> at org.infinispan.xsite.BackupReceiver.handleRemoteCommand(BackupReceiver.java:76)
> at org.infinispan.xsite.BackupReceiverRepositoryImpl.handleRemoteCommand(BackupReceiverRepositoryImpl.java:60)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromRemoteSite(CommandAwareRpcDispatcher.java:240)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:217)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:483)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:390)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:248)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:604)
> at org.jgroups.JChannel.up(JChannel.java:670)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
> at org.jgroups.protocols.relay.RELAY2.deliver(RELAY2.java:420)
> at org.jgroups.protocols.relay.RELAY2.route(RELAY2.java:316)
> at org.jgroups.protocols.relay.RELAY2.handleMessage(RELAY2.java:292)
> at org.jgroups.protocols.relay.RELAY2.handleRelayMessage(RELAY2.java:272)
> at org.jgroups.protocols.relay.Relayer$Bridge.receive(Relayer.java:214)
> at org.jgroups.JChannel.invokeCallback(JChannel.java:712)
> at org.jgroups.JChannel.up(JChannel.java:673)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
> at org.jgroups.protocols.RSVP.up(RSVP.java:188)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:896)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
> at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:769)
> at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:414)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:601)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
> at org.jgroups.protocols.Discovery.up(Discovery.java:359)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1293)
> at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1856)
> at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1829)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 4 months
[JBoss JIRA] (ISPN-2352) Second invocation of ClusteredQueryImpl.lazyIterator() yields results in reverse order
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2352?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2352:
--------------------------------
Fix Version/s: 5.2.0.CR1
(was: 5.2.0.Beta6)
> Second invocation of ClusteredQueryImpl.lazyIterator() yields results in reverse order
> --------------------------------------------------------------------------------------
>
> Key: ISPN-2352
> URL: https://issues.jboss.org/browse/ISPN-2352
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Affects Versions: 5.1.8.Final, 5.2.0.Alpha4
> Reporter: Marko Lukša
> Assignee: Galder Zamarreño
> Priority: Minor
> Fix For: 5.2.0.CR1, 5.2.0.Final
>
>
> When you invoke lazyIterator() for the 2nd time on the same ClusteredQueryImpl instance, the iterator returns results in reverse order. This only occurs when the query has a Sort specified.
> Caused by DistributedIterator.setTopDocs(), which inverts the reverse flag on SortField.
> The same is probably also true for ClusteredQueryImpl.iterator()
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 4 months
[JBoss JIRA] (ISPN-2580) Do not request segments from all nodes at once
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2580?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2580:
--------------------------------
Fix Version/s: 5.2.0.CR1
(was: 5.2.0.Beta6)
> Do not request segments from all nodes at once
> ----------------------------------------------
>
> Key: ISPN-2580
> URL: https://issues.jboss.org/browse/ISPN-2580
> Project: Infinispan
> Issue Type: Enhancement
> Components: State transfer
> Affects Versions: 5.2.0.Beta5
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 5.2.0.CR1
>
>
> When a new node joins large cluster filled with data, it gets the new CH and REBALANCE_START command, and requests data from all nodes at once (or almost all with even distribution of segments). It may be not able to handle this amount of transfers in parallel even at the JGroups level - this results in data sent to the node and discarded at the receiver, sent again and again. With a heavy congestion the node just buffers fragments of a message from one sender and never passes this up.
> The number of StateRequestCommands(START_STATE_TRANSFER) should be limited so that the node is not congested.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 4 months