[infinispan-issues] [JBoss JIRA] Updated: (ISPN-963) UnsupportedOperationException when sending new topology header from Hot Rod server

[Galder Zamarreño (JIRA)]

     [ https://issues.jboss.org/browse/ISPN-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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-size6-hotrod/1/console-perf01/consoleText

  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}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-size6-hotrod/1/console-perf01/consoleText



> UnsupportedOperationException when sending new topology header from Hot Rod server
> ----------------------------------------------------------------------------------
>
>                 Key: ISPN-963
>                 URL: https://issues.jboss.org/browse/ISPN-963
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Cache Server, Distributed Cache
>    Affects Versions: 4.2.0.Final, 4.2.1.CR3
>            Reporter: Galder Zamarreño
>            Assignee: Galder Zamarreño
>              Labels: hotrod, rehashing
>             Fix For: 4.2.1.FINAL
>
>
> 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-size6-hotrod/1/console-perf01/consoleText

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira