[JBoss JIRA] (ISPN-5883) Node can apply new topology after sending status response
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5883?page=com.atlassian.jira.plugin.... ]
Dan Berindei reassigned ISPN-5883:
----------------------------------
Assignee: Dan Berindei
> Node can apply new topology after sending status response
> ---------------------------------------------------------
>
> Key: ISPN-5883
> URL: https://issues.jboss.org/browse/ISPN-5883
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 8.0.1.Final, 7.2.5.Final, 8.1.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Labels: testsuite_stability
> Fix For: 8.1.0.Final
>
>
> {{LocalTopologyManagerImpl}} is responsible for sending the {{ClusterTopologyControlCommand(GET_STATUS)}} response, and when it sends the response it doesn't check the current view id against the new coordinator's view id. If the old coordinator already sent a topology update before the merge, that topology update might be processed after sending the status response. The new coordinator will send a topology update with a topology id of {{max(status response topology ids) + 1}}. The node will then process the topology update from the old coordinator, but it will ignore the topology update from the new coordinator with the same topology id.
> This is extra common in the partition handling tests, e.g. {{BasePessimisticTxPartitionAndMergeTest}} subclasses, because the test "injects" the JGroups view on each node serially, and often the 4th node sends the status response before it gets the new view.
> {noformat}
> 22:16:37,776 DEBUG (remote-thread-NodeD-p26-t6:[]) [LocalTopologyManagerImpl] Sending cluster status response for view 10
> // Topology from NodeC
> 22:16:37,778 DEBUG (transport-thread-NodeD-p28-t2:[]) [LocalTopologyManagerImpl] Updating local topology for cache pes-cache: CacheTopology{id=8, rebalanceId=3, currentCH=DefaultConsistentHash{ns=60, owners = (4)[NodeA-37631: 15+15, NodeB-47846: 15+15, NodeC-46467: 15+15, NodeD-30486: 15+15]}, pendingCH=null, unionCH=null, actualMembers=[NodeC-46467, NodeD-30486]}
> // Later, topology from NodeA
> 22:16:37,827 DEBUG (transport-thread-NodeD-p28-t1:[]) [LocalTopologyManagerImpl] Ignoring late consistent hash update for cache pes-cache, current topology is 8: CacheTopology{id=8, rebalanceId=3, currentCH=DefaultConsistentHash{ns=60, owners = (4)[NodeA-37631: 15+15, NodeB-47846: 15+15, NodeC-46467: 15+15, NodeD-30486: 15+15]}, pendingCH=null, unionCH=null, actualMembers=[NodeA-37631, NodeB-47846, NodeC-46467, NodeD-30486]}
> {noformat}
> As a solution, we can delay sending the status response until we have the same view as the coordinator (or a later one). We already check that the sender is the current coordinator before applying a topology update, so this will guarantee that the we don't apply other topology updates from the old coordinator. Since the status request is only sent after the new view was installed, this will not introduce any delays in the vast majority of cases.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ISPN-3905) Murmurhash3 implementation is slow on String keys
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3905?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-3905:
------------------------------------
I wonder if applications are really reusing String instances to use as cache keys. I would expect most application to use composite keys, by concatenating multiple strings and/or primitives, and never to reuse the concatenated string instances.
> Murmurhash3 implementation is slow on String keys
> -------------------------------------------------
>
> Key: ISPN-3905
> URL: https://issues.jboss.org/browse/ISPN-3905
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 6.0.0.Final, 6.0.1.Final
> Reporter: Sanne Grinovero
> Assignee: Dan Berindei
> Priority: Minor
> Fix For: 8.1.0.Final
>
>
> String instances are a common choice for being used as key entries, still the getBytes() operation being performed allocates costly buffers, and the computation to get those bytes looks like expensive too.
> I suspect there might be good reasons for not using the String's own hashcode directly as an input to Murmurhash? Still that's what other implementations seem to do.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ISPN-4190) Use Message.Flag.DONT_LOOPBACK instead of RequestOptions.setExclusionList
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4190?page=com.atlassian.jira.plugin.... ]
Dan Berindei resolved ISPN-4190.
--------------------------------
Fix Version/s: 8.0.1.Final
Resolution: Done
Resolved with ISPN-4250
> Use Message.Flag.DONT_LOOPBACK instead of RequestOptions.setExclusionList
> -------------------------------------------------------------------------
>
> Key: ISPN-4190
> URL: https://issues.jboss.org/browse/ISPN-4190
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 7.0.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 8.0.1.Final
>
>
> We are currently using {{RequestOptions.setExclusionList(channel.getAddress())}} in CommandAwareRpcDispatcher, to prevent the sender of an RPC to receive that message. We can't use {{Channel.setDiscardOwnMessages(true)}}, because TO requires messages to be delivered to self.
> JGroups 3.5.0.Beta2 has added a {{DONT_LOOPBACK}} flag, which should be a lot more efficient than using the exclusion list. We should start using it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ISPN-4190) Use Message.Flag.DONT_LOOPBACK instead of RequestOptions.setExclusionList
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4190?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-4190:
-------------------------------
Status: Open (was: Pull Request Sent)
> Use Message.Flag.DONT_LOOPBACK instead of RequestOptions.setExclusionList
> -------------------------------------------------------------------------
>
> Key: ISPN-4190
> URL: https://issues.jboss.org/browse/ISPN-4190
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 7.0.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
>
> We are currently using {{RequestOptions.setExclusionList(channel.getAddress())}} in CommandAwareRpcDispatcher, to prevent the sender of an RPC to receive that message. We can't use {{Channel.setDiscardOwnMessages(true)}}, because TO requires messages to be delivered to self.
> JGroups 3.5.0.Beta2 has added a {{DONT_LOOPBACK}} flag, which should be a lot more efficient than using the exclusion list. We should start using it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ISPN-4190) Use Message.Flag.DONT_LOOPBACK instead of RequestOptions.setExclusionList
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4190?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-4190:
-------------------------------
Status: Pull Request Sent (was: Reopened)
> Use Message.Flag.DONT_LOOPBACK instead of RequestOptions.setExclusionList
> -------------------------------------------------------------------------
>
> Key: ISPN-4190
> URL: https://issues.jboss.org/browse/ISPN-4190
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 7.0.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
>
> We are currently using {{RequestOptions.setExclusionList(channel.getAddress())}} in CommandAwareRpcDispatcher, to prevent the sender of an RPC to receive that message. We can't use {{Channel.setDiscardOwnMessages(true)}}, because TO requires messages to be delivered to self.
> JGroups 3.5.0.Beta2 has added a {{DONT_LOOPBACK}} flag, which should be a lot more efficient than using the exclusion list. We should start using it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ISPN-6003) Reduce number of allocations
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-6003?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-6003:
-----------------------------------------------
Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1272390|https://bugzilla.redhat.com/show_bug.cgi?id=1272390] from ASSIGNED to POST
> Reduce number of allocations
> ----------------------------
>
> Key: ISPN-6003
> URL: https://issues.jboss.org/browse/ISPN-6003
> Project: Infinispan
> Issue Type: Task
> Components: Core, Server
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: performance
> Fix For: 8.1.0.Final
>
>
> Profiling revealed some allocations that are easy to remove:
> * The HotRod operations factory stores a list of flags in a thread-local. The thread-local can be removed, and the flags can be stored in an {{int}}.
> * JGroupsTransport copies the list of members to check if a broadcast should be sent as a unicast, and the copy is then discarded.
> * ExtendedByteBuf could use {{Array.empty}} instead of {{Array[Byte]()}}.
> * DecoratedCache could avoid calling {{Arrays.asList()}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months