It make JFR Event Streaming asynchronously with try-catch-resources more understandable

[Erik Gahlin]

> On 16 Feb 2020, at 16:21, Chihiro Ito <chiroito107 at gmail.com> wrote:
> 
> Hi Erik,
> 
> Thanks for the quick response.
> 
> My offer is just output a log. I think we need not change the current implementation.
> When users to use JFR Event Streaming with try-catch-resources, It is too difficult for the user to understand why JFR Event Streaming is stopped after running try-catch-resources.

This seems to me what one would expect. If you do:

try (Recording r = new Recording()) {
  r.start();
}

the recording is also stopped when it is closed.

The is also what happens if you close a java.util.concurrent.SubmissionPublisher.

> For this reason,  if the user runs JFR Event Streaming asynchronously and when being called close() method as AutoClosable,  JFR Event Streaming will be stopped.
> When I had tried to use JFR Event Streaming with try-catch-resources, I hard to find this cause why it is stopped.
> If we implement to output that for example "JFR Event Streaming on async will be stopped" like a log message, the user easy to find the cause of stopping.

The behaviour is not unique for an async stream, so the log message must be “Event stream stopped”, or similar. 

There is a log message that says the stream has ended if you run with -Xlog:jfr-event+streaming=debug. That said, it's unlikely users will have JFR logging enabled, so it will most likely not help. 

I rather update the javadoc to make this more clear. Today it says:

/**
 * Releases all resources associated with this stream.
 * <p>
 * Closing a previously closed stream has no effect.
 */ 

Erik

> 
> Regards,
> Chihiro
> 
> 2020年2月16日(日) 23:29 Erik Gahlin <erik.gahlin at oracle.com <mailto:erik.gahlin at oracle.com>>:
> Hi Chihiro, 
> 
> Thanks for providing feedback.
> 
> When the RecordingStream is closed the underlying recording is stopped/closed, so no more data will be produced from that point on. Events are read in batches from disk, once every second, and a check if the stream is closed is done once per batch. One benefit with this behavior is that the application will get all the information in that window. For example, if you subscribe to a periodic event like ThreadAllocationStatistic you will get events for all threads.
> 
> We did consider to block in the close method until a batch has been sent out, but it could lead to applications blocking for an unreasonable amount time, for example if I/O is carried out in the callback.
> 
> Could you describe the use case when the stream not being stopped immediately is an issue? What problem does it cause?
> 
> Thanks
> Erik
> 
> > On 16 Feb 2020, at 13:29, Chihiro Ito <chiroito107 at gmail.com <mailto:chiroito107 at gmail.com>> wrote:
> > 
> > Hi,
> > 
> > I tried to use JFR Event Streaming asynchronously. When I use it with
> > try-catch-resource as the following code [1], It doesn't work. However, It
> > seems normal behavior.
> > This reason is that RecordingStream is auto closed.  I think when it is
> > called the close method, JFR and JFR Event Streaming should be stoped. But
> > It is difficult for the user to aware of why it doesn't work.
> > Why don't we output the log message for the async user as following [2].
> > 
> > What do you think, everyone?
> > 
> > I already implemented this and it seems fine.
> > 
> > [1]
> > public class JfrEventStreamingInProcessAsync {
> >    public static void main(String[] args) throws Exception {
> > 
> >        Configuration config = Configuration.getConfiguration("default");
> > 
> >        try (EventStream es = new RecordingStream(config)) {
> > 
> >            es.onEvent("jdk.CPULoad", System.out::println);
> >            es.startAsync();
> >        }
> > 
> >        TimeUnit.HOURS.sleep(1);
> >    }
> > }
> > 
> > [2]
> > 
> > JFR Event streaming is running asynchronously, but it has been closed. It
> > will be terminated immediately.
> > 
> > Regards,
> > Chihiro
>