[infinispan-issues] [JBoss JIRA] (ISPN-10818) Remote-query 9.4.x backwards compatibility
Ryan Emerson (Jira)
issues at jboss.org
Thu Oct 24 17:00:00 EDT 2019
[ https://issues.jboss.org/browse/ISPN-10818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13804251#comment-13804251 ]
Ryan Emerson commented on ISPN-10818:
-------------------------------------
A potential solution is to leverage the HotRod protocol version that is sent with every client request, to determine whether it's necessary for the legacy Ids to be mapped when processing the request and sending a response. If legacy TypeId mapping is required, we can add parameters to the MediaTypes associated with a request which can then be utilised by Transcoders etc that need to unmarshall/marshall request/response bytes.
Lots of discussions about this topic on the original PR https://github.com/infinispan/infinispan/pull/7357.
> Remote-query 9.4.x backwards compatibility
> ------------------------------------------
>
> Key: ISPN-10818
> URL: https://issues.jboss.org/browse/ISPN-10818
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Querying
> Affects Versions: 10.0.0.CR3
> Reporter: Ryan Emerson
> Priority: Major
>
> For performance reasons, ProtoStream changed the TypeId of WrappedMessage to 0, which means that pre 10.x clients using RemoteQuery are no longer compatible. Furthermore, ISPN-10663 updated the TypeId of the remote query messages to conform to the Infinispan TypeId ranges defined in ProtoStreamTypeIds.
> Therefore, for pre 10.x clients, it is neccessary for all remote query requests to have the legacy TypeId mapped to the new TypeId values. https://issues.jboss.org/browse/IPROTO-119 introduced a mechanism for this mapping, however more work is required, as the mapping must occur on a per request/response basis (only if communication is with a legacy client).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
More information about the infinispan-issues
mailing list