Augment JFR Socket Events

[Elliot Barlas]

Thanks for the reply, Erik.

I'm surprised that extracting local host and port details would be prohibitvely expensive since that's exactly what is already happening for the remote side.

As you mentioned, the only​ way to correlate socket events is with a thread ID. That's incredibly limiting.

The standard way to describe a TCP connection is with a pair of IPs and ports. I would intuitively expect the JFR events to reflect this.

In my case, I'm trying to profile a server application that is making HTTP calls to other server applications. I'm trying to pair application logs with JFR events. I can correlate an application log entry with a JFR entry based on time, but unfortunately, I can't make any claims about which​ connections are actually being used by application transactions, since I don't have adequate information (local IP, port) in JFR events. I can't pair the JFR events with a packet capture for the same reason.
________________________________
From: Erik Gahlin <erik.gahlin at oracle.com>
Sent: Tuesday, March 7, 2023 9:55 AM
To: Elliot Barlas <elliot.barlas at goto.com>; hotspot-jfr-dev at openjdk.org <hotspot-jfr-dev at openjdk.org>
Subject: Re: Augment JFR Socket Events

Aditional fields might introduce overhead. I would expect, but I could be wrong, that local host is the same in most applications and that the local port is not set by the user, which makes it hard to map to program logic?

I wonder if the existing event thread or the stack trace could be used to separate concurrent connection in your use case? Perhaps a virtual thread per connection task could provide the context?

Thanks
Erik

________________________________
From: hotspot-jfr-dev <hotspot-jfr-dev-retn at openjdk.org> on behalf of Elliot Barlas <elliot.barlas at goto.com>
Sent: Monday, March 6, 2023 6:47 AM
To: hotspot-jfr-dev at openjdk.org <hotspot-jfr-dev at openjdk.org>
Subject: Augment JFR Socket Events

The JFR SocketReadEvent and SocketWriteEvent classes include remote host, remote address, and remote port fields.

The absence of corresponding local host and port fields makes these events much less valueable. In a setting with many concurrent connections to the same target from a particular host, it can be very difficult to associate an event with a particular connection. There just isn't enough context.

Is it possible to extend the events to include that information? Is that something I can contribute?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-jfr-dev/attachments/20230307/f44f8bdb/attachment.htm>