I have a implemented mbean and I invoke a method using the jmx-console. This works fine.
My question is: How does this behave in a cluster? Do I have to invoke the method on each node or is this automatically done? If it is configurable, than where can I configure it?
Thank you for your answers.
Related
I want to invoke a Java MBean from UC4.
I found the below link to call the MBean directly from UC4, but I do not see an option in UC4 to create a JMX Job (from New Objects).
https://docs.automic.com/documentation/WEBHELP/English/all/components/AE/10/All%20Guides/Content/ucaccm.htm
Any pointers or blogs on this could be really helpful.
Talk to your UC4 administrator. He/she needs to allow access to the agent from your UC4 client number. Also, he/she needs to update the variable object named UC_OBJECT_TEMPLATE to include JOBS.JMX.
UC_OBJECT_TEMPLATE exists in client 0000 and may also exist in the client where you are currently logged in. If it exists in your current client, JOBS.JMX will need to be added to the UC_OBJECT_TEMPLATE in your current client.
I am using the Grails Rabbitmq Native plugin. When I launch the application, I don't want the RMQ consumers to be automatically started, so in my Config.groovy I have defined:
rabbitmq.enabled == false
The code within doWithSpring() (https://github.com/budjb/grails-rabbitmq-native/blob/master/RabbitmqNativeGrailsPlugin.groovy#L114) means that certain wiring isn't carried out if this flag is false.
At some point, I want to be able to start the RMQ system up. I'd like to call a method defined within the plugin class, such as restartRabbitContext() (https://github.com/budjb/grails-rabbitmq-native/blob/master/RabbitmqNativeGrailsPlugin.groovy#L231) to start up the RMQ consumers. I think I will need to carry out some of the wiring myself.
Is there a way to do this? What is the import required to be able to access the plugin class's methods?
Your best bet is to use the GrailsPluginManager to access your plugin by name using getGrailsPlugin. From there you should be able to access the plugin as a GrailsPlugin and access the public methods defined in the plugin itself.
The GrailsPluginManager can be obtained though the grailsApplication such as: grailsApplication.pluginManager. In the very rare event you can't use DI you can always fall back to Holders to get to the GrailsPluginManager (though this is a very rare case).
I want to load a custom JMX Client into a JVM by wrapping the client in a javaagent package and query MBeans locally. My intent is that the JMX Client will periodically query the host application's MBeans or receive notifications. However, since the javaagent is loaded before the main jar (via premain), the host applications's MBeans are not yet available. How should I handle this "chicken before the egg" problem? Are threads appropriate for this? Or is there some other JMX mechanism that would be preferred?
Thank you
Start a loop with a sleep in it until you successfully get the target MBeanServer. If this is the platform MBeanServer, you should get it immediately using ManagementFactory.getPlatformMBeanServer(). Then register a notification listener with the ObjectName defined as MBeanServerDelegate.DELEGATE_NAME. Filter for notifications of the class MBeanServerNotification, with notification types of MBeanServerNotification.REGISTRATION_NOTIFICATION. Your notification listener will get a callback every time a new MBean is registered in the target MBeanServer.
Is there any interceptor I can use to validate incoming requests to the Grails service classes/Endpoints?
I know interceptors for controllers but I want to do it for Service/endpoint.
This sounds like what you are looking for:
Intercepting Service Methods
In the link mentioned above(Kelly's reply), interceptor logic for Service has been added in BootStrap class. That might suffice in most of the cases but not all. In case you are using Quartz scheduler then job might get triggered even before BootStrap has made required modifications.
The best place to modify a service method would be via custom plugin. You can decorate service method in doWithApplicationContext or doWithDynamicMethod available in Plugin class. These methods are triggered at first and guarantee that changes made will be available to all other classes. Please refer Grails custom plugin documentation for more information.
I've just run into a problem with a Quartz job that I'm invoking through Spring. My ExecuteInternal method had a [Transaction] attribute (because it does a load of DB calls) but when it runs, I get the 'No NHibernate session bound to thread' error.
Just wondering if that's because Spring.NET doesn't support the [Transaction] attribute in Quartz objects?
If not, that's fine... I can start a transaction manually, but wanted to check that it was the case, and not a silly error in my config somewhere.
[Update]
I figured it out actually. In the API docs, it says the preferable way to do this is use transactions on the service layer. My job was using DAOs to do its work, but my transactions are on my service layer, so I just called service methods from my job instead to do the same work (saving, updating records etc) since they already existed.
It also suggests that if you give the SchedulerFactoryObject a DbProvider, you can use transactions in the job itself, but when I did that it seemed to want to find my triggers configured in a special table in the DB (which I haven't set up since my triggers are all in XML) but that's possibly another way to do it.
Calling service methods works fine for me though.
The transaction attribute works using aop. Spring.NET creates an aop proxy for the decorated object. This proxy creates the session and starts the transaction.
In the ExecuteInternal method, you don't call the method on a proxy, but on the target itself. Therefore spring cannot intercept the call and do its transaction magic.
Your services are injected and therefore the transaction attribute works for them.
There's a good explanation in the spring docs on this subject: http://www.springframework.net/doc-latest/reference/html/transaction.html#tx-understandingimpl