[ https://issues.jboss.org/browse/WFLY-11489?page=com.atlassian.jira.plugin... ] Richard Achmatowicz edited comment on WFLY-11489 at 1/11/19 1:39 PM: --------------------------------------------------------------------- I've now had a look in detail at the affinity processing here and have an idea for a fix. There are three problems to overcome. The first is to correct the assignment of strong and weak affinity for the SFSB with passivationEnabled == false. If the initial affinity of the proxy before session creation is (strong affinity, weak affinity) = (NONE, NONE), which is the default, then the affinity assignment we expect is either (NODE, NONE) or (NONE, NODE) which are equivalent. In other words, invocations should be tied to the node that the session is created on. This will require simple changes to the way the affinity is calculated - namely using the session cache do to the calculations. The second problem is that the v3 protocol will not allow sending arbitrary affinity values back to the client: it is assumed that: * updates to strong affinity are always of type ClusterAffinity * updates to weak affinity are always of type NodeAffinity For the code, see for example https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org... This means that we can't assign (NODE, NONE) to the SFSB with passivationEnabled=false, but we can assign (NONE, NODE) which is equivalent. This seems to be the only way around this particular issue. The third problem is that, on the client side, when the reply from the server is unpacked, there are some adjustments made to the affinity values before the invocation completes. These adjustments seem to interpret Affinity.NONE as "the affinity is not set", and try to replace Affinity.NONE with the targetAffinity which was determined when doing discovery. For example: https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org.... In fact, Affinity.NONE means "I don't care which node you send me to" and does not mean "the affinity is not set". So, for example, the affinity adjustment made in the DiscoveryEJBClientInterceptor above will transform (NONE, NODE) into (NODE, NODE) or possibly (URI, NODE) where URI is a URIAffinity assigment for the locator pointing to the server used to create the session. In this case, such a manipulation may not hurt, but it seems to be unnecessary. So, i'll be putting together a fix which incorporates these three changes. It would have been much easier and cleaner to be able to assign to the strong or weak affinity any affinity type, but with the v3 protocol, that is currently not possible. PS For those interested, targetAffinity is assigned as a side effect when we choose a target for the invocation. Doing discovery results in choosing a serviceURL to send the invocation to which satisfies the strong/weak affinity constraints. That serviceURL contains a location together with optional node, module and cluster attributes. The location tells us how to connect to the node, the attributes tell us what the node name is, which modules are deployed there and which clusters it belongs to. targetAffinity is NodeAffinity(<node name>) if the serviceURL does have a node attribute, and URIAffinity(<location>) if there is no node attribute. It seems to be used to make adjustments to affinity on the client based on where the last invocation attempt went. I'm really not seeing why this is needed. was (Author: rachmato): I've now had a look in detail at the affinity processing here and have an idea for a fix. There are three problems to overcome. The first is to correct the assignment of strong and weak affinity for the SFSB with passivationEnabled == false. If the initial affinity of the proxy before session creation is (strong affinity, weak affinity) = (NONE, NONE), which is the default, then the affinity assignment we expect is either (NODE, NONE) or (NONE, NODE) which are equivalent. In other words, invocations should be tied to the node that the session is created on. This will require simple changes to the way the affinity is calculated - namely using the session cache do to the calculations. The second problem is that the v3 protocol will not allow sending arbitrary values affinity back to the client: it is assumed that: * updates to strong affinity are always of type ClusterAffinity * updates to weak affinity are always of type NodeAffinity For the code, see for example https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org... This means that we can't assign (NODE, NONE) to the SFSB with passivationEnabled=false, but we can assign (NONE, NODE) which is equivalent. This seems to be the only way around this particular issue. The third problem is that, on the client side, when the reply from the server is unpacked, there are some adjustments made to the affinity values before the invocation completes. These adjustments seem to interpret Affinity.NONE as "the affinity is not set", and try to replace Affinity.NONE with the targetAffinity which was determined when doing discovery. For example: https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org.... In fact, Affinity.NONE means "I don't care which node you send me to" and does not mean "the affinity is not set". So, for example, the affinity adjustment made in the DiscoveryEJBClientInterceptor above will transform (NONE, NODE) into (NODE, NODE) or possibly (URI, NODE) where URI is a URIAffinity assigment for the locator pointing to the server used to create the session. In this case, such a manipulation may not hurt, but it seems to be unnecessary. So, i'll be putting together a fix which incorporates these three changes. It would have been much easier and cleaner to be able to assign to the strong or weak affinity any affinity type, but with the v3 protocol, that is currently not possible. PS For those interested, targetAffinity is assigned as a side effect when we choose a target for the invocation. Doing discovery results in choosing a serviceURL to send the invocation to which satisfies the strong/weak affinity constraints. That serviceURL contains a location together with optional node, module and cluster attributes. The location tells us how to connect to the node, the attributes tell us what the node name is, which modules are deployed there and which clusters it belongs to. targetAffinity is NodeAffinity(<node name>) if the serviceURL does have a node attribute, and URIAffinity(<location>) if there is no node attribute. It seems to be used to make adjustments to affinity on the client based on where the last invocation attempt went. I'm really not seeing why this is needed. -- This message was sent by Atlassian Jira (v7.12.1#712002)