Question

I need to implement an application that is simultaneously communicating with multiple clients using a (bidirectional) request-response protocol. Previously I have implemented this using two dedicated threads for each client (one reader/reactor and one writer/initiator). The problem with this is that the thread management became quite complex and ugly. Is there any standard way of handling this, possibly even with just one thread, or at least a constant amount of threads for handling all of the clients?

This is sort of how some communication would look in a thread with the blocking implementation:

Command response = request("cmd1", "a", "b");
if(!response.is("OK")) {
    return;
}
response = request("cmd2", "c");
if(!response.is("OK")) {
    return;
}
response = request("cmd3");

Between sending the request and awaiting the corresponding response I would like for the current thread to be able to do other work, but then continue execution once the response actually arrives.

I know that it could be possible to use asynchronious IO and register Java Future/Runnable instances to run once the response for the request is received, but this easily turns into a multi-level nesting of anonymous Runnable subclasses and I suspect that it will be more pain then it is worth. This would probably result in something like the sample below, which quickly becomes highly nested and unreadable. Surely there must be an easier way?

request("cmd1", "a", "b", new ResponseHandler() {
    public void response(Command response) {
        if(response.is("OK")) {
            request("cmd2", "c", new ResponseHandler() {
                public void response(Command response) {
                    if(response.is("OK")) {
                        request("cmd3", new NullResponseHandler());
                    }
                }});
        }
    }});

I have also considered the possibility of using a dedicated Actor framework to handle the request-response logic. While they look like they could help in this situation I have never worked with such frameworks before so I do not know if they are appropriate for this situation.

In short, my question is: How do I handle an arbitrary amount of request-response connections in a non-blocking way so that a constant amount of threads is sufficient? Are Actor frameworks a valid approach?

PS. I am using Java for this project.

Answer 1

I think this should be quite simple using some Java NIO framework like e.g. netty. Haven’t used an Actor framework so no idea if that wouldn’t be a better fit though.

Basically you create one class that handles the whole communication and stores the necessary information – the framework handles the whole threading in the background you just provide a method for e.g. messageReceived and handle it there.

The downside is, that you have to basically write your own state machine which may not be that simple – but it’s certainly the easiest way to use NIO.

Example:

enum State {
    S0, S1
}
private State state = State.S0;
public void messageReceived(
        ChannelHandlerContext ctx, MessageEvent e) {
    switch(state) {
    case S0:
        // read object from channel and write appropriate response
        e.getChannel().write("HELO");  // writes are asynchronous 
        state = State.S1;
        break;
    case S1:
        // same as S0
        e.getChannel().write("DONE");
        break;
    }
}

Note that reading the netty tutorial is still absolutely necessary, because there are things about NIO that aren’t self explaining (at least they weren’t for me). But there are several examples that are easy to work through which should teach you the basics.