[concurrency-interest] actor frameworks

Osvaldo Pinali Doederlein osvaldo at visionnaire.com.br
Fri Mar 6 08:31:37 EST 2009

Em 06/03/2009 00:40, David Walend escreveu:
> 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.)
Well, this is not so remarkable considering that JMS provides you a 
simple, weakly-typed data representation: a message is just a Map of 
headers (with a very short selection of types) plus a payload that's a 
simple blob (well, you can choose a binary blog and a text blob!). On 
top of that, JMS doesn't give you easy/standard access to the massive 
complexity of the middleware - look for instance the configuration of a 
IBM WebSphere MQ's queue manager and its queues, there is a bewildering 
number of properties, configurations and facilities for monitoring, 
routing etc.

But I have written massive JMS applications (for banking - what else?) 
and I never needed programmatic access to any feature that's not exposed 
by JMS. I only needed static configs that could be performed on the 
messaging server and/or the application server. This is a big 
difference; when dealing with a DBMS, I typically need dynamic access to 
all sorts of advanced features, so I either use an up-to-date JDBC 
driver with specific APIs, or I'm forced through DBMS-proprietary driver 
APIs or proprietary SQL extensions (at least, good ORM tools will do 
that for me most of the time).

My verdict is that JMS is really a very well designed API, kudos again 
to its authors, but it's a much more tractable domain that say JDBC/RDBMS...

> Dave
>> 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
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>> End of Concurrency-interest Digest, Vol 50, Issue 5
>> ***************************************************
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Osvaldo Pinali Doederlein                        Visionnaire Virtus S/A
osvaldo at visionnaire.com.br                http://www.visionnaire.com.br
Arquiteto de Tecnologia                          +55 (41) 337-1000 #226

More information about the Concurrency-interest mailing list