On 8/24/18 7:06 AM, Daniel Fuchs wrote:
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?
I agree that this is a behavioral change but I suspect this is not high
compatibility risk
though (no data though). I understand David's concern that this is to
fix a debugger
issue and we should investigate other alternatives to minimize the
compatibility risk.
The other approach David has proposed is to investigate if we can make
the service thread
not hidden. The threading model in the notification listener
invocation remains unchanged.
In addition, the VM service thread also handles DCMD and JVM TI
callbacks. I don't know
if there are public API to register DCMD callback. If so, it will
enable debugging
user-defined DCMD callback for free then. The notion of hidden VM
JavaThread was added
to avoid a compiler thread and other system thread being suspended and
resumed
(see JDK-4529296). So we should be careful and look into past issues
to make the
VM thread visible to debugger. It may be a feasible solution.
In any case, it would be useful to clarify the spec w.r.t. the
synchronization and threads
invoking the listeners and users should prepare the listeners may be
invoked
asynchronously in parallel.
Mandy
