[jboss-jira] [JBoss JIRA] (WFLY-11833) Stateful Session Bean affinity URI instead of cluster

[Richard Achmatowicz (Jira)]

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

Richard Achmatowicz edited comment on WFLY-11833 at 7/19/19 6:43 AM:
---------------------------------------------------------------------

I'm attaching a detailed log of test execution with just about everything written out: test-debug-log.txt

One thing I discovered was that affinities are being processed even in the marshaling code (see ProtocolV3ObjectResolver). When a proxy is marshaled, certain affinities are substituted with other affinities using the class ProtocolV3ObjectResolver, depending on the endpoints of the connection handing the invocation. This is where the unexpected URI affinities are coming from in this example. The ObjectResolver keeps track, for the current connection, of the sender's NodeAffinity and URIAffinity, as well as the receiver's NodeAffinity and URIAffinity and uses these values in substitution of what goes into the stream and what comes out of the stream.

At present, the code in ProtocolV3ObjectResolver works like this:
* when writing ("replacing") an Affinity object into the stream:
** if the object corresponds to Affinity.LOCAL (and the sender's NodeAffinity exists) , replace Affinity.LOCAL with the sender's NodeAffinity
** if the object corresponds to the receiver's URIAffinity, replace the receiver's URIAffinity with the receiver's NodeAffinity
* when reading ("resolving") an affinity object from the stream: 
** if the object corresponds to Affinity.LOCAL, resolve this to the sender's URIAffinity (if we prefer URIs), or the sender's NodeAffinity (if it exists) or NONE
** if the object corresponds to the receiver's NodeAffinity, resolve this to Affinity.LOCAL, else if the object corresponds to the sender's NodeAffinity, resolve to the sender's URIAffinity   

What we are seeing in this issue is the case where:
* when writing, Affinity.LOCAL is being replaced by the sender's NodeAffinity
* when reading, the sender's NodeAffinity is replaced by the sender's URIAffinity

Re-iterating the original problems in this issue, a proxy for a remote view of a bean is created on a server (which is also a member of a cluster) and is shipped across the network (maybe via multiple servers) back to a client. The proxy is created with Affinity.LOCAL and is getting translated into other values when shipped across the network, based on connection endpoints. If this is the way the scheme was intended to function, i'm not sure it is a workable solution.


was (Author: rachmato):
I'm attaching a detailed log of test execution with just about everything written out: test-debug-log.txt

One thing I discovered was that affinities are being processed even in the marshaling code (see ProtocolV3ObjectResolver). When a proxy is marshaled, certain affinities are substituted with other affinities using the class ProtocolV3ObjectResolver, depending on the endpoints of the connection handing the invocation. This is where the unexpected URI affinities are coming from in this example. The ObjectResolver keeps track, for the current connection, of the sender's NodeAffinity and URIAffinity, as well as the receiver's NodeAffinity and URIAffinity and uses these values in substitution of what goes into the stream and what comes out of the stream.

At present, the code in ProtocolV3ObjectResolver works like this:
* when writing ("replacing") an Affinity object into the stream:
** if the object corresponds to Affinity.LOCAL (and the sender's NodeAffinity exists) , replace Affinity.LOCAL with the sender's NodeAffinity
** if the object corresponds to the receiver's URIAffinity, replace the receiver's URIAffinity with the receiver's NodeAffinity
* when reading ("resolving") an affinity object from the stream: 
** if the object corresponds to Affinity.LOCAL, resolve this to the sender's URIAffinity (if we prefer URIs), or the sender's NodeAffinity (if it exists) or NONE
** if the object corresponds to the receiver's NodeAffinity, resolve this to Affinity.LOCAL, else if the object corresponds to the sender's NodeAffinity, resolve to the sender's URIAffinity   

What we are seeing in this issue is the case where:
* when writing, Affinity.LOCAL is being replaced by the sender's NodeAffinity
* when reading, the sender's NodeAffinity is replaced by the sender's URIAffinity



> Stateful Session Bean affinity URI instead of cluster
> -----------------------------------------------------
>
>                 Key: WFLY-11833
>                 URL: https://issues.jboss.org/browse/WFLY-11833
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, EJB
>    Affects Versions: 16.0.0.Final
>         Environment: WildFly cluster having SFSB deployed.
>            Reporter: Joerg Baesner
>            Assignee: Richard Achmatowicz
>            Priority: Major
>              Labels: downstream_dependency
>         Attachments: stateful-timeout.zip, test-debug-log.txt
>
>
> Deployed is an application with the following setup:
> * Containing a SFSB (_with passivationCapable="true"_)
> * A SLSB exposing a _remote_ method to a standalone client returning an instance of the SFSB
> Scenario:
> A standalone client is invoking the _remote_ method on the Stateless Session Bean and a new instance of the Stateful Session Bean is returned.
> The issue is that the affinity of the returned Stateful Session Bean is URI instead of Cluster.
> See the attached Gradle reproducer application



--
This message was sent by Atlassian Jira
(v7.12.1#712002)