I understand this reasoning and think it makes sense. To be honest, the
suggestion I made to allow concurrent handlers if the @ThreadSafe annotation
is not very clean.

I think this is a good idea and had it in mind as well. I was a bit
reluctant to do this because it would push some of the concurrency burden
that I could get rid of with Actorom back to the application. But given that
you also suggest to do it this way I will try this.

Actually, I had to ideas how to implement it:

1. The handler class has a concurrent queue as a member and all the handler
method does is push the incoming message into this queue. Then have a number
of worker threads in the handler class that process the queue.

2. In the handler method, create a new Runnable and pass it to the
ExecutorService (very similar to what you do in
OSMessageDispatcher.dispatch).

I prefer solution 2 because it is simpler. The only small doubt I have is
that I have to create a new Runnable for every message. I don't have enough
experience to guess how expensive this will be in practice but I assume it
will be easy to spot in case it really becomes a bottleneck. What do you
think?

Cheers,

Stefan