<> I am assuming that you have compiled and are running each of the the Controller app and the Plant app (they communicate message objects over a blocking socket). I am assuming that communication has been established between the two apps. (*) From here on in, the Plant should constantly be printing event actions to the Plant console, irrespective of what actions or messages you send on the Controller app. This is because each Plant event runs in its own thread and communication is set up in such a way that communication actions cannot block Plant events forever. The problem is that when you enter a 0, 1, 2 or 3 message at the Controller side, the Plant events eventually stop firing. (**) I have checked the same design sending strings instead of objects across the socket. The desired ongoing Plant event firing is observed. My conclusion is that there is some issue with respect to sending objects (via STORABLE) across sockets! This is because (**) is the same design as (*) except for the type of message. For strings (design **) we don't need STORABLE---the socket just supports strings out of the box. For objects (design *)--we see the unexpected behavior that the Plant events eventually block. After the Controller sends a message, it seems that those events that are sleeping--wake up and fire, but are then somehow prohibited from being taken again. This should not happen. The Plant console should be on the move, constantly as in design (**).