I have a RMI system set up and want to change the connectTimeout default value of 15 secs. I want to make it shorter. can someone show me the proper syntax to do this. I read somewhere that
sun.rmi.transport.proxy.connectTimeout
is what I'm supposed to use...but am not sure.
Fred
Hi,
you can try this :
import java.rmi.server.RMIClientSocketFactory;
import java.net.*;
import java.io.*;
public class TimedRMIClientSocketFactory implements RMIClientSocketFactory, Serializable {
public Socket createSocket(String host, int port) throws IOException {
Socket s = new Socket(host, port);
s.setSoTimeout(5000);
return s;
}
}
static {
RMISocketFactory.setSocketFactory(new TimedRMIClientSocketFactory ());
}
That doesn't set a connect timeout, it sets a read timeout.
And RMISocketFactory was deprecated in 1998: don't use it, and please don't recommend to others. And the code doesn't compile anyway.
@OP: -Dsun.rmi.transport.proxy.connectTimeout=timeout, in milliseconds. See http://java.sun.com/j2se/1.5.0/docs/guide/rmi/sunrmiproperties.html.
I didn't found any deprecation TAG in the javadoc...
In my mind using RMISocketFactory is a convenient way to set a read timeout for client and server with the same code. If I use RMIClientSocketFactory and RMIServerSocketFactory, I need to write 2 classes to implement read timeout on both sides.
But... that's not really the place to start flamming, you've answered to the original question, that's the most important thing.
Olivier
.
Bizarre! It certainly was deprecated.
The problems with using it as opposed to client/server socket factories are that if you use it to implement SSL (or any superimposed protocol) you can't talk to the ActivationSystem any more, and you lose HTTP tunnelling in all 3 forms. There are others which I'm afraid I can't even remember after all these years ...
IMHO Sun made several mistakes with socket factories, treating them as a universal solution without providing a way for them to be stacked together. And the notion of an SSL client downloading an SSL client socket factory that it has no means of establishing trust with and no way of controlling is frankly just bizarre. If you look at what they did with the Davis project (JERI) in Jini 2.0 you get a hint as to what the possible problems with just the JDK facilities are. Shame it never got into the JDK, but shame they didn't listen to the people who wanted an SPI architecture for RMI too, and find a way to combine all this together.