RFR : JDK-8170299 - Debugger does not stop inside the low memory notifications code
Sundararajan Athijegannathan
sundararajan.athijegannathan at oracle.com
Fri Aug 24 15:14:15 UTC 2018
+1. It is better not to fix this bug.
-Sundar
On 24/08/18, 7:36 PM, 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?
>
> best regards,
>
> -- daniel
More information about the serviceability-dev
mailing list