1. You can easily do something with the micro container.
If you have suggestions... I'm all ears to anything.
Anything that would help kill MDBs ;-)
- The core-API is a low-level API, independent of the application server. You need a ClientConsumer for each "handler" you want to have. (That's actually how we do on the Resource Adapter.. we have a few sessions configured).
- if you batch transactions, you will not need to have multiple threads.
2. MDBs are using the Transaction Manager. Are you planning using the Transaction Manager also (XA)?
Take a look also on the Asynchronous Send Example. That may
Yes, I do want MDBs to go away. Primarily I am looking at a way to configure a client consumer in say hornetq-configuration.xml or hornetq-beans.xml. HornetQ can, at runtime, instantiate and invoke the client consumer and pass on the messages received. This would obviate us to programmatically keep the session active and run client consumers for the x number of topics we have. Does it seem practical? Thanks!
I tried some use cases myself based on the docs and examples. I couldn't find an asynchronous send example. Regardless, it seems counter intuititve for me to start a consumer myself for receiving messages. From an asynchronous perspective, the messaging platform would allow registering of listeners and dispatch messages to the listeners that they are interested in. With HornetQ, I have to start the consumers myself and wait for messages. As I mentioned my earlier post, I expected that we can register the message listeners/handlers in some xml file. These listeners are to be instantiated by the messaging platform for dispatching messages. Please let me know if I am missing something. Thanks!
You could do something like this:
class MyBean implements MessageHandler
ClientSession session; //
public void start()
ClientSession... // do the whole initialization here
ClientConsumer ... // initialize the consumer
// make sure you have these things with a reference being held.
public void stop()
// close your session and consumers here
And add that class into hornetq-beans.xml (with a dependency to the server).
Whatever you do, it will go through these steps. (even if you used something that would do it automagically for you)
If we added something that would register a listener for you, this is what would happen under the covers.
If you are interested... the Spring integration that Bill Burke wrote has something as well. You should take a look.
BTW: The example I was referring was send-acknowledgements.
Ah. That would help. Couple of questions.
1. Is there an XSD for hornetq--beans.xml? I did not find one in the schemas directory. It would help in figuring out the structure.
2. Since the message handler would be injected in the server, there would be only one instance of the handler. Having a pool of message handlers would be helpful for scaling. Is it being considered?
Thanks for the help! Very positive experience with HornetQ so far. Great job!
People usually will need multiple instances of the consumer (like on MDBs) because MDB will *force* you to commit your message through XA on every received message.
I was expecting you would be dealing with transactions yourself and not requiring multiple instances.
If you need multiple instances.. I would just open multiple sessions at your instance. Controlling arrays.. etc.
As for the XSD for hornetq-beans... that comes straight from JBoss Micro Container. I'm not sure where's the XSD for that.
(BTW: If you are inside JBoss, you could have your own myapp-beans.xml, and the microcontainer would deploy it for you.)