From the usage within JBossMessaging, it would be nice if invocations on the reference threw an exception if the server had been stopped but I don't think this is a big deal.
More important I guess is to not have the client pinger and leasing enabled in the invm case (since they are pointless) but this is off topic I guess.
Really just wondering if is ok for local invokers to behave differently from remote invokers? Since may not even know if is local or not within the code, may have unwanted side effects if they do not behave the same (like wanting to know if server shut down regardless of local or remote).
Since you are the only one to respond, you win. ;)
Will have server invoker throw exception if invocation made when stopped/destroyed state. Will disable connection checking if is local.
There are two issues I can think of where you would want
to know the "local invoker" has been shutdown.
1) Firing the JMS ExceptionListener and serverside listener
to say the client<->server is no longer there, even if it was
an in-memory link.
2) It would allow failover. e.g. The client connects to the local node
but if that is removed it can failover to a remote node.
In fact, both could probably be caught at higher levels.
Since the issue is not really about the local invoker but whether
the target service still exists on the other side.
Personally, I would assume consistent behavior and rely on that. The fact that the server and client are colocated is not principally different from the situation when they are running in different address spaces. It seems logical to me that if the server has been shout down, an invocation into it would fail.
So: a local invocation should fail on a stopped server, in my opinion.
Personally, I would assume consistent behavior and rely on that.
Yes, with the exception of pinging. There's no point doing that in the INVM case.
It depends what the ping does. e.g. in JBossMQ it travels through
the interceptor stack and into the server. So it also traps
problems with the server being broken/removed (assuming it isn't
trapped elsewhere). :-)
The same might apply to the remoting stack?
There is no extra logic hops being made within remoting for the connection checking or leasing.