| Author |
Message
|
| anilit99 |
 Posted: Thu Jul 02, 2009 8:33 am Post subject: message selector on a mdb. |
 |
|
Voyager
Joined: 28 May 2009
Posts: 75
Location: London, UK
|
Hi,
I've searched in this forum already. But, newbie as I am, couldnt find the related post ! I am damn sure, I am not the first person to face this.
Question : How to specify the message selector in an mdb ? I couldnt find that property in the resource adapter (the only thing i found there was - messageSelection which has the values of Client and Broker). I am talking about JBoss 4.2 and EJB3 and I am using annotations to specify the properties.
I've read the Using Java thing - it specify how to mention it using QueueReceiver but not in asynchronous delivery using mdbs.
ALSO
can you experts tell me where this filtering of messages based on the selectors happen ? On the MQ server or on the application side ?
_________________
"I almost care !" |
|
| Back to top |
|
 |
| anilit99 |
| Posted: Fri Jul 03, 2009 12:22 am Post subject: |
|
|
Voyager
Joined: 28 May 2009
Posts: 75
Location: London, UK
|
OMG ! I think this is the only thread in this forum which got no replies even after a complete day !
I think either the question must be incredibly dumb or completely illegible or been asked too many times !
I cant help if it is the first one - but if its the second I can rephrase it may be and if its the third one - i guess i have to do my searches once again !
 !!
_________________
"I almost care !" |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Fri Jul 03, 2009 12:56 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
|
| Back to top |
|
|
| anilit99 |
| Posted: Fri Jul 03, 2009 1:44 am Post subject: |
|
|
Voyager
Joined: 28 May 2009
Posts: 75
Location: London, UK
|
Oh ! thanks WMBDEV1 !
Once in a while there comes a situation where I want to kill myself ! and this is exactly the one.
For any unlucky souls out there like me its - messageSelector and its not message-selector !!
and btw, for some reason you cannot see this property in the resource adapter's ra.xml.
_________________
"I almost care !" |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jul 03, 2009 11:13 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
And the real reason why you got no answer is that we have none to give with the elements provided.
The question is not how to but why would you want to?
Looking at what an MDB is designed to do, why would you ever want to put a selector onto it?
There are other patterns that can help you deal with the underlying requirement...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| anilit99 |
| Posted: Fri Jul 03, 2009 11:36 am Post subject: |
|
|
Voyager
Joined: 28 May 2009
Posts: 75
Location: London, UK
|
well, here is the scenario.
There is a system which can talk to only one queue. But posts all "types" of messages to that queue (10 types of responses).
As I see it, I have two options now -
1. Have one mdb in place and a chain of if else statements to differentiate between the types of responses.
2. Multiple mdbs with message selectors on them and do the filtering on the MQ itself - receive messages only if the message selector matches. (dont know whether thats the way MQ works or not - I asked the same thing in the first post).
_________________
"I almost care !" |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jul 03, 2009 9:35 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| anilit99 wrote: |
well, here is the scenario.
There is a system which can talk to only one queue. But posts all "types" of messages to that queue (10 types of responses).
|
Can you please elaborate? This is very atypical!
I would expect that if you can have one mdb you could just as well configure a different one on a different queue...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| anilit99 |
| Posted: Sun Jul 05, 2009 2:08 am Post subject: |
|
|
Voyager
Joined: 28 May 2009
Posts: 75
Location: London, UK
|
sorry for being so veil.
I have to interface with a system(external) which can talk to only one MQ queue. But as I already said - it sends different kinds of xml messages to the queue. Each kind of xml message is supposed to be treated entirely different - updateOrder, deleteUser, checkCompany and likewise.
The external vendor said they can set a message selector on the message. So, isnt it nice to have separate mdbs for each kind of message but still looking on the same queue. This way I can deal with each kind of message separately and my code looks very clean.
Well, at least thats the idea.
| Quote: |
| I would expect that if you can have one mdb you could just as well configure a different one on a different queue |
as I said we just have one queue.
_________________
"I almost care !" |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Jul 05, 2009 3:44 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Wrong approach.
What you need is a single MDB with a distribution/dispatch pattern.
It will read the message determine the message type and dispatch to which ever queue is specific for the processing of the message.
You can then have a different MDB service that queue.
Advantages... If something goes wrong you can pinpoint the culprit with a lot more ease... Say orders don't process anymore (changed spec)... How would you realize this when you run with a selector? The added queue depth ensuing from the original problem would also quickly kill the performance of the other applications reading from the queue.... (not so much if using V7 and server based selectors but very much so on any prior version)...
So you are not limited in your design to a single queue. Just dispatch messages from the single queue to the queues your application needs.
And yes you will have to write the dispatcher MDB but that's peanuts...
It also furthers scalability by highlighting the component that needs to be scaled....
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| anilit99 |
| Posted: Sun Jul 05, 2009 5:23 am Post subject: |
|
|
Voyager
Joined: 28 May 2009
Posts: 75
Location: London, UK
|
thanks a ton fjb_saper !
I read the reply and read it again.. ! Well, I am going for this pattern you just mentioned. I kinda like the idea of single point of entry (dispatch mdb) instead of multiple.
I seriously think that I should've mentioned these details (point noted for the next time)
| Code: |
AS: JBoss 4.2
MQ : V7
Approximate Load : 2000-2500 msgs per hour.
Approximate msg length : 2-3mb.
|
Now being said that, am I not introducing one more hop in between and subsequent delay ?
MQ --> dispatch MDB --> service queues --> service mdb
I am just trying to understand is it worth introducing one more hop in between ?
Or let me put it this way, is this approach still holds good if the load is, say 50,000 msgs per hour instead of a mere 2000 AND the message size is lets say 20-30mb ?
p.s: I thought I was the only one working on a sunday !   |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Jul 05, 2009 1:15 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| anilit99 wrote: |
thanks a ton fjb_saper !
I read the reply and read it again.. ! Well, I am going for this pattern you just mentioned. I kinda like the idea of single point of entry (dispatch mdb) instead of multiple.
I seriously think that I should've mentioned these details (point noted for the next time)
| Code: |
AS: JBoss 4.2
MQ : V7
Approximate Load : 2000-2500 msgs per hour.
Approximate msg length : 2-3mb.
|
Now being said that, am I not introducing one more hop in between and subsequent delay ?
MQ --> dispatch MDB --> service queues --> service mdb
I am just trying to understand is it worth introducing one more hop in between ?
Or let me put it this way, is this approach still holds good if the load is, say 50,000 msgs per hour instead of a mere 2000 AND the message size is lets say 20-30mb ?
p.s: I thought I was the only one working on a Sunday ! |
If that was the case you'd probably need to put some serious thought into load balancing and scaling.
As to the extra time -- with messages that big yes there will be extra time involved. However the handoff between dispatcher and consumer should all be in memory as the consumer should already be waiting for the next message.
The point with online processing / batch processing of XML messages is to reduce the message to its atomic transactional unit.
If you have a unit as being a batch with multiple transactions that does not play well in online... What you need is each atomic transaction being its own message. So a batch would comprised of x online transactions where x usually ranges in the thousands. You will find that online messages are much faster in processing when kept to a minimum in size.
It is usually faster to process 1000 message in subsecond time than to process one big message that will take some time only to load alone (20 MB) and quite some time again to process?
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| anilit99 |
| Posted: Mon Jul 06, 2009 3:01 am Post subject: |
|
|
Voyager
Joined: 28 May 2009
Posts: 75
Location: London, UK
|
thanks again fjb_saper !
| Quote: |
| If that was the case you'd probably need to put some serious thought into load balancing and scaling. |
As I said, I was just trying to understand the pattern you explained to me a post earlier. I just deployed your solution and its working like charm in the dev system (well, there is no reason for it not to work  )
and some posts earlier you said this :
But you didnt quite mention the wrongness in that approach. If its not too much to ask, I am just curious to know why exactly that was a wrong approach. I read in this forum somewhere that previous versions of MQ had severe problems with message selector. But I am using V7 and as you said those problems have been fixed in this version.
Message selector is a standard from JMS and honestly I believe this is exactly the kind of scenario where we can put that in to use.
_________________
"I almost care !" |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jul 06, 2009 2:04 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| anilit99 wrote: |
some posts earlier you said this :
But you didnt quite mention the wrongness in that approach. If its not too much to ask, I am just curious to know why exactly that was a wrong approach. I read in this forum somewhere that previous versions of MQ had severe problems with message selector. But I am using V7 and as you said those problems have been fixed in this version.
Message selector is a standard from JMS and honestly I believe this is exactly the kind of scenario where we can put that in to use. |
 but I believe I had also highlighted some points:
