[ https://issues.jboss.org/browse/ISPN-1217?page=com.atlassian.jira.plugin.... ] Manik Surtani updated ISPN-1217: -------------------------------- Issue Type: Bug (was: Feature Request) Assignee: Galder Zamarreño (was: Manik Surtani) Fix Version/s: 5.0.0.FINAL Forum Reference: http://community.jboss.org/thread/168926 (was: http://community.jboss.org/thread/168926) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1217?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-1217: ---------------------------------------- Indeed, the current HotRod server set up is that a HotRod topology address has a map of cache->hashId where it assumes that there's a single hashId per cache. Virtual nodes breaks this assumption which means that for a topology address, a given cache has multiple hashIds. Luckily, this should not require a change in the protocol (http://community.jboss.org/docs/DOC-14421) because nothing stops the server sending several hash id entries for a single host:port, i.e. localhost:1234,hashId=75848, localhost:1234,hashId=78304...etc. Internally, the server will have to do some adjustments including using a different method instead of ConsistentHash.getHashId(). For future reference, here's the stacktrace: {code}java.lang.IllegalStateException: With virtual nodes enabled each address has more than one hash id at org.infinispan.distribution.ch.AbstractWheelConsistentHash.getHashId(AbstractWheelConsistentHash.java:205) at org.infinispan.server.hotrod.HotRodServer.org$infinispan$server$hotrod$HotRodServer$$updateHashIds(HotRodServer.scala:176) at org.infinispan.server.hotrod.HotRodServer$$anonfun$createTopologyAddress$1.apply(HotRodServer.scala:156) at org.infinispan.server.hotrod.HotRodServer$$anonfun$createTopologyAddress$1.apply(HotRodServer.scala:155) at scala.collection.Iterator$class.foreach(Iterator.scala:631) at scala.collection.JavaConversions$JIteratorWrapper.foreach(JavaConversions.scala:549) at org.infinispan.server.hotrod.HotRodServer.createTopologyAddress(HotRodServer.scala:155) at org.infinispan.server.hotrod.HotRodServer.addSelfToTopologyView(HotRodServer.scala:106) at org.infinispan.server.hotrod.HotRodServer.startTransport(HotRodServer.scala:98) at org.infinispan.server.core.AbstractProtocolServer.start(AbstractProtocolServer.scala:99) at org.infinispan.server.hotrod.HotRodServer.start(HotRodServer.scala:79) ... {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1217?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-1217: ---------------------------------------- Also, it's clear that if for example you have 10 virtual nodes, having to send the host:port with each of the hash ids is not very efficient, but at least it does not force us to change the protocol right. However, I'll make sure this gets added to the v2 improvements so that it can be considered when we design v2. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1217?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-1217: ---------------------------------------- I've added http://community.jboss.org/wiki/HotRodProtocol#Num_servers_in_topology_vi... that documents the expectations with regards to the number of topology addresses returned in the topology change header with distributed caches. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira