I'm working on an application that is supposed to serve as an adapter
to a 3rd party product. The communication to the latter happens with
ASCII messages over TCP/IP and I found that dispatching the incoming
messages to their handlers seems like a good case to try Actorom. It
actually works very good, I hardly had to restructure the application
and could get rid of a lot of code. So thanks for that :)

I chose the OS threads over the green threads to allow for more
concurrency between the processing of the different message types I'm
getting from the 3rd party app (i.e. there is one separate actor for
most of the message types I need to handle).

However, since the OSMessageDispatcher ensures that messages handled
by the same actor run sequentially I have some worries when the
handler takes longer (I need to parse potentially big ASCII message,
for example) than the inter arrival time of its messages.
If I understand the actors model correctly, this is to ensure that the
actor does not need to worry about synchronization. However, if the
handler is state less, it seems like it should be no problem for this
actor to accept messages concurrently.

What is your thought on this? Do you discourage this upfront or do you
think it could make sense?

I was thinking to implement a MessageDispatcher myself that does the
same thing as the OSMessageDispatcher but allowing concurrent handling
on the same actor if it has the @ThreadSafe annotation.

Thanks,

Stefan