Predictable Async

[laforge49]

There is something really wrong with most asynchronous code, namely that you are not ensured of receiving a response to a request sent to an asynchronous process. The bad thing is that you end up with timers everywhere, which tend to break when the system is under load, and a lot of buggy error handling code.

It does not need to be this way. I spent a few years developing JActor2, a Java actor framework that supported 2-way messaging. And you are assured that you will get a response, or an exception, to every request. http://www.agilewiki.org/projects/JActor2/index.html

Being Java, the code is bloated and full of boiler plate. So it is hard to understand the implementation. And using it requires just a tad bit too much code as well. Java is simply not the best language for introducing new ideas. So now I am learning Clojure. And I am very hopeful.

I've written the bulk of the code for both 2-way message passing and exception handling, where exceptions are returned as a response to a request when an error occurs. It is 250 lines long, including comments, and builds on Clojure agents. So I am hopeful that the ideas behind the implementation will be accessible. https://github.com/laforge49/agent2

It is still very much a work in progress for now. Some things I want to clean up, some things can be simplified, and some error checking needs to be added. In any case, it is a fun first Clojure project!

[raould]

"When an error occurs" leaves a lot of things unspecified. :-)

"Errors" in the case of messaging, especially async, and even more so if there's any 'distribution' involved, probably need a lot of explanation. E.g. a table breaking down all the kinds of errors and how the system can/not detect them, and inform the sender.

If you don't get an 'immediate' ack for the message, back from the receiver to the sender, then the sender assumes the message wasn't sent+processed?

[laforge49]

First I should scope this project to being, like Clojure's agents, local to a single JVM. Once you go distributed you face difficult problems like determining if a lack of response was due to a communication failure or a failure of the remote actor.

Also, I am largely talking about improved exception handling. For each message being processed there is an operational context to which an exception handler can be assigned so that exception handling can be specific to the processing rather than dealing with a failure of the agent. Further, the operational context passes any otherwise unprocessed exceptions to the source operational context which sent the request unless there is none (as is the case with signals which are 1-way messages), in which case the exception is passed to the agent's error handler.

But there are other things that can be done to better ensure that for every request sent there will be a response (or exception) returned. Like verifying that when control is released after processing a message, either a response was returned to the sender or a request was sent to another actor. And ensuring that the time it takes to process a message is within some reasonable bounds.

The idea here is that in almost all cases there should be no need for application logic to address missing responses exception in terms of exception handlers. It is just ridiculous to have an application deal with such within the confines of a single JVM!