Class StateTrackingHandler

java.lang.Object
org.eclipse.jetty.util.component.AbstractLifeCycle
org.eclipse.jetty.util.component.ContainerLifeCycle
All Implemented Interfaces:
Handler, Handler.Container, Handler.Singleton, Request.Handler, org.eclipse.jetty.util.component.Container, org.eclipse.jetty.util.component.Destroyable, org.eclipse.jetty.util.component.Dumpable, org.eclipse.jetty.util.component.Dumpable.DumpableContainer, org.eclipse.jetty.util.component.LifeCycle, org.eclipse.jetty.util.thread.Invocable

@ManagedObject public class StateTrackingHandler extends Handler.Wrapper

A troubleshooting Handler.Wrapper that tracks whether Handler/Request/Response asynchronous APIs are properly used by applications.

The violation of these tracked APIs are reported to a StateTrackingHandler.Listener instance; the default listener implementation emits warning logs.

StateTrackingHandler can be linked in at any point in the Handler chain, and even be present in multiple instances, likely configured differently.

For example, to troubleshoot wrong usages of the callback passed to method handle(Request, Response, Callback), a StateTrackingHandler should be configured as the outermost Handler. This is because the handle(...) call propagates inwards. In this way, StateTrackingHandler can wrap the callback passed to inner Handlers and verify that it is eventually completed.

On the other hand, to troubleshoot custom Handler implementations that perform wrapping of Response.write(boolean, ByteBuffer, Callback), a StateTrackingHandler should be configured after the custom Handler implementation. This is because the write(...) call propagates outwards. In this way, StateTrackingHandler can wrap the write(...) call before forwarding it to outer Handlers and eventually to the Jetty implementation, and verify that it is eventually completed.

See Also: