Analysis from Jacob Kolind on mailing list

While experimenting with the REQ/REP pattern together with a colleague (see SO post: http://stackoverflow.com/questions/12096192/akka-zeromq-actor-seems-to-be-slow-for-rep-req) we came across some weird behaviour that looks as an error in the design of the ConcurrentSocketActor in akka-zeromq.

The problem with the reply zeromq-actor is that it seems very slow with standard settings (10msg/sec) compared to a similar implementation of a reply-actor in Python (7000msg/sec). Changing the configuration options for akka-zeromq to poll-timeout = 1ms in the application.conf file helps a bit (500msg/sec) as Victor Klang hints at in his comment on the SO post. That is however, still very slow compared to the python implementation.

We hypothesise that the following is wrong when using the ConcurrentSocketActor as a zeromq-reply-actor:
1) Requester sends a message "Hello" on the zeromq channel
2) zeromq-reply-actor receives this message, and sends it onto Listener
3) zeromq-reply-actor starts polling on the zeromq channel, but does not receive anything, and polling times out.
4) In the meantime the Listener handles the message "Hello" and sends back "World" to the zeromq-reply-actor.
5) When the zeromq-reply-actor is done polling on the zeromq-channel it handles the message "World" which it sends to the Requester.
6) The Requester receives the message "World" after a delay determined by the configuration setting poll-timeout.

The error seems to stem from (ConcurrentSocketActor.scala lines 186-189) where polling is resumed directly after handling a message instead of waiting for an answer to the request in the actor-inbox.

https://github.com/akka/akka/pull/679

Updating tickets (#1446, #1269, #1387, #1434, #1436, #1461, #1473, #1603, #1798, #1975, #2035)