<< Back to previous view

[JMX-5] Timeout support Created: 07/Mar/12  Updated: 29/Mar/12

Status: Open
Project: java.jmx
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: Sanel Zukan Assignee: Unassigned
Resolution: Unresolved Votes: 0
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.



 Comments   
Comment by Nick Bailey [ 29/Mar/12 11:34 AM ]

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?





[JMX-8] Extend java.jmx to support exposing operations in created beans Created: 31/Aug/12  Updated: 17/Jun/14

Status: Open
Project: java.jmx
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: Chris Jeris Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None

Attachments: Text File JMX-8.patch    
Patch: Code and Test

 Description   

The attached patch extends java.jmx to support creating beans that expose invokable operations. Operation function definitions are supplied after the state-ref in the create-bean form in a syntax similar to protocol method implementations. Type signatures, descriptions, and impact constants are harvested from metadata on the operation definitions. Nontrivial argument type binders (rest arguments, destructuring, etc) in operations are not supported.

I am sure this patch could be improved in many ways; the operation method parser in create-bean feels unnecessarily hairy and yet limited at the same time, because my macro-fu is not yet strong. The documentation examples are not yet updated, though I am happy to do this if the feature is reviewed and accepted.



 Comments   
Comment by Howard Lewis Ship [ 17/Jun/14 9:59 AM ]

I've done something similar internally, and would love to see some approach to exposing operations as an official part of the library.





[JMX-9] Eliminate several uses of reflection in java.jmx Created: 28/Oct/12  Updated: 16/Dec/12

Status: Open
Project: java.jmx
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Andy Fingerhut Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File jmx-9-eliminate-reflection-v1.txt    
Patch: Code

 Description   

There are a fair number of occurrences of reflection in java.jmx that can be eliminated with the addition of suitable type hints.



 Comments   
Comment by Andy Fingerhut [ 28/Oct/12 11:56 PM ]

jmx-9-eliminate-reflection-v1.txt dated Oct 28 2012 eliminates most reflection warnings from java.jmx.

I would recommend that you check the type hints carefully before applying this, in case I messed some of them up. I am not familiar with javax.management library usage. I simply did a lot of looking at method signatures for methods used in the code in the Java library docs.

In particular, I wasn't sure whether connection should be a javax.management.MBeanServer or MBeanServerConnection. MBeanServerConnection is good enough for most of the code, but for the .registerMBean method invocation in register-mbean it needs to be a MBeanServer to avoid reflection. Perhaps it should be MBeanServer everywhere? My main question is whether that would limit the code's generality too much.

Comment by Nick Bailey [ 16/Dec/12 5:07 PM ]

Well it shouldn't be MBeanServer everywhere. When using the with-connection macro connection is a RemoteMBeanServerConnection and 'registerMBean' isn't a defined method.

I'm thinking perhaps we just change register-mbean to always get the local JMX server rather than using the connection binding. You can't register mbeans with a remote jmx server.





[JMX-12] Throw exception when overloaded operation is ambiguous Created: 26/Nov/13  Updated: 20/Dec/13

Status: Reopened
Project: java.jmx
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Stuart Sierra Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

clojure.java.jmx 0.2.0



 Description   

The clojure.java.jmx/invoke function invokes the first method it finds with a matching name, even if that method's signature does not match the type or number of arguments passed to invoke.

The correct usage is to call invoke-signature, explicitly specifying which method signature to call.

invoke could theoretically examine its arguments and guess the correct signature to call. But without that, it is better to have it throw an exception when the method overloading is ambiguous, instead of just taking the first signature.



 Comments   
Comment by Stuart Sierra [ 20/Dec/13 10:05 AM ]

This appears to be fixed already on master but not included in a release.

Comment by Stuart Sierra [ 20/Dec/13 10:17 AM ]

No, it hasn't been fixed. Commit b76f33a improves the situation but it can still occur.





[JMX-13] Can't connect with username and password Created: 02/Oct/14  Updated: 03/Oct/14

Status: Open
Project: java.jmx
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Janko Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I'm trying to connect with jmx server secured by user/password authentication:

(jmx/with-connection {:host "my.server", :port 50001 :environment {"jmx.remote.credentials" ["user" "pass"]}} (jmx/mbean "java.lang:type=OperatingSystem"))

which ends up with:

ClassNotFoundException clojure.lang.PersistentVector (no security manager: RMI class loader disabled) sun.rmi.server.LoaderHandler.loadClass (LoaderHandler.java:396)

any idea what's goin on here?



 Comments   
Comment by Janko [ 03/Oct/14 6:12 AM ]

sorry, false alarm. I've just realized I should sent :environment params as java array of Strings instead of clojure vector:

(jmx/with-connection {:host "my.server", :port 50001 :environment {"jmx.remote.credentials" (into-array String ["user" "pass"])}} (jmx/mbean "java.lang:type=OperatingSystem"))





Generated at Mon Dec 22 16:49:57 CST 2014 using JIRA 4.4#649-r158309.