Lazy Events

[Erik Gahlin]

Hello, 

The recommended way today is to add fields. i.e.

class MyEvent |
   @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH)
   long  timestamp;
   Thread thread;
}

The “eventThread” field is meant for the thread which the event was committed in. 

We are aware that JFR could be used as a storage backend where timestamps, stack trace, event thread etc. could come from a different system, but we aren’t sure the JFR consumer API and/or the JFR file format should be that system. It could be that this is better handled by third party libraries where JFR events can be pushed into those systems using event streaming. I understand that JFR may be able to store data more efficiently, but one reason for today’s efficiency (and tomorrow’s) are the limitations that JFR imposes, for example, the stack trace is taken in the commit method and users don’t have access to the clock source.

If we would make JFR a generic backend, it would require a larger redesign.

Best regards,
Erik

> On 24 Aug 2020, at 08:15, Michael Bien <mbien42 at gmail.com> wrote:
> 
> Hello,
> 
> I was wondering if it was ever considered to implement lazy evaluation of event attributes?
> 
> commit() must happen close to the time the event happens since it stores the time and thread id. Instead of storing all fields on commit using the client Thread, JFR could potentially append additional fields by calling event methods before its written to the repository on the JFR Thread.
> 
> class LazyEvent extends Event {
> 
>     @Label("Normal Field")
>    String msg1;  // taken on commit()
> 
>    @Lazy
>    @Label("Lazy Field")
>    String msg2() { return /** called by JFR thread before its written to repo **/; }
> 
> }
> 
> Another (simpler) way to allow the same functionality could be a Event::writeHeader() which would only store eventThread + startTime/duration values, while the actual Event::commit() would store the fields without altering the exiting event "header" and could be called from a different thread later.
> 
> I am mostly asking since I wrote a tiny library called JFRLog[1] which lets you log directly to JFR records using normal logging APIs. While a traditional logger impl can be usually configured to do potentially expensive stuff like message formatting or calling toString() on objects asynchronously (e.g the Thread which writes the message to a file could do this), JFRLog has to do everything in the caller Thread before event.commit(). If i would try to put that into its own thread, the eventThread IDs and startTime would be all wrong.
> 
> 
> its mostly just a thought i got while writing the lib - the performance is sufficient for my needs, I avoid using complex log msgs anyway which makes it just as fast as loggers which format in their own Threads. JFR does all the heavy lifting anyway.
> 
> best regards,
> 
> michael
> 
> ps: thank you for the flush-interval flag :)
> 
> 
> [1] https://mbien.dev/blog/entry/jfrlog-logging-directly-to-the
>