I'm working out some complicated details related to sunsetting the current metrics and tracing code and replacing it with something modern and well supported. Doing that and maintaining some semblance of backwards compatibility is a challenge.

We're also investigating whether a Netty-based integration is justified. Netty is more complicated to work with than Jetty, but may be able to yield higher throughput, especially when some work in asynchronous.

There's also a bit of Pedestal that has never been well documented or tested; I don't like to take on more than I can maintain.

Netty - wow! That sounds like a year's work, actually.

Very curious what problem adding a dependency on Netty would be solving.

There are alternatives: ex with loom that could make it easier to maintain that introducing netty + deeper async

That would be a good bet for the future, as jvm internals get modified to make arbitrary code more loom "compatible"

Lastly for tracing, loom means you can just leverage automatic instrumentation via java agent (for instance from opentelemetry) and also not have to build you own abstractions to work-around tracing support across (arbitrary) async operations (trace/spans propagation etc, been there, done that, not fun).

yup ^. would prefer pedestal integration for helidon nima and not netty

wondering if there’s still cases where you’d reach for async pedestal (returning a channel) if it was integrated with nima?

I guess it would just be other libraries that haven't been updated to use loom

returning a channel is a mechanism for relinquishing the thread while work happens in the background, because platform threads are precious

virtual threads are not precious

right. So if I that aspect of pedestal wouldn’t make sense in that context anymore it probably offers some nice possibilities to simplify. Less so if backwards compatibility needs to be maintained.

you know where we stand on backwards compat 🙂

yes, I’m contemplating if it should get a new name then 🙃

also wondering how much of pedestal’s design was driven by the desire to unify sync & async requests. But it sounds like you’d want to reach for interceptors with loom, right @ghadi?

Interceptors would not really change, especially if c.async support remains