From a mail discussion:
> On 2/11/12 8:55 AM, Jaikiran Pai wrote:
>> Reviving this old discussion again, now in the context of
>> https://issues.jboss.org/browse/AS7-3716. The issue there is still under
>> investigation so I'm not 100% sure about the problem, but I do have a
>> theory that it might very well be related to our affinity logic.
>> So like we discussed earlier in this mail and like David explained, the
>> weak affinity (along with the hard affinity) is there to make sure that
>> we always (whenever possible) direct the client invocations to the node
>> which owns the session. Our current implementation I believe is missing
>> a piece which is not letting this happen. To recap, how we deal with
>> affinities, consider a server on which we have a SFSB deployed which
>> belongs to cluster "foo" consisting node A and B:
>> 1) Client looks up SFSB which triggers a session creation on node A. The
>> server (node A) responds back with a session id and also sends along a
>> "hard affinity" == "foo cluster".
>> 2) Client invokes on the proxy which then trigger the receiver selection
>> logic where we find that the locator is associated with a hard affinity
>> == foo cluster.
>> 3) We then look for a receiver which belongs to "foo cluster" within the
>> current EJB client context. Now at this step, there's no guarantee that
>> the client context will return node A receiver. It might very well
>> return node B receiver too. Ideally we do want node A receiver, since
>> that's what owns the session.
>> Our initial idea while implementing the EJB protocol was to pass back
>> the weak affinity only during method invocations. i.e. whenever the
>> client invokes on the proxy, along with the method invocation result we
>> would also get a weak affinity (which points to the node which owns the
>> session). So subsequent requests (starting the second one) on the
>> proxy would result in the invocation being directed correctly to node A.
>> I believe we should also send back a weak affinity (along with the
>> current hard affinity) on the session creation response too. That'll
>> make sure that even the first invocation on the SFSB proxy will take
>> into account the node which owns the session. I'll be implementing this
>> now and running some tests. Just wanted to give you guys a heads up and
>> make sure I we agree on this change.