What appears below all-out wins the award for the nastiest, most evil code I've ever written that appears in a production system.
resp = ReflectionUtils.unwrapResponse(resp);
if (resp instanceof ResponseFacade rf) {
try {
// Drill through Tomcat internals using reflection to get to the underlying socket and SHUT it down hard.
NioEndpoint.NioSocketWrapper w =
ReflectionUtils.getField(rf, "response.coyoteResponse.hook.socketWrapper", NioEndpoint.NioSocketWrapper.class);
ReflectionUtils.attempt(() -> w.getSocket().getIOChannel().shutdownInput());
ReflectionUtils.attempt(() -> w.getSocket().getIOChannel().shutdownOutput());
} catch (Exception e) {
log.warn("Cannot access socket: {}", e);
}
} else {
throw new RuntimeException("Simulated Socket Reset", new SocketException("Connection Reset [simulated]"));
}
It is used for a mock endpoint developed to performance test an application that sends messages to other systems. The purpose of this is to force a reset on the server socket being used to response to a request. The mock endpoint receives a request, and randomly shuts down the socket to help test the resilience and performance of the main application.
This delves deeply into Tomcat internals and uses a few reflection utility functions that I wrote.
The unwrapResponse() function just gets to the inner most HttpServletResponse assuming that is the beast that is closed to Tomcat internals (in my case, it is).
public static HttpServletResponse unwrapResponse(HttpServletResponse servletResp) {
return ((servletResp instanceof HttpServletResponseWrapper w) ?
unwrapResponse((HttpServletResponse)w.getResponse()) : servletResp);
}
The getField() method breaks the string given as the second argument into parts around the period (.) character, and then recursively extracts the object at that field, returning it. The last argument is the type of the object. I'll leave this one as an exercise for the reader. These lines of code First get the socket from socket wrapper of the action hook in the CoyoteResponse of the Response object that's backing the outermost HttpServletResponse object given in resp.
The attempt() method just calls the callable (which is allowed to throw an exception), and returns, regardless of whether or not the attempt succeeds. This is because I don't want this code to fail.What's inside that callable is the critical code. That uses the socketWrapper to get the NIOChannel, and force a shutdown on both sides of the socket. This is the hardest I can crash an inbound connection without messing with operating system calls, and it works in Tomcat 8.5, and I'm pretty certain it will work in Tomcat 10 as well. I'll know in a couple of days once I get done migrating.
This is truly evil code; however, it wouldn't exist without a purpose. That is to test how the system responds when a socket goes randomly belly-up during a performance test. Yes, this code is randomly triggered during performance testing whilst the application is attempting to make requests. As much as possible, I've basically installed a robot walking through the server room and randomly pulling cables from the endpoint the application is trying to get to, without having any access to that room or the cables.
This is basically the code that it getting invoked by this ugliness (that link is for Java 8, I'm actually using JDK 17 and previously used JDK11). You might find this technique useful yourself. I find it's a lot better than having to pull my wired connection a dozen or more times for my weekly performance test. Yes, this runs in a scheduled automated test at least once a week.