Support for JMX notifications (events) #644 #646

dgloeckner · 2018-03-01T10:29:52Z

I've started to implement support for JMX notifications as discussed in the issue.

It's working end-to-end as can be seen in JmxTransformerIT integration test.

For now the only kind of Notification which is supported is AttributeChangeNotification. Applications could of course implement their own Notifications but jmxtrans would need to have related classes on its class path. It's probably not the common case.

My use case is the following:

Publish events (e.g. completed business processes with execution time and meta data).
Stick to AttributeChangeNotifications, Java collections and primitives to model events.

Example publisher:

public class Hello
        extends NotificationBroadcasterSupport
        implements HelloMBean {

       ....
        Map<String, Object> vals = new HashMap<>();
        vals.put("cacheSize", this.cacheSize);
        vals.put("someId", "12345");
        vals.put("someVersion", "1.2.3");

        Notification n = new AttributeChangeNotification(this,
                sequenceNumber++, System.currentTimeMillis(),
                "Event occurred", "CustomEvent",   "Map",
                null, vals);

        sendNotification(n);

Example jmxtrans configuration:

          {
          "obj": "Examples:type=JMX,name=MXBean",
          "resultAlias": "myEvent",
          "queryType" : "NOTIFICATIONS",
          "attr": ["CacheSize"],
          "outputWriters": [
            {
              "@class": "com.googlecode.jmxtrans.model.output.InfluxDbWriterFactory",
              "url": "http://127.0.0.1:8086/",
              "username": "admin",
              "password": "admin",
              "database": "appstats",
              "tags": {
                "application": "my-app2"
              }
            }
          ]
        }

The query will subscribe to nofitications of the CacheSize attribute which are published by the configured MBean. queryType is set to NOTIFICATIONS to tell jmxtrans that we want to use events here and not polling.

Example data from InfluxDB:

> select * from myEvent where time > now() - 1m
name: myEvent
time                 CacheSize CustomEvent_cacheSize CustomEvent_someId CustomEvent_someVersion _jmx_port application attributeName className hostname  objDomain typeName
----                 --------- --------------------- ------------------ ----------------------- --------- ----------- ------------- --------- --------  --------- --------
1522362599612000000            22                    12345              1.2.3                   10000     my-app2     CustomEvent   Hello     localhost Examples  type=JMX,name=MXBean
1522362601803000000            1                     12345              1.2.3                   10000     my-app2     CustomEvent   Hello     localhost Examples  type=JMX,name=MXBean
1522362612651000000            22                    12345              1.2.3                   10000     my-app2     CustomEvent   Hello     localhost Examples  type=JMX,name=MXBean
1522362630900000000            11                    12345              1.2.3                   10000     my-app2     CustomEvent   Hello     localhost Examples  type=JMX,name=MXBean

We can of course discuss the overall design and limitations. I'm keen to hear feedback.

First attempt

…ification to attribute to be able to re-use JmxResultProcessor (WIP) + extended integration test

AppVeyorBot · 2018-03-01T10:30:32Z

❌ Build jmxtrans 99 failed (commit db34444d0e by @dgloeckner)

gehel · 2018-03-01T10:44:14Z

jmxtrans-core/src/main/java/com/googlecode/jmxtrans/connections/JMXConnection.java


 @ToString
 @ThreadSafe
 public class JMXConnection implements Closeable {
-	@Nullable private final JMXConnector connector;
-	@Nonnull @Getter private final MBeanServerConnection mBeanServerConnection;
+	@Nullable


It would be nice to not reformat code that you don't touch. It makes reviewing it much easier...

Sorry was a mistake and yes makes reviewing a lot easier ;) I'll double check next time.

No problem, that's really a minor issue...

gehel · 2018-03-01T10:46:28Z

jmxtrans-core/src/main/java/com/googlecode/jmxtrans/connections/JMXConnection.java

+					AttributeChangeNotification changeNotification = (AttributeChangeNotification) notification;
+					return attributes.contains(changeNotification.getAttributeName());
+				}
+				return false;


Minor style issue: I prefer to have preconditions with early return instead of nested blocks. In this case, I think it would be nicer to have:

if (! notification instanceof AttributeChangeNotification) return false; [...]

Besides the style issue, do you think that limiting the support to AttributeChangeNotifications is OK for now?

I have a feeling that supporting other kind of notification could have value. But starting with just AttributeChange and building up from there is perfectly fine (even better!). We can always improve later if there is a need.

gehel · 2018-03-01T10:52:48Z

jmxtrans-core/src/main/java/com/googlecode/jmxtrans/connections/JMXConnection.java

 	private boolean markedAsDestroyed;
 	private static final Logger logger = LoggerFactory.getLogger(JMXConnection.class);

+	private final IdentityHashMap<Object, QueryNotificationListener> notificationListeners = new IdentityHashMap<>();


Note that JMXConnections are pooled and should be considered ephemeral. Keeping a list of notificationListeneners as an instance member will probably cause issues when connections are recycled by the pool.

In the design with polling (see the other comment) I needed to map received notifications to the query (List getNotifications(Object query)). We would not need such a mapping if we implement a push-based approach as you suggested. Let's see how it goes :)

I think that the real issue is that JMX notifications rely on a long lived JMX connection. Which to some extend goes against the model we have. And in all cases, JMX connection can break for a number of reason (transient network issues seems the most obvious). So we need to account for that in some way. Not an easy task.

Yes, we need to re-create listeners when re-creating connections. We would need to detect the liveness of JMX connections and deal with listener re-creation. Any hints appreciated :)

gehel · 2018-03-01T10:54:38Z

jmxtrans-core/src/main/java/com/googlecode/jmxtrans/model/Query.java

 	private static final Logger logger = LoggerFactory.getLogger(Query.class);

 	/** The JMX object representation: java.lang:type=Memory */
 	@Nonnull @Getter private final ObjectName objectName;
+	@Getter private final QueryType queryType;


queryType should be @nonnull

gehel · 2018-03-01T10:55:10Z

jmxtrans-core/src/main/java/com/googlecode/jmxtrans/model/Query.java

@@ -241,6 +256,41 @@ public String makeTypeNameValueString(List<String> typeNames, String typeNameStr
 		return ImmutableList.of();
 	}

