Changing timeouts on both the Client and Server side..
Hi!
I am having trouble figuring out how to change the timeout that occurs when a server vanishes and the client, which has not yet been sent a JMXConnectionNotification, unwittingly executes a method such as mbsc.queryNames().
My code can currently wait as long as 120 seconds before a JMXConnectionNotification.CLOSED or JMXConnectionNotification.FAILED arrives.
If the server is closed and the client is made to execute an mbsc method within this period, the method call seems to hang for a full 45 seconds before some kind of timeout occurs. This is the one I wish to change.
Since the server has already gone but no notification has arrived, it seems like the client has already been given some sort of timeout value to use.
How can I set this timeout to a shorter value?
There seems to be a bewildering list of "jmx.remote......" strings that EnvHelp.java references but there does not seem to be any real documentation on how and why to use these.
Thanks.
David
[1023 byte] By [
detaylsa] at [2007-11-15]
David,
What you describe sounds like the behaviour when the server machine is down or unreachable. If the server is just closed (JMXConnectorServer.stop()) or the server process exits, then the client should react punctually. If it does not, then that's probably a bug, and we'd be interested in further details.
If it is indeed the case that the server machine is down or unreachable, then you are seeing the TCP/IP timeout. By default most TCP/IP stacks wait for quite a long time before deciding that a machine is unreachable. You can adjust this, but the way to do so depends on the connector.
If you're using the RMI connector, then you need to set an RMIClientSocketFactory on the server. I can give more details if you confirm that this indeed the problem.
Regards,
蒩monn McManus -- JMX Spec Lead -- http://weblogs.java.net/blog/emcmanus
蒩monn,
Thanks for the quick response. There may indeed be a bug. Here's some more information:
* the above described behavior is all seen on a single Windows XP development machine using localhost and port 9995. JRE is 1.50_06.
* to reproduce the hang, I take the following steps:
start the server application,
start the client application,
open a document that uses AttributeChangeNotification listeners,
change something on the server,
see AttributeChangeNotifications on the client,
exit the server process,
click in the client window and note that the Swing main thread is still responding nicely,
click in the client's close box,
client hangs while executing mbsc.removeNotificationListener.
* the behavior only happens if one or more AttributeChangeNotifications have been asked for. (This adds a ClientNotifForwarder thread.)
* if all data is obtained from the server by polling then the thread asking for the data hangs just like it does in the notify case but there is no timeout, since it does not need to call mbsc.removeNotificationListener.
The code on the server to start the connection is:
mbs = ManagementFactory.getPlatformMBeanServer();
managerBean = new SampleJmxManager(hsj);
ObjectName managerName = null;
try {
managerName = new ObjectName("SampleJmxApp:name=Manager");
mbs.registerMBean(managerBean, managerName);
...
There is no special server closedown code, it ultimately just calls
System.exit(0);
On the client the connection is made by:
HashMap<String, Object> env = new HashMap<String, Object>();
String[] credentials = new String[] {userName, password};
// pass in the username and password
env.put("jmx.remote.credentials", credentials);
// if the URL is to be used, substitute here
if (usingURL()) {
urlstr = url;
} else {
urlstr = "service:jmx:rmi:///jndi/rmi://" +
owner.host + ":" + owner.port + "/jmxrmi";
}
JMXServiceURL url = new JMXServiceURL(urlstr);
jmxConnector = JMXConnectorFactory.connect(url, env);
MBeanServerConnection s = jmxConnector.getMBeanServerConnection();
// make sure we know about connection
// status
jmxConnector.addConnectionNotificationListener(
GmsJmxConnInfo.this,
null, GmsJmxConnInfo.this);
If attribute change notifications are asked for then the client calls mbsc.addNotificationListener with an AttributeChangeNotificationFilter.
If I could somehow tell cheaply that the connection is flaky by making some sort of local call in the client to avoid making a call such as removeNotificationListener(), this would be a big help.
Thanks for looking at this.
David
