message3? I don't see that in your example?
How are you sending the message?
Post a complete example please...
When you write the post, switch to advanced editor -> you can then attach files.
You can ignore my previous question as I have found & resolved the bug at my end. Sorry for the inconvinience.
Now I have a design decision to make with core apis & topics.
Do I create 1 queue and 1 consumer of a topic(=hornetq address), consume all the messages and then pass the relavant messages to all my 10 application listeners using a for loop in that consumer. (In this case, all messages are coming to my consumer and then messages filtering & message passing is taking place, so unncessary processing is a concern)?
Do I create 10 queues and 10 consumers of a topic(=hornetq address) using selectors, these 10 consumers will consume only their relavant messages and then call their one-2-one mapped application listeners. (I assumed that while working with JMS topics and creating session.createConsumer(topicName) , hornetQ code internally creates a queue with the address (=toipcName) and a listener listening on that queue. So in this case, 10 consumers are getting created so object heap space is a concern)?
any other option available?
Using an address, and queues with filters is probably the best option.
I don't fully understand your architecture, but filter on a queue is usually a good solution.
With core APIs, design Option1 (explained above) worked for us.
Creating a temporory queue for every subscription request failed in our load tests of 50k subscriptions & unsubscriptions per day and 10 messages per second. Lot of create queue send and block wait time out exceptions were seen in hornetq logs. There was also one class cast exception while casting 'nullresponse' to 'session+something' [will have to check the exact class name] at the time of creation of the temporary queue.
We took the temporary queue creation logic from hornetqsession class for JMS support.
I said: I didn't know your architecture.
If you are creating a queue every time like that, it's best if you just just keep the subscription open.
I"m not sure what you are doing. I would need to some code.
It's not possible for me to expose the prop. code. But I will try to explain that with my code snippets later.