Simple TCP Server using Dropwizard

[MLnick]

Hi

I know Dropwizard is mostly focused around HTTP webservices. However, I'm looking at putting together a service that initially will be mostly for internal use (e.g. centralised logging system), but that over time may also add either HTTP / REST based features internally, or possibly become a fully-fledged external web service.

Initially what I need is to run a pretty standard simple TCP listener service, but one that hopefully can also scale to the 5-10k requests per sec level. We don't want to use HTTP because we're expecting massive data flow through the service as things scale up.

What really interests me about using Dropwizard is it's ease of quick out-of-the-box development, health checks, easy monitoring etc. I'd like to use these features instead of having to roll my own stuff via Jetty, vertx, netty or whatever.

Is there an easy way to achieve this without serious alteration of the framework, and while still being able to keep the benefits of DW?

Thanks

Nick

[Nick Telford]

We use Dropwizard for several services that don't expose an HTTP API (aside from Dropwizard's Admin UI); notably, several services powered by Apache Kafka. We do this for the same reason you highlighted: Dropwizard provides a bunch of useful wiring abstractions that make bootstrapping and deploying a service quick and simple.

To my knowledge, DW doesn't currently have a generalized "TCP server" module, so you'll probably need to code that part of your application yourself. Given the broad nature of such a server, I'm not sure that such an abstraction would even be useful.

Your best bet is probably to build yourself a Netty server and integrate it with DW by writing HealthChecks and instrumenting it with Metrics. You might find DW's ExecutorServiceManager useful for integrating Netty's lifecycle with that of Dropwizard.

Regards,

Nick Telford

[MLnick]

So if I understand correctly, I'd in theory simply use DW to manage lifecycle, and hand off to a thread (/pool) that would run the other server. So essentially DW would then provide the health check, admin interface and commands etc.

So it would be something like:

    @Override

    protected void initialize(TestConfiguration configuration,

                              Environment environment) {

        final String template = configuration.getTemplate();

        final String defaultName = configuration.getDefaultName();

        ExecutorService es = environment.managedExecutorService("test-thread-%d", 10, 20, 10, TimeUnit.SECONDS);

        environment.addResource(new TestResource(template, defaultName));

        environment.addHealthCheck(new TemplateHealthCheck(template));

        

        es.execute(new Runnable() {

public void run() {

System.out.println("hello world from a thread");

}

});

    }

Or is it better to use the Managed approach:

environment.manage(managedTcpServer);

and have the server implement it's logic in start()/ stop().

Or finally, it seems like one could implement a Command, similar to the server command, in fact just add another "tcpServer.start()" to the ServerCommand#run() method?

It's not clear to me exactly which approach is most in keeping with the framework and will best allow full use of the healthchecks and metrics etc? Seems to me implementing in Service#initialize() may be the best way?

[Coda Hale]

I'd suggest writing a Managed wrapper for whatever server
implementation you end up using.

You can either just provide a dummy resource which returns a 404 to
make Jersey happy, or you can flesh out an admin/management API for
the service.

It's a fairly common pattern for DW services which aren't all HTTP.

--
Coda Hale
http://codahale.com

[Nick Pentreath]

Great, thanks for the guidance. Will give it a go.