local invoker behavior

[tom.elrod]

While working on JBREM-382, I realized might be good to get feedback on the behavior of the local invokers in general. To start, if a client and server are running within the same VM, the client will use a local invoker instance to make calls on the server (by reference). When this is done, even if the server's stop() and destroy() method is called, the client still maintains a valid reference to the server.

The current behavior is that the client can *always* make calls on a server it has a direct reference to. This is done via calling the ServerInvoker.invoke(InvocationRequest invocation) method. This invoke() method does not do any checking of the server's state (if it has been stopped/destroyed). This being the case, there is no point in having a connection validator hooked up from the client side, since will always have a server once connected.

The question is the correct behavior? If is not a local connection, calling stop()/destroy() on the server would cause the connection to be terminated. Should local connections behave the same way? If so, no way to invalidate the client's reference to the server, but could add state checking within the server's invoke() method to throw an exception if has been stopped/destroyed so that will mimic same behavior to the client as if was remote. If this is done, then would make sense to have connection validation on the client.

All feedback welcome. I am leaning to leaving the way it is ;)

[timfox]

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.

[tom.elrod]

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.

[adrian.brock]

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.

[ovidiu.feodorov]

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.

[timfox]

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.

[adrian.brock]

"timfox" wrote:

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?

[tom.elrod]

There is no extra logic hops being made within remoting for the connection checking or leasing.

[tom.elrod]

http://jira.jboss.com/jira/browse/JBREM-382