<edit> It was pointed out that publisher/subscriber is not the right terminology for what I'm describing. Please substitute producer/consumer instead. </edit>
I'm trying to fashion a module following the publish/subscribe methodology. The idea is to publish messages which ALL subscribers will consume (rather than just one subscriber). This is like a JMS topic but without the overhead of JMS.
I've tried doing this with wait()s and notifyAll()s but ran into trouble because synchronization is required to obtain the lock and that limits the messages to being processed by one subscriber.
I also looked into BlockingQueue which is nearly exactly what I want, although again the queue.take() will only alert one subscriber per message.
What do you think? Does anyone have any ideas? I'd like to do this with just one collection or resource if possible, rather than having one queue per subscriber, but I can go to that model if necessary.
Thanks for your ideas. [ December 15, 2008: Message edited by: Cameron Dalton ]
I am not very knowledgeable on the subject, so take anything I say with a grain of salt.
I thought the whole idea of the publish-subscribe pattern was that you can have many subscribers to a single publisher. Each subscriber registers with the publisher, who maintains a list of who is interested.
Then, when a message comes out, the publisher send a copy of the message to everyone interested.
The way you are describing it, it sounds like your publisher is putting one copy of the message in one spot, and you want each subscriber to come and read that only copy. I think this is wrong.
Each subscriber should have a way to receive the message, just like each subscriber of a magazine has a mail box. It wouldn't make sense for "Time" magazine to only print one copy of the magazine and expect everyone to come to <insert city here> to read the only copy in existance, would it?
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
I suppose a more accurate term might be producer/consumer rather than publisher/subscriber. The scenario I described is what I need because I need the subscribers to block until a message is produced, which excludes the possibility of using an event-type callback function (unless there's something to that I'm not aware of).
Thanks for your input - good catch on my bad terminology.