Skip to content

Use static INSTANCE singleton for stateless HttpServerResponseMutators#18326

Merged
trask merged 5 commits into
open-telemetry:mainfrom
trask:mutators
May 4, 2026
Merged

Use static INSTANCE singleton for stateless HttpServerResponseMutators#18326
trask merged 5 commits into
open-telemetry:mainfrom
trask:mutators

Conversation

@trask

@trask trask commented Apr 26, 2026

Copy link
Copy Markdown
Member

Since they're currently being unnecessarily allocated on the hotpath.

Adds 'static final INSTANCE' field and private constructor to the stateless final-class HttpServerResponseMutator implementations (Grizzly, Helidon, Jetty 8/11/12, Servlet 3) and updates their call sites to use INSTANCE instead of 'new XyzMutator()'. These mutators are invoked from per-response advice / filters / handlers, matching the hot-path exception in general-rules.md ('Prefer Instance Creation Over Singletons'). This also brings them in line with the existing enum-singleton mutators (Armeria, JavaHttpServer, Netty 3.8/4.0/4.1, Tomcat 10, Restlet 1/2, Undertow) and the static-INSTANCE mutators (Tomcat 7, Servlet 2.2). Akka and Pekko mutators are intentionally left unchanged because they hold per-request header state.
@trask trask marked this pull request as ready for review April 26, 2026 23:57
@trask trask requested a review from a team as a code owner April 26, 2026 23:57

public class GrizzlyHttpResponseMutator implements HttpServerResponseMutator<HttpResponsePacket> {

public static final GrizzlyHttpResponseMutator INSTANCE = new GrizzlyHttpResponseMutator();

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could consider using the enum singleton as it is more compact, a bunch of HttpServerResponseMutators already use it

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, makes sense

it would be nice to have a consistent story for when / whether we use enum singleton pattern

I did a quick check and looks like we have pretty even split of enum singleton INSTANCE to class singleton INSTANCE.

I'm good with any range of never to always or something in the middle

maybe just embrace them? (except maybe for public library classes in order to preserve flexibility)

trask added 3 commits May 2, 2026 15:01
# Conflicts:
#	instrumentation/servlet/servlet-3.0/javaagent/src/main/java/io/opentelemetry/javaagent/instrumentation/servlet/v3_0/Servlet3HttpServerResponseMutator.java
@trask trask enabled auto-merge (squash) May 4, 2026 02:56
@trask trask merged commit c2d057e into open-telemetry:main May 4, 2026
92 checks passed
@trask trask deleted the mutators branch May 4, 2026 03:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants