laforge49 / pamailbox Goto Github PK

To eliminate the need to have multiple MailboxFactories, one for each "group of actors" with different "threading needs", in particular used, to limit how many thread each of those groups get to do their work, we have decided to add a second thread-pool to the MailboxFactory, which should be good enough for 99% of the use-cases.

The idea is that we create one thread-pool, where the size is equivalent to the number of processors (Runtime.getRuntime().availableProcessors(), usually +1, to account for the occasional unplanned blocking). This is for the normal, non-blocking, messages,

Then we have a second thread-pool, for the blocking calls. The size of this thread-pool is then user-specified, as it varies a lot between applications.

The big questions are:

1. How we identify which messages to process in which pool?
2. What to do with mixed messages, where some would need to be processed in one pools, and some in an other.

I think Bills suggested we control the behavior by fixing the pool choice in the Mailbox itself. This solves both problems, but is a rather "coarse-grained".

The discussion about timers reminded me of java.util.Timer. I think something like that is essential to an Actor API. Maybe we can extract it from Project Harmony, and turn it into one of our API classes?

To harden the API, as much as is possible, we could add assert statements that call some "test-class", built to throw random exceptions, in a configured way. The idea is that with the assertion disabled, as is expected for production code, this would be totally eliminated at runtime, and cost no resources. But when activated, would cause "random exceptions" to be thrown, in most possible places, allowing us to truly test the exception handling, and check that no request, response or exception gets totally lost. Failure is always possible, but it should be documented, and the goal is that the end-user knows what to expect, with regards to what can go wrong where, and what will happen when it goes wrong.

Implement commandeering, similar to how it is done in JActors.

An optional timer on non-blocking mailboxes to ensure that all messages are processed in less than 1 millisecond.

Following the discovery of the much faster 1-to-1 non-blocking queues, we are now looking how to put those to good use, to improve performance, but without compromising on the current API. Bill suggest we had a new method in Mailbox (not MailboxFactory) that creates a "port" for "direct messaging" from one specific MB to another specific MB. This would allow the actors to have "normal" Mailboxes, but at the same time achieve much faster exchange between specific MB that have a lot of exchanges to do.

How to go about implementing this is not clear yet (at lest not clear to me).