[concurrency-interest] Re: Concurrency Utilities in Practice

David Walend david@walend.net
Tue, 25 Nov 2003 14:12:07 -0500

Thanks for the plug, Tim. You're not oversimplifying. SomnifugiJMS is 
dl.u.c Channels in JMS clothing.

Jonathan Simon and I proposed a Threading in Swing technical session 
where we want to show a spectrum of solutions: running within the awt 
Thread, using invokeLater(), spinning up worker Threads, putting work in 
j.u.c queues with threaded feeders bound to slower resources, using 
SomnifugiJMS queues, and using SomnifugiJMS topics. Different solutions 
hit different scales and different developer skills. Jonathan and I want 
to focus on Swing in particular, so our talk might make a good companion 
talk. (Assuming we get to do it. You can always revisit the outline for 
your talk after we all hear back. And I put in a BoF proposal for code 
generation, with some examples from SomnifugiJMS. I could always squeeze 
it in there if your BoF fills up.)

My own (hugely biased) take on using raw j.u.c for work queues vs a fast 
JMS: If there's N or fewer queues in the system, no topics, and amazing 
developers who don't know JMS but do know j.u.c, use j.u.c queues. 
Otherwise, use a fast JMS. I think for most projects, N will be about 3 
before the overhead to manage the queues exceeds the overhead to use a 
JMS implementation. It's about the point where you build a central 
manager for the queues. For me, N is 1. (I know JMS well. dl.u.c just 
fits between my ears, and this list is mental yoga for me. YMMV.)

I hope that adds something,



From: Tim Peierls <tim@peierls.net>
To: Claude Hussenet <chussenet@yahoo.com>
CC: concurrency-interest@altair.cs.oswego.edu
Subject: Re: [concurrency-interest] Concurrency Utilities in Practice

Claude Hussenet wrote:

>> We're the concurrent package as a way to process simultaneous 
>> request to the backend in an asynchronous fashion. ... We found 
>> the concurrent package an an alternative to the JMS API which 
>> usually require a J2EE container.

Have you considered Dave Walend's SomnifugiJMS? It is essentially 
a JMS wrapper around the concurrency utilities (forgive me, Dave, 
if I oversimplify).


It would be nice to get a feeling for how to decide between JMS-style 
designs and the direct use of the concurrency utilities. If we had all 
the time in the world, I'd love to present things in this order:

  1) a j.u.c implementation of SomnifugiJMS
  2) an example of asynch request processing using 1)
  3) an example of asynch request processing using "raw" j.u.c
     (as in Claude's financial site)

But we don't have much time. As interesting as all of this is, I think 
our first priority is breadth of application of the concurrency utilities. 


David Walend