[infinispan-issues] [JBoss JIRA] (ISPN-7358) Hot Rod server not dealing with pipe requests properly

[Karl von Randow (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-7358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13454992#comment-13454992 ] 

Karl von Randow commented on ISPN-7358:
---------------------------------------

We are seeing something that might be related to this using Infinispan 8.2.6 as a remote cache. We're unable to upgrade to Infinispan 9.1 as we also use Infinispan as Hibernate 2LC, and it appears that the hotrod connector cannot be upgraded independently (class conflicts at runtime).

We are receiving exceptions like:

{code}
org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for messageId=457992 returned server error (status=0x81): org.infinispan.server.hotrod.InvalidMagicIdException: Error reading magic byte or message id: 3

org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for messageId=3858 returned server error (status=0x81): org.infinispan.server.hotrod.InvalidMagicIdException: Error reading magic byte or message id: 180
{code}

We're receiving this _really frequently_ when we are using the `replace` method. Here is a representative stack trace:

{code}
org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for messageId=110117 returned server error (status=0x81): org.infinispan.server.hotrod.InvalidMagicIdException: Error reading magic byte or message id: 1
42
        at org.infinispan.client.hotrod.impl.protocol.Codec20.checkForErrorsInResponseStatus(Codec20.java:350)
        at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:139)
        at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:125)
        at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56)
        at org.infinispan.client.hotrod.impl.operations.AbstractKeyOperation.returnVersionedOperationResponse(AbstractKeyOperation.java:63)
        at org.infinispan.client.hotrod.impl.operations.ReplaceIfUnmodifiedOperation.executeOperation(ReplaceIfUnmodifiedOperation.java:41)
        at org.infinispan.client.hotrod.impl.operations.ReplaceIfUnmodifiedOperation.executeOperation(ReplaceIfUnmodifiedOperation.java:19)
        at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:54)
        at org.infinispan.client.hotrod.impl.RemoteCacheImpl.replaceWithVersion(RemoteCacheImpl.java:153)
        at org.infinispan.client.hotrod.impl.RemoteCacheImpl.replaceWithVersion(RemoteCacheImpl.java:145)
{code}

Should we attempt to backport these fixes to 8.2.6 or does this appear to be a separate issue that we should raise?

> Hot Rod server not dealing with pipe requests properly
> ------------------------------------------------------
>
>                 Key: ISPN-7358
>                 URL: https://issues.jboss.org/browse/ISPN-7358
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Remote Protocols
>    Affects Versions: 8.2.5.Final, 9.0.0.Beta1
>            Reporter: Galder Zamarreño
>            Assignee: Galder Zamarreño
>            Priority: Blocker
>             Fix For: 9.0.0.Beta2, 9.0.0.Final
>
>
> This might not become so apparent with the current synchronous Java client, but with fully asynchronous clients such as the Javascript one, multiple requests can be piped one after the other.
> Hot Rod server does not often deal with those well, showing exceptions such as:
> {code}
> org.infinispan.server.hotrod.InvalidMagicIdException: 
> Error reading magic byte or message id: 119
> {code}
> {code}
> org.infinispan.server.hotrod.UnknownVersionException: 
> Unknown version:-96
> {code}
> This exceptions appear when applying considerable load with the Javascript client (see HRJS-24), but the same effect can be replicated with a Netty based, fully asynchronous client, such as the simplified version used [here|https://gist.github.com/galderz/94705dd73d5339b1ab5aa0a5157a9803].



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)