="galder.zamarreno(a)jboss.com" wrote : In the case of clustered invokers, I think
disconnecting the current client before creating/connecting a new one would make sense as
otherwise you're leaking clients (this probably needs a jira, FAO Brian thoughts?)
There are really 2 cases here:
a) switching to a new Client due to failover. In that case the InvokerLocator is removed
from the set of targets and disconnecting seems like an obvious right thing to do.
b) switching to a new Client due to normal load balancing (e.g. RoundRobin) with an
expectation that we may end up creating another Client later for the same InvokerLocator.
That, if I understand the code correctly, will end up using the already-existing
The b) case is more tricky. If in the non-clustered case we end up deciding to call
disconnect after every invocation, then the clustered case should as well. If
non-clustered doesn't disconnect on every invocation, we can revisit. Sounds like
disconnecting is necessary though, with the "invokerDestructionDelay" as the
workaround to cut down on the waste associated with that.
View the original post :
Reply to the post :