java.jmx

Timeout support

Details

  • Type: Enhancement Enhancement
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None

Description

In the current java.jmx code there is no way to explicitly setup connection timeout when is used with-connection macro. This option can be quite useful, especially when client is trying to connect to unreliable jmx host or on location where client doesn't know jmx is enabled.

http://weblogs.java.net/blog/emcmanus/archive/2007/05/making_a_jmx_co.html can be used as starting point.

Activity

Hide
Nick Bailey added a comment -

So one way, you can set the socket timeout for jmx connections is by overriding the default rmi socket factory. See:

http://stackoverflow.com/a/1822760/940653

That solution isn't perfect though. For one thing it overrides the default factory for any rmi operation, not necessarily just jmx. It also will only work if jmx is actually falling back to the default factory. For example, if you enable jmx over SSL then the default factory won't be used and that solution won't work. What you could do though is not tell jmx to use ssl, but override the default socket factory to return ssl sockets potentially. Once again though that will be the case for an rmi operations at that point.

The solution in the post you mentioned is interesting. I kind of think adding a custom thread factory and executor service to the jmx library is a bit heavy handed. I might be more comfortable adding some documentation to the readme/wiki detailing the problem and the above possible solutions, so users can find them.

Thoughts on that approach?

Show
Nick Bailey added a comment - So one way, you can set the socket timeout for jmx connections is by overriding the default rmi socket factory. See: http://stackoverflow.com/a/1822760/940653 That solution isn't perfect though. For one thing it overrides the default factory for any rmi operation, not necessarily just jmx. It also will only work if jmx is actually falling back to the default factory. For example, if you enable jmx over SSL then the default factory won't be used and that solution won't work. What you could do though is not tell jmx to use ssl, but override the default socket factory to return ssl sockets potentially. Once again though that will be the case for an rmi operations at that point. The solution in the post you mentioned is interesting. I kind of think adding a custom thread factory and executor service to the jmx library is a bit heavy handed. I might be more comfortable adding some documentation to the readme/wiki detailing the problem and the above possible solutions, so users can find them. Thoughts on that approach?

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated: