RFR : JDK-8170299 - Debugger does not stop inside the low memory notifications code

Daniel Fuchs daniel.fuchs at oracle.com
Fri Aug 24 14:06:31 UTC 2018


Hi Harsha,

On 23/08/2018 17:35, Daniel Fuchs wrote:
> So all in all - maybe this is worth fixing but better early
> in the release than late. I also wonder whether such a behavior
> change should deserve a release note (or a switch to revert
> to the old behavior - though I do hope that isn't necessary).

On second thought - it occurred to me that what you are proposing
to do in the platform could very well be implemented in the
client (listener) code instead.

The workaround would be simple:

-------------------------------
package com.foo.monitoring;

import javax.management.*;

final class PlatformMXBeaNotificationListener implements
       NotificationListener {

     private final NotoificationListener delegate;

     PlatformMXBeaNotificationListener(NotoificationListener delegate) {
	this.delegate = delegate;
     }

     public void handleNotification(Notification notification,
                                    Object handback) {
          executor.execute(() ->
                delegate.handleNotification(notification, handback));
     }

     private static final Executor executor
           = Executors.newSingleTreadExecutor();
}
--------------------------------

This way the threading would remain in control of the
client application, and the debugger would be able to
step in the delegate's handleNotification(...) method?

Given the unquantifiable risk posed by changing the threading
model in the platform, then maybe leaving the current
implementation as is and documenting that workaround
leaving it up to the client code to decide whether to use
that or not, would be the better idea?

best regards,

-- daniel


More information about the serviceability-dev mailing list