8 Replies Latest reply on May 18, 2006 11:44 AM by Tom Elrod

    local invoker behavior

    Tom Elrod Master

      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 ;)

        • 1. Re: local invoker behavior
          Tim Fox Master

          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.

          • 2. Re: local invoker behavior
            Tom Elrod Master

            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.

            • 3. Re: local invoker behavior
              Adrian Brock Master

              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.

              • 4. Re: local invoker behavior
                Ovidiu Feodorov Master


                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.

                • 5. Re: local invoker behavior
                  Tim Fox Master

                   

                  "ovidiu.feodorov@jboss.com" 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.

                  • 6. Re: local invoker behavior
                    Adrian Brock Master

                     

                    "timfox" wrote:
                    "ovidiu.feodorov@jboss.com" 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?

                    • 7. Re: local invoker behavior
                      Tom Elrod Master

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