Hi Lew,
This is why I asked about your use case. Not all use cases call for queues, otherwise every single program would always use them. No?
it's about developing a little actor framework (see
http://en.wikipedia.org/wiki/Actor_model) with distributed actors
connected through some means to exchange messages through the wire.
Actors are active objects, e.g. objects that run in their own thread
(to prevent deadlock and other locking issues). The usual approach to
implement this is something like this:
public class MyActor implements Runnable {
BlockingQueue<Message> queue = new LinkedBlockingQueue<Message>();
public static void main(String[] args) {
new Thread(new MyActor()).start();
}
public void run() {
while(true) {
Message message = queue.take();
if(message.getSelector().equals("doWork")) {
doWork();
return;
}
}
}
public void doWork() {
System.out.println("doing my work");
}
}
So messages are exchanged between actors through queues when an actor
wants to notify another actor about something. With distributed actors
those messages would have to be exchanged through the wire. Since
these messages are similar to command objects that are added to queues
my first approach to move this into a distributed setting was to use
distributed queues like JMS queues. Each actor type serves a different
purpose with all the actors working in a collaborative fashion.
You aren't specific, given that you've only mentioned the solutions you've examined and not the purpose they should serve, but the shape of your search (assuming your analysis of what you need is correct) does indicate that your use case might be appropriate for queues.
Yes, maybe it has become clearer now :-)
Cheers, Oliver