[ https://issues.jboss.org/browse/WFLY-11833?page=com.atlassian.jira.plugin... ] 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 -- This message was sent by Atlassian Jira (v7.12.1#712002)