12 Replies Latest reply on Jul 7, 2007 3:48 AM by ron_sigal

    Exceptions in calls and callbacks

    login4jbr

      Hello, I'm a begginer with JBoss remoting and any help will be great.

      What happens if something bad happens during a remote call or callback?

      The remote call throws some special exception like the RemoteException in RMI?

      How can I know that something bad happened?
      How can I know exactly what happened?

      For a remote call you use the invoke() and invokeOneWay() methods in the Client class. These method declare that throws a Throwable, but what does it mean?
      I've looked at the javadoc, but there are no explanations.
      I've looked at the JBoss remoting guide but found nothing.
      Where can find information about this?

      I wish to determinate if the problem ocurred:
      when the call was going to the server.
      when the request was being processed in the server.
      when the call was returning to the client.


      Analogously:

      For a remote callback you use the handleCallback() method in the InvokerCallbackHandler implementation. This method throws a CallbackHandleException.

      I need to know the meaning of that exception and the exact situation.

      Thanx

        • 1. Re: Exceptions in calls and callbacks
          ron_sigal

          Welcome to Remoting.


          I wish to determinate if the problem ocurred:
          when the call was going to the server.
          when the request was being processed in the server.
          when the call was returning to the client.


          You want to look at the particular Throwable that comes back, its type and its description. If a problem occurs in transit, you might get an IOException. If the server side handler throws an exception, that exception will be transported across the network and re-thrown by Remoting on the server side.

          For a remote callback you use the handleCallback() method in the InvokerCallbackHandler implementation. This method throws a CallbackHandleException.


          Throwables generated during callback handling are wrapped in a CallbackHandleException. You want to extract the Throwable embedded in the CallbackHandleException and apply my previous remarks.

          By the way, when I get an exception I don't recognize I often just google it and get lots of useful information.

          • 2. Re: Exceptions in calls and callbacks
            login4jbr

            Thank you very much for the reply, I really appreciate the help.

            I think my original post wasn't clear (sorry about my poor english), I'll try to put this as correctly as possible.

            When you do a remote call or callback, a number of problems may happen.

            The invoke() and invokeOneWay() methods declare that throw a Throwable, but Throwable is a very general interface (I'm confused because I have readed somewhere that throwing or catching a Throwable is a bad practice, anyway let's continue with the main point).

            The programmer that uses these methods needs to know what kind of things may be thrown and the originating reasons.

            I know that you can search in google for a certain type of exception to learn about its meaning, but that's not the problem here. The problem is that there is no documentation (at least I don't have found it) about the things that can be thrown by the remote invocations.

            The same applies for the callbacks:When you do a callback, a CallbackHandleException can arise, which wraps the real Throwable, but I don't know what kind of things may come in there.

            Is important to know what will be thrown in the following situations:

            - When the call were going from the emisor to the receptor.
            - When the call made it to the receptor but some problem occurred during processing.
            - When the call were returning from the receptor to the emisor.

            Think in the following scenario:

            1. You have a client-server application.
            2. The server have a variable X with value 5.
            3. The client does a remote call to the server and tells him "please increment X by one"
            4. The server increase the value and now X == 6
            5. The remote call returns
            6. The client tells the user: "dear user, now the value of X is 6"

            Now imagine that the remote call throws a Throwable...
            How can you determinate what happened?
            Did the request get to the server?
            Was the value of X increased?
            The problem occurred during the call return?

            Well, I hope my explanation was correct and clear.

            Big thanks to all people.

            • 3. Re: Exceptions in calls and callbacks

              Maybe I can clarify a bit. The reason the remoting client declares that it throws Throwable is that remoting will pass along the Throwable object thrown from the server side hanlder. Since we don't know what type of exceptions the server side handler might throw, we have to declare the most generic base class there is, which is Throwable.

              So for example, suppose the user has an implementation of ServerInvocationHandler that looks like:

               public class MyInvocationHandler implements ServerInvocationHandler
               {
               ...
              
               public Object invoke(InvocationRequest invocation) throws Throwable
               {
               Object param = invocation.getParameter();
               if("foo".equals(param)
               {
               throw new AssertionError();
               }
               else if("bar".equals(param)
               {
               throw new IllegalArgumentException();
               }
               else
               {
               return "Thank you";
               }
               }
              
               ...
               }
              
              


              So if the remoting client passes the String "foo" to the invoke() method, an AssertionError will be thrown from the invoke() method call. If the remoting client passes the String "bar" to the invoke() method, an IllegalArgumentException will be thrown from the invoke() method call. Both will appear just as it was thrown from the handler on the server side to the client. Since there is no way for remoting to know what might possibly thrown by the server handler, we have to just declare we throw Throwable.

              Now it is possible that an exception may occur that has nothing to do with the server handler (i.e. a network error). So if the remoting client can not connect to the server for some reason, remoting will throw a org.jboss.remoting.CannotConnectException. If there was some other network exception such as a socket timeout, would get that exception thrown as well (i.e. java.net.SocketException).

              Hope that helps.


              • 4. Re: Exceptions in calls and callbacks
                login4jbr

                That helps indeed :)

                Thank you for the explanation.

                I understand now.

                Is there some way to determinate if the problem was before, during or after the call was handled in the server?

                • 5. Re: Exceptions in calls and callbacks

                  About the only thing can know for sure is if get a CnnotConnectException, the call never reached the server. Anything else would be difficult to know for sure (i.e. if get SocketException, can't be certain that call didn't make it to server).

                  • 6. Re: Exceptions in calls and callbacks
                    login4jbr

                    Ok, that's all for my questions.

                    Thanks for the replies.

                    I wish this post help others as much as it helped me.

                    See ya.

                    • 7. Re: Exceptions in calls and callbacks
                      shdv

                       

                      "tom.elrod@jboss.com" wrote:
                      About the only thing can know for sure is if get a CannotConnectException, the call never reached the server. Anything else would be difficult to know for sure (i.e. if get SocketException, can't be certain that call didn't make it to server).


                      Why does org.jboss.remoting.Client.invoke() throw Exception when client is not connected? According to the above description it should be CannotConnectExcetption.

                      I was really disappointed when I got it. My code catches CannotConnectException to handle connection issues.

                      Since Client is usually wrapped in a proxy, under some circumstances proxy class can wrap it into UndeclaredThrowableException making things even worse.

                      • 8. Re: Exceptions in calls and callbacks
                        ron_sigal

                         

                        "shdv" wrote:
                        "tom.elrod@jboss.com" wrote:
                        About the only thing can know for sure is if get a CannotConnectException, the call never reached the server. Anything else would be difficult to know for sure (i.e. if get SocketException, can't be certain that call didn't make it to server).


                        Why does org.jboss.remoting.Client.invoke() throw Exception when client is not connected? According to the above description it should be CannotConnectExcetption.

                        I was really disappointed when I got it. My code catches CannotConnectException to handle connection issues.

                        Since Client is usually wrapped in a proxy, under some circumstances proxy class can wrap it into UndeclaredThrowableException making things even worse.


                        Well, when Client.invoke() throws Exception, it's not a *cannot* connect problem, it's a *did not* connect problem.

                        • 9. Re: Exceptions in calls and callbacks
                          shdv

                          In my case connection was established and several calls got through.
                          The scenario is:
                          1. Connect to server
                          2. DoSomething1
                          3. DoSomething2 and disconnect in the same moment due to networking issue

                          DoSomething2 fails with Exception being thrown.
                          I export POJO with RMI transport and see the following stack.

                          java.lang.reflect.UndeclaredThrowableException
                           at $Proxy244.stop(Unknown Source)
                           at ...
                          Caused by: java.lang.Exception: Can not make remoting client invocation due to not being connected to server.
                           at org.jboss.remoting.Client.invoke(Client.java:616)
                           at org.jboss.remoting.Client.invoke(Client.java:604)
                           at org.jboss.remoting.Client.invoke(Client.java:589)
                           at org.jboss.remoting.transporter.TransporterClient.invoke(TransporterClient.java:276)
                           at $Proxy244.stop(Unknown Source)

                          at ...

                          I didn't expect UndeclaredThrowableException in this situation.

                          Thanks,

                          • 10. Re: Exceptions in calls and callbacks
                            shdv

                            Disconnect was caused not by my code but by Remoting itself (detected by ping or something else).

                            • 11. Re: Exceptions in calls and callbacks
                              shdv

                              Disconnect was caused not by my code but by Remoting itself (detected by ping or something else).

                              • 12. Re: Exceptions in calls and callbacks
                                ron_sigal

                                From the line numbers, it looks like you're using Remoting 2.0.0. The notion of "connected" changed from 2.0.0 to 2.2.0. I'm not sure what is happening, but you might try upgrading to see of the problem goes away.