[JBoss JIRA] (ISPN-6771) HotRod Client - TcpTransportFactory - update topology issue with multiple caches
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-6771?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec updated ISPN-6771:
--------------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.0.0.Final
Resolution: Done
> HotRod Client - TcpTransportFactory - update topology issue with multiple caches
> --------------------------------------------------------------------------------
>
> Key: ISPN-6771
> URL: https://issues.jboss.org/browse/ISPN-6771
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 9.0.0.Alpha2, 8.2.2.Final
> Environment: Infinispan server 8.2.2.Final
> Hot rod client (Java) : 8.2.2.Final
> Reporter: Jean-Francois LARTAUD
> Assignee: Gustavo Fernandes
> Fix For: 9.0.0.Alpha4, 9.0.0.Final, 8.2.4.Final
>
>
> After debugging :
> In TcpTransportFactory, the topologyInfo is global (whatever the number of caches), the balancing strategies are defined by cache.
> * For the 1st cache, the servers list is updated (org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory#updateServers(java.util.Collection<java.net.SocketAddress>, byte[], boolean), the topologyInfo is updated.
> ** The new servers list is returned only if servers have been added.
> ** As this list is not empty, the balancy strategy for the first cache is updated.
> * For the other caches, the server list is updated by calling the same "updateServers" method, the "updateTopologyInfo" method is called
> ** But as the topologyInfo has been already updated for the 1st cache, it returns "Collections.emptyList();"
> ** The associated balancing strategies are not updated.
> {code}
> public void updateServers(Collection<SocketAddress> newServers, byte[] cacheName, boolean quiet) {
> synchronized (lock) {
> Collection<SocketAddress> servers = updateTopologyInfo(newServers, quiet);
> if (!servers.isEmpty()) {
> FailoverRequestBalancingStrategy balancer = getOrCreateIfAbsentBalancer(cacheName);
> balancer.setServers(servers);
> }
> }
> }
> {code}
--
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 Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-3905?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec updated ISPN-3905:
--------------------------------------
Fix Version/s: 9.0.0.Alpha4
9.0.0.Final
> 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
> Labels: performance
> Fix For: 9.0.0.Alpha4, 9.0.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