[ https://issues.jboss.org/browse/ISPN-963?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño updated ISPN-963: ---------------------------------- Description: If a Hot Rod server attempts to send a new hash topology header back to client while rehashing is going on due to a view change, it will fail like this: {code}java.lang.UnsupportedOperationException: Unsupported! at org.infinispan.distribution.ch.UnionConsistentHash.getHashId(UnionConsistentHash.java:53) at org.infinispan.server.hotrod.HotRodEncoder$$anonfun$writeHashTopologyHeader$4.apply(HotRodEncoder.scala:164) at org.infinispan.server.hotrod.HotRodEncoder$$anonfun$writeHashTopologyHeader$4.apply(HotRodEncoder.scala:160) at scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.scala:61) at scala.collection.immutable.List.foreach(List.scala:45) at org.infinispan.server.hotrod.HotRodEncoder.writeHashTopologyHeader(HotRodEncoder.scala:160) at org.infinispan.server.hotrod.HotRodEncoder.writeHeader(HotRodEncoder.scala:117) at org.infinispan.server.hotrod.HotRodEncoder.encode(HotRodEncoder.scala:32){code} A solution here might be to compute all hash ids before deciding whether to send a new topology back to the client. If any of the computations is missed, the encoder could maybe keep track of it and try again when sending response to next command. A full console log can be found in: http://hudson.qa.jboss.com/hudson/view/EDG/job/edg-51x-stress-client-size... was: If a Hot Rod server attempts to send a new hash topology header back to client while rehashing is going on due to a view change, it will fail like this: {code}[JBoss] java.lang.UnsupportedOperationException: Unsupported! [JBoss] at org.infinispan.distribution.ch.UnionConsistentHash.getHashId(UnionConsistentHash.java:53) [JBoss] at org.infinispan.server.hotrod.HotRodEncoder$$anonfun$writeHashTopologyHeader$4.apply(HotRodEncoder.scala:164) [JBoss] at org.infinispan.server.hotrod.HotRodEncoder$$anonfun$writeHashTopologyHeader$4.apply(HotRodEncoder.scala:160) [JBoss] at scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.scala:61) [JBoss] at scala.collection.immutable.List.foreach(List.scala:45) [JBoss] at org.infinispan.server.hotrod.HotRodEncoder.writeHashTopologyHeader(HotRodEncoder.scala:160) [JBoss] at org.infinispan.server.hotrod.HotRodEncoder.writeHeader(HotRodEncoder.scala:117) [JBoss] at org.infinispan.server.hotrod.HotRodEncoder.encode(HotRodEncoder.scala:32){code} A solution here might be to compute all hash ids before deciding whether to send a new topology back to the client. If any of the computations is missed, the encoder could maybe keep track of it and try again when sending response to next command. A full console log can be found in: http://hudson.qa.jboss.com/hudson/view/EDG/job/edg-51x-stress-client-size... -- 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-963?page=com.atlassian.jira.plugin.s... ] Manik Surtani commented on ISPN-963: ------------------------------------ Hmm, maybe don't provide updated headers when a rehash is still in progress? (You only have a UnionConsistentHash when a rehash is going on). You could make a note of the fact that there was a topology change but only send the topology header after any rehashing is complete... -- 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-963?page=com.atlassian.jira.plugin.s... ] Work on ISPN-963 started by Galder Zamarreño. -- 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-963?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño resolved ISPN-963. ----------------------------------- Resolution: Done -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira