Bug 1050041 - HotRod rolling upgrades -- inter-server communication need to "lock" at HR protocol v 1.2
Summary: HotRod rolling upgrades -- inter-server communication need to "lock" at HR pr...
Keywords:
Status: VERIFIED
Alias: None
Product: JBoss Data Grid 6
Classification: JBoss
Component: Server
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: CR2
: 6.2.0
Assignee: Tristan Tarrant
QA Contact: Martin Gencur
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-08 16:25 UTC by Tomas Sykora
Modified: 2014-01-10 09:02 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker ISPN-3880 0 Major Resolved HotRod Rolling Upgrades -- use HR protocol of version 1.2 for inter-server communication 2018-05-23 16:54:25 UTC

Description Tomas Sykora 2014-01-08 16:25:34 UTC 
During the process of Hot Rod rolling upgrades, old clients are communicating with JDG 6.1 cluster using HR protocol version 1.2. New clients which are connected to the new (6.2) cluster are using protocol version 1.3.

The problem occurs when a data is being stored into new cluster and its "pinging" old remote cache store using protocol 1.3. (specified in JDG server modules/system/layers/base/org/infinispan/client/hotrod/main).

As a consequence, versions are mixed and following error is thrown:

Caused by: org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[2] returned server error (status=0x85): scala.MatchError: 13 (of class java.lang.Byte)
	at org.infinispan.client.hotrod.impl.protocol.Codec10.checkForErrorsInResponseStatus(Codec10.java:143)
	at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:99)
	at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56)
	at org.infinispan.client.hotrod.impl.operations.PingOperation.execute(PingOperation.java:44)
	at org.infinispan.client.hotrod.impl.operations.FaultTolerantPingOperation.executeOperation(FaultTolerantPingOperation.java:30)	at org.infinispan.client.hotrod.impl.operations.FaultTolerantPingOperation.executeOperation(FaultTolerantPingOperation.java:16)	at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:46)
	at org.infinispan.client.hotrod.impl.RemoteCacheImpl.ping(RemoteCacheImpl.java:433)
	at org.infinispan.client.hotrod.RemoteCacheManager.ping(RemoteCacheManager.java:632)
	at org.infinispan.client.hotrod.RemoteCacheManager.createRemoteCache(RemoteCacheManager.java:613)
	at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:524)
	at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:520)
	at org.infinispan.persistence.remote.RemoteStore.start(RemoteStore.java:89)
	at org.infinispan.persistence.manager.PersistenceManagerImpl.start(PersistenceManagerImpl.java:122)
	... 23 more


We suggest to "lock" inter-server communication and using HR protocol version 1.2.
Comment 2 Tomas Sykora 2014-01-10 09:02:01 UTC 
We are OK here, thanks!
Comment 3 Tomas Sykora 2014-01-10 09:02:53 UTC 
And we added "Important INFO" box into doc, that for communicating with old cluster is used protocol v 1.2 and 1.3 for the new cluster.
Note You need to log in before you can comment on or make changes to this bug.