+	public synchronized boolean isNotificationListenerRegistered(JMXConnection jmxConnection) {


Synchronization is probably not necessary here. The Query itself is immutable, so you're not protecting any state that is local to that class. If synchronization needs to happen, it is in the JMXConnection itself.

gehel · 2018-03-01T11:01:33Z

jmxtrans-core/src/main/java/com/googlecode/jmxtrans/model/Server.java


-			for (ObjectName queryName : query.queryNames(connection)) {
-				results.addAll(query.fetchResults(connection, queryName));
+			if(query.getQueryType() == Query.QueryType.POLL) {


An Enum looks like a good candidate for a switch statement instead of ifs.

Sure... final cleanup pending :)

gehel · 2018-03-01T11:04:18Z

jmxtrans-core/src/main/java/com/googlecode/jmxtrans/model/Server.java

+				}
+			} else {
+				// Subscribe to notifications
+				if(!query.isNotificationListenerRegistered(jmxConnection)) {


A notification should probably not be executed, but registered at startup. The processing of results should be done when the notification is received, not polled. Basically, the notification listener should directly send results to the ResultProcessor...

The design with polling was the simplest starting point I could think of. Just for my understanding, why do you think polling is not a good idea in this case?

Pushing (converted) notifications to registered ResultProcessors could also be implemented.

I need to understand

where I could register the notification listeners at startup

how to retrieve the output writers for a given query

Are output writers thread safe?

Polling an intermediate list of notification requires to keep that state for some time. As you noted in your comment, that state can grow unbounded and end in an OOM (so at least that queue should be bounded). Also, having a queue of notification will delay those notifications from being processed for a somewhat arbitrary reason. If in the end, we're functionally just doing polling of an attribute value, then why not do just that and use the current query mechanics.

I agree to the points about polling. Whether the delay is acceptable depends on the use case I guess. For me having a few seconds delay is acceptable. I disagree that polling from a list of received notifications is equivalent to polling MBeans. In the former case, the publisher sends explicit events and we should receive all of them (if we stay connected). This is not guaranteed with polling of MBeans as we might miss intermediate attribute values.

One problem with the pushing design is that we need to re-register listeners when re-creating JMX connections. I guess MBeanServerConnectionFactory can't do this for us. On the other hand, it's the only one who knows when a connection is created. I was thinking that the initial listener registration could happen from JmxTransformer when we iterate over servers and queries. But how to handle broken and re-created connections is still a mistery to me. Would you have any idea?

gehel · 2018-03-01T11:06:51Z

jmxtrans-test-utils/src/main/java/com/googlecode/jmxtrans/test/OutputCapture.java

@@ -52,6 +52,9 @@ protected void before() throws Throwable {
 	protected void after() {
 		System.setOut(originalOut);
 		System.setErr(originalErr);
+		// I guess it's useful to print this after completion
+		System.out.println("What was captured:");


I would disagree... It is the job of the client of OutputCapture to print stuff if it make sense. In most cases, it probably does not. And even if it does, it should be sent to a logger.

I just found that debugging the integration test was painful. After adding the above output, I was able to see that my test needed to be fixed.

I think that in this case, you should probably add the output to the integration test itself, via a logger. Or use a debugger when debugging, step through the code and check the state...

gehel · 2018-03-01T11:08:59Z

jmxtrans-core/src/main/java/com/googlecode/jmxtrans/connections/QueryNotificationListener.java

+ */
+class QueryNotificationListener implements NotificationListener {
+
+	private final List<Notification> notifications = new ArrayList<>();


You probably want to use a concurrent queue instead of an ArrayList here. You could then get rid of all the synchronization of this class.

gehel · 2018-03-01T11:15:15Z

Great to see this moving forward! I added a few comments inline. I really need to take more time to review this (I know next to nothing about JMX notifications). But here is already some feedback. Thanks a lot for digging into this! That's a great addition to jmxtrans!

how to re-use JmxResultProcessor (see TODO in code of Server class)

Not sure I understand the question. I need to spend some more time reading that code.

how to feed timestamps from notifications into the jmxtrans records

The Result class has an epoch field that is the timestamp of the result.

is the approach of subscribing for notifications (JMXConnection.addNotificationListener()), collecting them in a data structure (QueryNotificationListener) and fetching the received notifications as part of the normal jmxtrans query mechanism (JMXConnection.getNotifications()) OK from your POV?

I think that we should treat notifications as events, and process them as soon as they arrive. This might be problematic for some output writers, which have the assumption that results arrive at regular intervals. But for most, it should work and would remove the delay. If we do need to do time based batches, this should be taken out of the QueryNotificationListener and implemented as its own composable class.

cyclic package dependencies are forbidden in jmxtrans project ;) As a result, JMXConnection.addNotificationListener cannot depend on Query. The extended API in JMXConnection is quite ugly atm and uses Object instead of Query ;)

No project should allow package cycles :) In this case, it looks like we have mixed responsibilities a bit. I have not looked into details, but it looks like the code related to notifications should not be in JMXConnection, but probably extracted to its own class, and moved probably to its own package.

How to deal with configuration changes, i.e. removed queries. We need to unsubscribe in this case. Or are all JMXConnections dropped in this case? If yes it would already worked as JMXConnection.close() does unsubscribe.

Short answer: we deal badly with config changes. We should drop everything and restart, but the connection pools are probably not re-initialized correctly. Note that JMXConnection is pooled and should be considered as an ephemeral object. It can be closed, killed, ... at any time.

…ners are subscribed when a new JMX connection for a server is created. NotificationProcessor translates notifications to results and passes them to output writers of the query.

AppVeyorBot · 2018-03-03T15:57:22Z

❌ Build jmxtrans 101 failed (commit 0b3489ae08 by @dgloeckner)

dgloeckner · 2018-03-03T16:02:44Z

Hi,

I've just pushed a commit where I changed my design to use pushing instead of polling.

Here's how it works:

when a new JMX connection is created for a given server (JmxConnectionProvider) the notification listeners are registered. MBeanServerConnectionFactory calls server.subscribeToNotifications() when a connection is created.
NotificationProcessor receives the notifications, converts them to results and passes them to the configured output writers. On the calling thread atm.
Epoch (timestamp) is taken from the notification itself.

Some questions popped up:

query.queryNames() - what is this used for and do I use it correctly in Query.subscribeToNotifications()
Threading / concurrency: see comment in NotificationProcessor
objectInstance in JmxResultProcessor: am I passing in the correct object?

Keen to hear your feedback.

Cheers,
Daniel

gquintana · 2018-03-03T21:28:17Z

See #648 for problem with AppVeyorCI

AppVeyorBot · 2018-03-03T22:46:37Z

✅ Build jmxtrans 106 completed (commit aee8030fc9 by @dgloeckner)

gquintana

Interesting

gquintana · 2018-03-06T10:10:01Z

...ans-core/src/main/java/com/googlecode/jmxtrans/connections/MBeanServerConnectionFactory.java

 		} else {
 			JMXConnector connection = server.getServerConnection();
-			return new JMXConnection(connection, connection.getMBeanServerConnection());
+			newJMXConnection =  new JMXConnection(connection, connection.getMBeanServerConnection());
+			// TODO: also for local???


Why not local? Can you see an issue?

gquintana · 2018-03-06T10:11:23Z

jmxtrans-core/src/main/java/com/googlecode/jmxtrans/jmx/JmxUtils.java

-				executor.submit(pqt);
-			} catch (RejectedExecutionException ree) {
-				logger.error("Could not submit query {}. You could try to size the 'queryProcessorExecutor' to a larger size.", pqt, ree);
+			if(query.getQueryType() != Query.QueryType.NOTIFICATIONS) {


if(query.getQueryType() == Query.QueryType.NOTIFICATIONS) { continue; }

would be clearer

I wonder whether we could abstract how values are fetched using some strategy pattern: local poll, remote poll, notifications. It may avoid all the if local, if notification... It may be a pure utopia...

gquintana · 2018-03-06T10:20:40Z

jmxtrans-core/src/main/java/com/googlecode/jmxtrans/model/Query.java

+				}
+			};
+
+			jmxConnection.addNotificationListener(oi.getObjectName(),


NotificationListener is never removed, except when connection is closed. Isn't there a risk of memory/resource leak in the monitored app?

In case of a broken connection the monitored app would need to remove the (dead) listeners. I haven't checked the JMX server code yet but there must be some logic for that.

There isn't any logic yet. It is probably possible to plug into the connection pool to process the removal of listener before a JMXConnection is killed.

Which connection pool are you referring to here? From our pov the monitored app is a pure JAVA app which exposes metrics via JMX. About listener removal in jmxtrans, I'm taking care of it (I hope).

The JMX Connections are pooled. The pool is managed by a Guice module, and is used in Server.execute(). Having a pool for the JMX connection is mainly useful to ensure that connections are validated, recycled, and overall managed correctly. It make things a bit awkward for notifications. You can't assume that a there is a single JMX Connection to any application. You also can't assume that those connections are long lived (well, you should never assume they are, things can and will break, connections will be reset outside of your control).

You can't assume that a there is a single JMX Connection to any application.
That's true, but can I assume that there's a single JMX connection per configured server (might be multiple "server configs" for the same application)? If yes, my design should work.

Nope, you can't even assume that there is a single connection per server. The GenericKeyedObjectPool that we use works as a map of sub pools. This allows multiple threads to work in parallel to execute queries. Since JMXConnections are threadsafe and probably have very low contention, we could use a smarter way of managing them, getting away from the KeyedObjectPool and implementing connection validation / recycling. That might be a solution, but it requires a non trivial amount of work.

gquintana · 2018-03-06T10:24:35Z

jmxtrans-core/src/main/java/com/googlecode/jmxtrans/model/JmxResultProcessor.java


 	public JmxResultProcessor(Query query, ObjectInstance objectInstance, List<Attribute> attributes, String className, String objDomain) {
+		this(query, objectInstance, attributes, className, objDomain, System.currentTimeMillis());


IMHO, it makes more sense to leave this specific instantiation in NotificationProcessorImpl. I didn't understand the purpose of this constructor at first.

Agreed! Also, don't use System.currentTimeMillis(), there is a Clock abstraction in jmxtrans, you should use it. (and we should replace it with java.time.Clock at some point).

Re-reading that class again, it is a mess (it was already before you touched it!). The time of query should be injected, not instantiated here.

gquintana · 2018-03-06T10:46:31Z

jmxtrans-test-utils/src/main/java/com/googlecode/jmxtrans/test/OutputCapture.java

@@ -52,6 +52,9 @@ protected void before() throws Throwable {
 	protected void after() {
 		System.setOut(originalOut);
 		System.setErr(originalErr);
+		// I guess it's useful to print this after completion


dgloeckner · 2018-03-15T20:40:08Z

@gquintana @gehel I appreciate if you could have a look at my questions posted after the latest commit :)

gehel · 2018-03-16T08:57:14Z

A few comments:

when a new JMX connection is created for a given server (JmxConnectionProvider) the notification listeners are registered. MBeanServerConnectionFactory calls server.subscribeToNotifications() when a connection is created.

That is problematic as multiple JMX Connections can be opened to a single application (see inline comment about connection pool). We need to abstract the subscription even more. Also I think that the pool has a default min idle of 0, which means that the connections are created only on demand. If we only have notification queries, the connection will probably never be created and the notifications never registered.

NotificationProcessor receives the notifications, converts them to results and passes them to the configured output writers. On the calling thread atm.
Epoch (timestamp) is taken from the notification itself.

That looks fine.

Some questions popped up:

query.queryNames() - what is this used for and do I use it correctly in Query.subscribeToNotifications()

Yes, you seem to use it correctly. A query can resolve to multiple mbeans. queryNames() will execute the query and return a list of the ObectNames of the mbeans matching the query.

Threading / concurrency: see comment in NotificationProcessor
objectInstance in JmxResultProcessor: am I passing in the correct object?

I'm not sure what you are referring to. Could you add a link?

gehel · 2018-03-16T08:58:53Z

jmxtrans-core/src/main/java/com/googlecode/jmxtrans/model/NotificationProcessor.java

+
+import javax.management.Notification;
+
+public interface NotificationProcessor {


This interface has a single implementation, and does not provide any additional abstraction. Just merge it with the implementation class.

Needed to avoid package cycle. You might suggest another design but there are similar examples in jmxtrans already (also with single implementation):

jmxtrans is full of examples of things you should never do :) I'll have a look to see if I can find a better solution.

gehel · 2018-03-16T08:59:48Z

jmxtrans-core/src/main/java/com/googlecode/jmxtrans/model/NotificationProcessorFactory.java

+
+import javax.management.ObjectInstance;
+
+public interface NotificationProcessorFactory {


Same here, this interface does not add any value, please remove it.

Needed to avoid package cycle. You might suggest another design but there are similar examples in jmxtrans already (also with single implementation):

gehel · 2018-03-16T09:00:59Z

...rans-core/src/main/java/com/googlecode/jmxtrans/notifications/NotificationProcessorImpl.java

+	private List<Result> transform(Notification notification) {
+		if (notification instanceof AttributeChangeNotification) {
+			AttributeChangeNotification changeNotification = (AttributeChangeNotification) notification;
+			List<Attribute> attributes = new ArrayList<>(1);


Use Collections.singletonList() instead of an explicitly sized ArrayList.

gehel · 2018-03-16T09:11:30Z

Despite all the comments, congratulation on the nice job! You are trying to address a complex problem, within a code base that could be much cleaner than it is! I hope we'll manage to make all that work!

…otFoundException "no security manager: RMI class loader disabled"

AppVeyorBot · 2018-03-28T06:27:11Z

❌ Build jmxtrans 160 failed (commit 1501042351 by @dgloeckner)

…work)

…ion handling + using an object pool with max size set to 1. Server + query are used as a compound key for the pool. That way, the same NotificationProcessor instance is returned each time we ask for a certain server / query combination. + periodically subscribing, re-subscribing to notifications. + using a dedicated JMX connection per server and query to deal with notifications. Makes the implementation simpler as we know which listeners in the JMX connection are registered already.

AppVeyorBot · 2018-03-29T22:48:03Z

✅ Build jmxtrans 161 completed (commit 23fefe097e by @dgloeckner)

dgloeckner · 2018-03-29T22:52:58Z

@gehel I've just pushed a major change. There's now an explicit object pool which handles a notification processor per server-query tuple. A notification processor has a private JMX connection so managing the subscriptions (also with varying nr of returned object names) is much easier. The notification listeners will be subscribed / re-subscribed at a regular interval.

dgloeckner · 2018-03-29T22:55:10Z

I'm sure there are more reviews for "cosmetic" changes. I hope we get closer to the final design now and than the fine tuning can start.

…s not exist any more in the remote + Improved JavaDoc

dgloeckner · 2018-03-30T20:54:35Z

Here's the gist of the re-design:

    public void subscribeToNotifications(final Server server) throws Exception {
		NotificationProcessor processor = null;
		ServerQuery serverQuery = new ServerQuery(server, this);
		try {
			processor = notificationProcessors.borrowObject(serverQuery);
			processor.subscribeToNotifications();
		} catch (Exception e) {
			if(processor != null) {
				notificationProcessors.invalidateObject(serverQuery, processor);
			}
			throw e;
		} finally {
			notificationProcessors.returnObject(serverQuery, processor);
		}
	}

Calling processor.subscribeToNotifications() takes care of adding new notification listeners and removing notification listeners for which the remote object name does not exist any more. The notification processor contains a JMXConnection. Since the notification processor relies on state in the JMXConnection (registered listeners) the 1:1 relation between processor and connection simplifies things a lot.

If anything goes wrong during subscribeToNotifications(), we tell the object pool to invalidate the processor. The object pool is configured with max active = 1 so the periodic call to server. subscribeToNotifications() will always get the same notification processor for a given server - query tuple.

What I like is that the state for notification listeners is isolated in one object, the NotificationProcessor. That object is responsible for bookkeeping. It features "let it crash" as we can simply throw away a notification processor which threw an exception (possibly due to a connection issue) and we'll try again from scratch without any extra code.

Calling processor.subscribeToNotifications() periodically also acts as a "heart beat" to ensure that the JMX connection is still alive so we can be sure that we're able to receive notifications. It also takes care of new object names appearing at run time which could match our query.

dgloeckner · 2018-03-30T21:04:18Z

TODOs:

have design approved ;)
add unit tests and extend integration test further (e.g. MXBeans added / removed at runtime, simulate broken connections)
fix all issues from code review once the design is approved
document usage, design and limitations

…tr" values as enabled attributes. If not "attr" are provided, no filter will be passed.

dgloeckner · 2018-04-02T11:54:00Z

@gehel would be cool if you could review the re-design, specifically handling of JMX connections. Maybe one JMX connection per server and query to receive notifications is too extreme. On the other hand, I wanted to keep state management simple which is a feature of the current design.

dgloeckner · 2018-04-02T11:58:54Z

...trans-output-influxdb/src/main/java/com/googlecode/jmxtrans/model/output/InfluxDbWriter.java

@@ -178,7 +178,7 @@ public void doWrite(Server server, Query query, Iterable<Result> results) throws

 			HashMap<String, Object> filteredValues = newHashMap();
 			Object value = result.getValue();
-			if (isValidNumber(value)) {
+			if (isValidNumber(value) || value instanceof String) {


It seems strange to only allow "valid numbers". InfluxDB for sure allows to store Strings. I'm now also accepting Strings but I guess we should review the whole filtering logic.

tjeppesen · 2019-07-24T13:44:49Z

Was this merged into JMXTrans? Does the latest JMXTrans release support mbean notifications?

dgloeckner added 2 commits February 27, 2018 14:03

Support for JMX notifications (events) jmxtrans#644

f46caf2

First attempt

jmxtrans#644: round-trip working with first attempt of converting not…

6628ef3

…ification to attribute to be able to re-use JmxResultProcessor (WIP) + extended integration test

gehel reviewed Mar 1, 2018

View reviewed changes

jmxtrans#644: re-designed notification processing. Notification liste…

2d8e04c

…ners are subscribed when a new JMX connection for a server is created. NotificationProcessor translates notifications to results and passes them to output writers of the query.

dgloeckner added 3 commits March 3, 2018 22:16

jmxtrans#644: using timestamp from notification as epoch

7e400d4

jmxtrans#644: making tests green

0496cdb

jmxtrans#644: using timestamp from notification as epoch

c57a49e

jmxtrans#644: using executor service from repository

711f50b

gquintana reviewed Mar 6, 2018

View reviewed changes

gehel reviewed Mar 16, 2018

View reviewed changes

jmxtrans#644: InfluxDbWriter was swallowing String values

c3993fb

dgloeckner added 2 commits March 28, 2018 08:21

jmxtrans#644: InfluxDbWriter was swallowing String values

72c5992

jmxtrans#644: fixes after testing with real application. Avoid ClassN…

a460ca6

…otFoundException "no security manager: RMI class loader disabled"

dgloeckner added 3 commits March 29, 2018 20:06

jmxtrans#644: periodic subscription for notifications

cbbc921

jmxtrans#644: don't subscribe when connections are created (does not …

a8392a0

…work)

dgloeckner added 2 commits March 30, 2018 22:37

jmxtrans#644: removing notification listener when the object name doe…

a2cec68

…s not exist any more in the remote + Improved JavaDoc

jmxtrans#644: simplified interface

ca952fb

dgloeckner added 2 commits March 30, 2018 23:13

jmxtrans#644: fixed checkstyle

af284b3

jmxtrans#644: use AttributeChangeNotificationFilter which has all "at…

9f1e2a9

…tr" values as enabled attributes. If not "attr" are provided, no filter will be passed.

dgloeckner commented Apr 2, 2018

View reviewed changes


		public JmxResultProcessor(Query query, ObjectInstance objectInstance, List<Attribute> attributes, String className, String objDomain) {
		this(query, objectInstance, attributes, className, objDomain, System.currentTimeMillis());


		import javax.management.Notification;

		public interface NotificationProcessor {


		import javax.management.ObjectInstance;

		public interface NotificationProcessorFactory {

Support for JMX notifications (events) #644 #646

Are you sure you want to change the base?

Support for JMX notifications (events) #644 #646

Conversation

dgloeckner commented Mar 1, 2018 • edited

AppVeyorBot commented Mar 1, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gehel Mar 1, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gehel Mar 1, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gehel commented Mar 1, 2018

AppVeyorBot commented Mar 3, 2018

dgloeckner commented Mar 3, 2018 • edited

gquintana commented Mar 3, 2018

AppVeyorBot commented Mar 3, 2018

gquintana left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dgloeckner commented Mar 15, 2018

gehel commented Mar 16, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gehel commented Mar 16, 2018

AppVeyorBot commented Mar 28, 2018

AppVeyorBot commented Mar 29, 2018

dgloeckner commented Mar 29, 2018

dgloeckner commented Mar 29, 2018

dgloeckner commented Mar 30, 2018 • edited

dgloeckner commented Mar 30, 2018

dgloeckner commented Apr 2, 2018

dgloeckner Apr 2, 2018 • edited

Choose a reason for hiding this comment

tjeppesen commented Jul 24, 2019

dgloeckner commented Mar 1, 2018 •

edited

gehel Mar 1, 2018 •

edited

gehel Mar 1, 2018 •

edited

dgloeckner commented Mar 3, 2018 •

edited

dgloeckner commented Mar 30, 2018 •

edited

dgloeckner Apr 2, 2018 •

edited