All geek questions in one place

Is it possible if JMX registers or displays MBeans forms of different virtual machines on the same central MBean server?

I am looking for a solution to register MBeans or all MBean servers directly from different Java virtual machines on a central MBean server, which should also run in a separate virtual machine. The goal is to have only one central MBean server that contains all the MBeans of the entire system. Another requirement is the difficulty :-) that the "client" MBean servers must connect / register to the central MBean server, and not vice versa. The central MBean server does not need to know the "client" MBean servers for registration.

I just found JMX examples in which the "main" MBean server connects to the "client" MBean servers and transfers their registered MBeans, but not vice versa. Unfortunately, the registerMBean () method, which is used to register your own MBeans, exists only for local MBean servers, but not for remote MBean servers in MBeanServerConnection. You can use the createMbean () method there, the problem here is that it worked to register the MBean on the remote MBean server, but then you have different objects, one local and the other on the remote MBean server. So, now the problem is that when something changes on the local object, there are only changes, the registered MBean on the remote MBean server does not receive these changes (new variable values ​​...). The only solution I have so far is to create a loop to unregister the MBeans on the remote server and create new ones to get the actual values ​​of the object. It is very ugly and also not very good for execution.

I hope someone can give me a hint how I can do it better.

+4
source share
1 answer

OpenDMK provides a complete way to do this using the Cascade Service . From the documentation:

The cascading service allows you to access the MBeans of a subagent directly through the MBean server of the main agent. The cascading service has been completely redesigned in the Java Dynamic Management Kit (Java DMK) 5.1 to allow it to work on socket protocols defined by the Java Management Extensions (JMX) remote API. The legacy of cascading services is now out of date. Examples of legacy cascading services were retained in chapter 25 for reasons of backward compatibility. However, when using legacy Java DMK connectors, you should use the new CasdingServiceMBean with legacy connectors wrapped up instead of relying on the legacy cascading agent API legacy.

There are several interesting snippets in this library that have been inherited to standard Java SE in JMX 2.0. Cascading services, I think, was one of them. Once you understand how this works, you can conclude that this is something you can implement yourself, although there are a few thorny corner cases that OpenDMK answers. I'm not sure how active the project is, but the software looks like stable.

Here you can find the documentation set here . In addition, I created a mavenized project build package here .

// Nikolay

+4
source

Source: https://habr.com/ru/post/1401468/

More articles:


All Articles