-
1. Re: More control over the execution thread when receiving messages
clebert.suconic Dec 3, 2013 11:56 AM (in response to timwright)you should have used the user's forum for this... we would have picked this sooner...
Why do you need an interceptor for this.. why you just don't use a super class on your consumer doing what you need... your onMessage would just call the beforeReceive and then an abstract method where you could use on all your consumers?
We do something similar on our MDB interceptor...
And I'm not sure why you call this thread control? it's just a simple executor after a message arrives? I got confused on your usecase.. maybe you need Message grouping?
-
2. Re: More control over the execution thread when receiving messages
timwright Dec 3, 2013 9:22 PM (in response to clebert.suconic)Hi,
Sorry to have confused you - let me see if I can describe it a little better! (it's not really related to message groups)
By thread control, I really meant able to supply your own thread to dispatch messages on in the form on an ExecutorService. I would like to do this since we use the same ExecutorService to handle work from many other sources in addition to HornetQ. We would also like in some cases to start an XA transaction prior to processing a message.
There are there two issues with the regular API.
- Using receive() is not sufficient, since you can't practically do this in combination with an ExecutorService.
- It's my understanding that you can't really use MessageHandler.onMessage() with XA transaction as you need to enlist the resource prior to callback, hence the need to start the the transaction just before the message is dispatched.
In essence it's very like implementing MDB, I suppose I was thinking about a solution through a public API. (The JMS API has the MessageConsumer API which allows you to do this sort of thing). I spent some time looking at the public API, and figured that it could be done with an interceptor, but did not really like the idea.
I did take a quick peek at the internals,and figured it was doable. Generally I am not a fan of sub-classing internal components, unless the are designed to be sub-classes. I would need to look in more detail at your suggestion, but my initial impression was that it would be fiddly to do, as the internals or the core API are (understandably) not designed to be easily sub-classed or wrapped for this sort of purpose.
I hope that clarifies my problem!
Cheers,
Tim