Choosing a request handler base class

A request handler may be a direct subclass of one of the JDisc request handler base classes, but there are also base classes available for integrating easier with the Vespa platform. For instance, the base class LoggingRequestHandler does access logging to the Vespa access log, the JDisc API is masked behind a synchronous API and so on.

For the Container, there is nothing special about the different handlers, the application will work as well deploying a pure JDisc handler, be it a subclass of com.yahoo.container.jdisc.ThreadedRequestHandler or a fully independent implementation of the interface com.yahoo.jdisc.handler.RequestHandler. As long as they are built and deployed as other components in the application, they will be instantiated and bound properly by the container framework.

Also, do note, any handler can have arbitrary components injected into its constructor, refer to a HTTP API use case for examples with both arbitrary shared components and the processing handler.

To summarize:

Extend com.yahoo.container.jdisc.LoggingRequestHandler if
  • you want your queries automatically written to the access log
  • you otherwise have requirements as listed for com.yahoo.container.jdisc.ThreadedHttpRequestHandler.
Extend com.yahoo.container.jdisc.ThreadedHttpRequestHandler if
  • you only are implementing an HTTP service
  • you want to use a synchronous API
  • you want an HTTP date header automatically added to the response (if your own code adds a date header, it will not be overwritten, though)
  • you want logging of exceptions (and masking of these from the JDisc layer)
  • you want automatic shutdown when an Error is thrown
  • you want a multi-threaded execution model
Extend com.yahoo.container.jdisc.ThreadedRequestHandler if
  • you want a multi-threaded execution model
  • only use instantiation and configuration from the container
  • you want to use the JDisc I/O API directly
Implement com.yahoo.jdisc.handler.RequestHandler if
  • you want full control over your own execution model
  • only use instantiation and configuration from the container
  • you want to use the JDisc I/O API directly