[concurrency-interest] actor frameworks
gregg at cytetech.com
Fri Mar 6 10:09:42 EST 2009
One the simplest strategies for eliminating context switches between senders and
receivers, is to have sender call into receiver's listener. If Kilim code
weaving works, this will work as well. More importantly, the listener, who
actually knows how expensive 'his' task is, can dispatch into thread pools or do
other per message optimizations so that throttling of incomming load, due to
messages, can be managed.
The Kilim weaving looks interesting. Look at the old ObjectStore database,
which did code weaving to implement persistence of objects, automatically. In
the end, it didn't really survive as a useful detail, because of several issues.
One of those was, of course, the fact that you had to license it. But, it was
also a little painful for general reuse because of the multi-step compilation
and management of the overall build of any package needing it.
I've been using the same "Space" with sender-calls-subscriber implementation for
many years, and it's never been the performance bottle neck of my broker.
David Walend wrote:
> On Mar 5, 2009, at 12:00 PM, concurrency-interest-request at cs.oswego.edu
>> I think Scala's is mature enough that I'd plan a production app on it
>> (with caveats for early perf testing).
> Whenever I look at actors, I see the message queues I first saw in big
> banks 15 years ago. They'd been there longer. I was what was new. They
> work great, provide a good trade space between speed and reliability.
> The most common patterns to use are either Actors or Events. When you
> say Actor I hear MessageListener.
> The only big change with message queues was their unification of API via
> the JMS spec in 1999. The JMS spec itself is pretty remarkable -- almost
> eight years without even a minor revision, and no major revision in ten
> years. (Compare that to the arms race that is JDBC.)
>> I would want to thrash the others more first. Kilim does compile-time
>> weaving which I find to be a pain from a tooling point of view,
>> regardless of whether it works. I'm not sure whether any of the Java
>> frameworks have been tested much if at all on big multi-core
>> machines. I'm hoping to grab a few cycles to try them at work if we
>> have a machine free. From the small benchmarking I've done in the
>> past and that I've read from others, the basics like message send are
>> very fast, in the same general order of magnitude with Erlang. It's
>> really hard to tell how good the scheduling and other critical parts
>> are though without really building an app-level benchmark.
>> ----- Original Message ----
>> From: Raoul Duke <raould at gmail.com>
>> To: Alex Miller <alexdmiller at yahoo.com>
>> Cc: concurrency-interest at cs.oswego.edu
>> Sent: Wednesday, March 4, 2009 1:10:18 PM
>> Subject: Re: [concurrency-interest] actor frameworks
>>> Lots of options these days.
>> yeah, but the question is, which ones are actually robust? :-)
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> End of Concurrency-interest Digest, Vol 50, Issue 5
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest