| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Experts...Need help on JCN for Best Design approach |
« View previous topic :: View next topic » |
| Author |
Message
|
| Ravin |
 Posted: Thu Sep 06, 2012 8:48 pm Post subject: Experts...Need help on JCN for Best Design approach |
 |
|
Novice
Joined: 18 Nov 2010
Posts: 11
|
Hi Everyone,
I have a requirement where I need to process say 5 messages at a time. So, I used a compute node to get the 5 messages from the input queue, store in database and retrieve all the 5 messages once the threshold 5 is reached.
Now, I store these 5 messages in the environment variable as..
Environment.msgData.payLoad(i)
I pass this to the JCN, where I have a java code to process all the messages at a time.
My question here is, if there are 500-700 messages to be processed at a time is it a best approach to store messages in the environment variable or do I need to construct an xml message to pass to JCN? Which approach would yield better performance..pls. suggest.
Thanks. |
|
| Back to top |
|
 |
| marko.pitkanen |
| Posted: Fri Sep 07, 2012 1:05 am Post subject: |
|
|
Chevalier
Joined: 23 Jul 2008
Posts: 440
Location: Jamsa, Finland
|
Hi Ravin,
Not your direct question but have you considered use other perhaps built-in functions to implement message collections?
--
Marko |
|
| Back to top |
|
|
| Ravin |
| Posted: Fri Sep 07, 2012 1:39 am Post subject: |
|
|
Novice
Joined: 18 Nov 2010
Posts: 11
|
Hi Marko,
Thanks for the response!
I initially used the collector node, but was later advised to use ESQL code rather than the collector node.
Other than this I am not aware of built-in functions for message collection.
Just to clarify my question/requirement:
1) Take message from input queue one-by-one, store in database until a threshold is reached(threshold value is set in DB)
2) Once the threshold is reached, pull message from DB store in environment variable as an array of messages
3) Pass this environment variable to Java Compute Node (which has the necessary java files to process all the messages at the same time)
All I want to know is, if this is the best approach for the above scenario.
Thanks. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Sep 07, 2012 2:33 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
Probably not. The real question is why do you need to process 5 messages at a time. I cannot imagine that those would be 5 random messages pulled off the message stream, but rather that you are hitting some kind of message affinity.
The easiest part would be to send the content of all 5 messages in a single message. This can and should be handled outside of the broker, by the sending app.
If this is a means of making a discrete application do the right thing, have a DB collect the messages until they are ready for processing, then process the 5 msgs that go together as a single message.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Sep 07, 2012 4:03 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| fjb_saper wrote: |
| If this is a means of making a discrete application do the right thing, have a DB collect the messages until they are ready for processing, then process the 5 msgs that go together as a single message |
Which is exactly what has been said is being done.
I'd question the source of the recommendation to NOT use Collector node.
I'd reexamine the messages to see if they can be turned into message segments or groups, or otherwise see if there is any way they can be treated as "the same" message.
Processing 5 messages as a set is one thing, processing 5000 messages as a set is something else! |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Sep 07, 2012 5:45 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| I'd question the source of the recommendation to NOT use Collector node. |
I'd certainly want to know the justification for such a recommendation.
| mqjeff wrote: |
| I'd reexamine the messages to see if they can be turned into message segments or groups, or otherwise see if there is any way they can be treated as "the same" message. |
Given that the threshold / group size is stored as a parameter in the database it sounds a lot like this is some kind of arbitrary batch processing limit rather than something which actually links the messages.
Which begs the question why group the messages? Why not pass them one at a time to the Java? What's the requirement for this grouping?
| mqjeff wrote: |
| Processing 5 messages as a set is one thing, processing 5000 messages as a set is something else! |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
