2 Replies Latest reply on Mar 22, 2007 3:48 PM by Ron Sigal

    timeout specification

    Jose Luis Newbie


      Consider a client-server application using socket transport.

      the client side app is in a machine called CM
      the server side app is in a machine called SM

      Suppose that the machine SM is not accessible (is turned off or IP address is wrong or network cable is disconnected, etc.).

      You launch the client side and:
      The Client object is created and the connect() method succeeds. why?
      And when you call the invoke() method it get stuck for long time (10 min aprox).

      How can limit this waiting time (may be some kind of timeout)?

      When you do a remote call, how do you specify a timeout?

      In other words.

      I do a remote call and want to specify how long must wait until the call throws the exception.

      Thank you very much.

        • 1. Re: timeout specification
          Jose Luis Newbie

          By the way.

          I have already tried the timeout property when creating the Client instance, but this don't solve this problem :(

          thanx in advance.

          • 2. Re: timeout specification
            Ron Sigal Master

            I just did an experiment in which I set the client's timeout to 1 second and pulled the ethernet plug out of the server machine. I'm using the socket transport, by the way. It took 30 seconds to get a timeout exception. What's happening is that the socket client invoker tries multiple times (30 by default) to get a connection, and each connection timed out after 1 second. The number of attempts can be configured by setting the numberOfRetries parameter.

            Similarly, (also in the socket transport) if a connection has been established and then fails during the invocation, the invocation will be retried (3 times by default). The number of retries can be configured by setting the numberOfCallRetries parameter.

            You might be experiencing something like this. See what happens if you run the client with the log level for org.jboss.remoting loggers set to DEBUG.

            By the way, my client was on a Windows machine and my server was on a linux machine. Java sockets depend on the underlying operating system, and it's just a fact that different environments handle this problem differently. If you have the misfortune to be working in an environment that doesn't give you the support you need, you may have to handle the "unplugged cable" problem at the application level. Just to see that you're not alone, take a look at


            A couple of strategies come to mind. The forum suggests pinging on the connection to see if it's alive, and Remoting can help you with that. Read about leasing and connection validation in Chapter 8 of the Remoting documentation:


            Another possibility would be to put the invocation in a separate thread t, and then, in your main thread, call t.join(timeout).