Like how fast will you be able to determine which selector has a problem and is backing up messages on the queue. Imagine that backup becoming huge fast (100,000 msgs). Regardless of whether you do the selection on the server or the client, doing the selection will still take some time.
Determining which of the several MDB's with selector is responsible will also take time...
Imagine everything is fine but you just can't process fast enough... scaling is clearer and easier, as well as load balancing, when everything has its own queue...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| anilit99 |
| Posted: Tue Jul 07, 2009 4:50 am Post subject: |
|
|
Voyager
Joined: 28 May 2009
Posts: 75
Location: London, UK
|
thanks for all the patience fjb_saper !
I am a newbie here and your posts were really helpful in understanding the concepts.
Btw, I am not going to stop leeching this forum until I understand the meaning of my own signature - which I overheard from one of the poobahs in some post ! 
_________________
"I almost care !" |
|
| Back to top |
|
|
| atheek |
| Posted: Tue Aug 25, 2009 2:39 am Post subject: |
|
|
Partisan
Joined: 01 Jun 2006
Posts: 327
Location: Sydney
|
I think this is a very common scenario in messaging. The best possible solution is to have separate set of message channels (by channel I mean remote-local queue pairs) between the sytems for each message type. This could avoid the extra hop introduced by the dispatcher. This is best suited if the number of message types is small, say 3-5.
However, this could become an administrator's nightmare if the numer of message types increases, maintainig very large number of remote - local queue pairs will be a tedious task.As the messaging architect you can make the call on this tradeoff - performance v/s ease of administration.
As far as I understand, as a JMS best practise, message selector on queues should be avoided as it kills performace with increased numer of pending messages in the queue. Message Selectors on topics are fine as far as the number of subscribers listening to the topic is limited. |
|
| Back to top |
|
|
|
|
