[
https://issues.jboss.org/browse/ISPN-2632?page=com.atlassian.jira.plugin....
]
Galder Zamarreño commented on ISPN-2632:
----------------------------------------
Michal, thx for attaching the logs. It only contains TRACE on client but it's Ok.
Taking one client as example (
https://gist.github.com/4511311), the number of servers sent
back looks right (missing 192.168.87.122), so it doesn't appear to be an issue with
the way view is managed. IMO, it seems to be more of an issue with hashing itself.
Looking at the cached positions on the client, I don't see anything wrong at 1st
glance:
https://gist.github.com/4511569. The positions taken by .122 appear to have gone.
Doesn't seem to be a problem with node4 taking more positions on the hash map.
I wonder if this issue has to do with ISPN-2670? I see
org.infinispan.client.hotrod.impl.protocol.Codec12 in the logs, but ISPN-2670 seems to
imply that Hot Rod client does not work with version 1.2 of the protocol.
I'm gonna tackle ISPN-2670 first and then we can see if the issue is still there.
Uneven request balancing after node crash
-----------------------------------------
Key: ISPN-2632
URL:
https://issues.jboss.org/browse/ISPN-2632
Project: Infinispan
Issue Type: Bug
Components: Remote protocols
Affects Versions: 5.2.0.CR1
Reporter: Michal Linhard
Assignee: Galder Zamarreño
Priority: Critical
Fix For: 5.2.0.CR2, 5.2.0.Final
This is a new manifestation of ISPN-1995, but in this case this happens after killing
only one node: the hot rod requests aren't very well balanced.
these runs still manifest also ISPN-2550 and it may be cause of this bug.
The uneven balancing of requests can be seen here:
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EDG6/view/EDG-REPOR...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira