***UPDATE*** I was able to create a cache of MessageConsumers and my approach appears to work ok, BUT....
I noticed there are alot of QueueThread threads created - 1 for each Queue destination. I understand this is the default behavior, but I may have 1000(s) of queues in a given usage. After reading through some low-level articles from FuseSource and ActiveMQ FAQ(s) I decided to try and configure the broker-level DedicatedTaskRunner to false. PROBLEM: I'm doing this programmatically on an embedded broker. My test scenario creates 20 Queues. When I look at the threads in Eclipse via my embedded Tomcat instance, I notice there are 20 QueueThread threads still??? How big is the default TaskRunner threadpool? Or, do I need to also set the optimizeDispatch property, too? If so, can someone tell me how to programmatically do this? Thanks again, Bob bob.deremer wrote: > > While this is possible, it's not desirable because of the dynamic nature > of my pub/sub. I was planning to use the VirtualTopic [queue-backed] > approach for the dynamic event subscribing side of things because of the > performance it claims and the fact that each consumer/destination pair is > run on it's own thread from ActiveMQ's threadpool. > > So, for example, if I have P1 and P2 as the event publishers and C1 as the > subscriber [to both publisher's events], I would have the following > destinations: > > P1 = VirtualTopic.P1 > P2 = VirtualTopic.P2 > C1 = Consumer.C1.VirtualTopic.P1 > C1 = Consumer.C1.VirtualTopic.P2 > > As you can see from the VirtualTopic approach - the number of destinations > is really dynamic. As C1 subscribes/unsubscribes to P# publishers - the > consumer/destination(s) will change. I want to avoid having to do thread > management for all of this - since it appears that ActiveMQ should fit the > bill. > > I'm working on the implementation now where I keep a > ConcurrentHashMap<String, MessageConsumer> collection. When a new > subscription is added, I just create the consumer on the fly and wire it > to my existing OnMessage handler. I'll see how this works. It > VirtualTopics aren't designed for scenarios where there will be lots of > subscribers and the list changes dynamically at runtime - please let me > know. > > Thanks, > Bob > > > Joe Fernandez wrote: >> >> Can you have two instances of the same POJO? If so, create two separate >> threads with their own sessions to the appropriate destination and give >> each thread an instance of the POJO. >> >> What about spawning multiple threads, each having their own Session, >> instance of the message listener POJO, and pointed to a particular >> destination? >> >> Joe >> http://www.ttmsolutions.com >> >> >> bob.deremer wrote: >>> >>> Hi ActiveMQ experts, >>> >>> I have a scenario where I'd like to create a single MessageListener >>> POJO, but it needs to be a listener on multiple queues. The reason is >>> that I'm trying to support the following 2 cases: >>> >>> 1) a pub/sub event model using Virtual Topics. As a result, each >>> subscriber (i.e. MessageListener) must be a separate Queue following the >>> VirtualTopic naming convention. This means that there could be 0 - many >>> queues this single POJO may be receiving messages from - based on what >>> events the POJO is subscribed. In addition, these subscriber queues >>> will be added/removed dynamically >>> 2) a request/reply model with the same POJO. This one is easy, as I'll >>> create a single Queue/POJO to handle incoming request messages. >>> >>> So, is this possible? And - even if it's possible, [IS IT A GOOD IDEA?] >>> While something may be possible, it might not be a design. I cannot >>> create a single POJO per destination and to support both >>> request/response + event subscription - i will still need a minimum of 1 >>> Topic + 1 Queue = 2 destinations going to the same POJO. >>> >>> Thanks in advance for any suggestions and please let me know if you need >>> any further details, >>> Bob DeRemer >>> >> >> > > -- View this message in context: http://old.nabble.com/Is-it-possible-to-have-1-MessageListener-POJO-handle-multiple-queues--tp27452190p27462754.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
