There is no way to do this currently wihtin remoting. However, can add config on client side so that can pass timeout desired per invocation.
Have created a jira issue for this to be added in remoting 2.2.0 release - http://jira.jboss.com/jira/browse/JBREM-598
I made the changes as per your suggestion, the request still is timing out incorrectly.
The client is created as shown below:
String hostName = InetAddress.getLocalHost().getHostName();
String locatorURI = "socket://" + hostName + ":5000/?timeout=120000";
InvokerLocator locator = new InvokerLocator(locatorURI);
Client client = new Client(locator);
The server connector also has the same timeout configuration.
The changes as per your suggestion when calling the invoke:
HashMap config = new HashMap();
config.put("timeout", new Long(5000)); // Test - 5 seconds
res = client.invoke(arg, config);
The request is not timing out correctly even with the above code changes. I am using Java version 1.4.2 and JBossRemoting 1.4.1.
I am not sure if I am missing anything here.
I don't think I phrased it well in my previous post. Can not set the timeout per config in the invocation currently, but have added a jira issue so that will be added within the next remoting release.
Per invocation timeouts have been implemented for the socket and sslsocket transports, as well as the newly derived bisocket and sslbisocket transports.
A timeout that will apply only to the current invocation may be requested as follows:
HashMap config = new HashMap(); config.put(ServerInvoker.TIMEOUT, "5000"); // Test - 5 seconds res = client.invoke(arg, config);
where the value of ServerInvoker.TIMEOUT is "timeout".
Per timeout invocation now works for the HTTP transport as well. For jdk 1.5 the timeout is set on the HttpUrlConnection. For jdk 1.4 this option is not available, so it is simulated by executing the invocation on a separate thread and waiting until the timeout has expired. The thread comes from a threadpool which defaults to org.jboss.util.threadpool.BasicThreadPool, but the thread pool can be configured by calling org.jboss.remoting.transport.HTTPClientInvoker.setTimeoutThreadPool(). If the default thread pool is used, it can be configured by passing HTTPClientInvoker.MAX_NUM_TIMEOUT_THREADS (value "maxNumTimeoutThreads", defaults to 10) and HTTPClientInvoker.MAX_TIMEOUT_QUEUE_SIZE (value "maxTimeoutQueueSize", defaults to 1024) in the configuration Map with which the org.jboss.Remoting.Client is initialized.
I have noticed a strange behavior with respect to timeouts. The timeout parameter works fine when the server is accessible to the client through the network. However, if this is not the case (for example if the server is shut down or the network cable is unplugged), the timeout parameter does not seem to work. The invocation hangs for a long time (around 11 minutes in my machine) and it is only after this long period that I get an exception (even if my timeout is configured for a shorter period).
Is there any way to avoid this situation? Or does anybody know of a way to abort the remote call after a certain period of time?
Thank you very much.
What should happen (at least with 2.2.0 code) is when a server is killed while processing a client invocatoin, the client will get a connection reset exception (is a SocketException that is actually thrown internally). Internally, remoting client catches that SocketException and re-tries the invocation (several times). I think the delay you are seeing is due to the number of times it retries along with the amount of time it takes for the connection timeout to kick in (i.e. timeout * numberOfRetries * numberOfCallRetries).
If want immediate failure, can set numberOfRetries and numberOfCallRetries to 0 (see http://labs.jboss.com/portal/jbossremoting/docs/guide/ch05.html#d0e1088).