| Author |
Message
|
| rurki |
 Posted: Mon Jul 14, 2008 7:29 am Post subject: MQ to DB2 Throttling |
 |
|
Newbie
Joined: 14 Jul 2008
Posts: 3
|
Hello,
We are currently using "db2mqlsn" to listen for messages on a queue then populate those messages in DB2.
All works until DB2 can not keep up with MQ.
Is it possible to throttle the amount of messages pulled from a queue within MQ?
db2mqlsn does not support doing so, so its up to MQ.
Thank you |
|
| Back to top |
|
 |
| sami.stormrage |
| Posted: Mon Jul 14, 2008 8:22 am Post subject: |
|
|
Disciple
Joined: 25 Jun 2008
Posts: 186
Location: Bangalore/Singapore
|
Yes, u can have ur own custom code written for the throtelling utility on MQ
_________________
*forgetting everything  * |
|
| Back to top |
|
|
| rurki |
| Posted: Mon Jul 14, 2008 9:38 am Post subject: |
|
|
Newbie
Joined: 14 Jul 2008
Posts: 3
|
So I would have to produce the middleware for db2mqlsn?
Or perhaps is there a way to throttle the channel to the queue, so that a queue can only contain 20 messages from the channel. Once those messages are removed the channel can release another 20 to the queue?
Thanks again, |
|
| Back to top |
|
|
| sami.stormrage |
| Posted: Mon Jul 14, 2008 10:15 am Post subject: |
|
|
Disciple
Joined: 25 Jun 2008
Posts: 186
Location: Bangalore/Singapore
|
There are quite a few possiblities.
1) You can change the batchsize interval on the sending channels.. .. please check the intercmmncation manual.
2) Think the messages are getting Triggered. So how about making ur aplication pick up the messages (this is not recommended for IMS though) instead of them gettiing triggered.
You can anyway, dowload the support pack MP00 and MP16.. And the pdf M16 could be of somehelp. As this has the exact scenario tht ur are trying to impliment..
But make sure that there isn't much overhead on mq itself.. with long running UOW's and Q chaching..
_________________
*forgetting everything * |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jul 14, 2008 10:18 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| ...custom code written for the throtelling utility on MQ |
Huh? Throttling utility?
I'll guess that sami is suggesting you (re)write your message creator application to put 20 messages, then wait for some time period, then put the next 20, and so on.
Nothing (that I know of) is included in the product to slow message channels down.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| sami.stormrage |
| Posted: Mon Jul 14, 2008 10:30 am Post subject: |
|
|
Disciple
Joined: 25 Jun 2008
Posts: 186
Location: Bangalore/Singapore
|
Ahh.. thought.. someone would comment on my first post.. wasn't Grand poobah.. this time.. think the same aplies to you aswell.. please check the docs..
I mean Jeff.. this time was a literal inarticulation..
*And sorry about my pathetic english*
_________________
*forgetting everything * |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jul 14, 2008 10:41 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| please check the docs |
What docs? If you are going to refer someone to documentation, please be specific. What manual? Provide a link. What chapter?
Many of us will read 'please check the docs' as RTFM - not at all useful if you don't tell us which docs to check.
Your English language skills are not the issue here.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| rurki |
| Posted: Mon Jul 14, 2008 11:50 am Post subject: |
|
|
Newbie
Joined: 14 Jul 2008
Posts: 3
|
I put a limit on the queue max size, so that only 24 messages can be queued at one time. Going to see if that does the job.
Thanks, |
|
| Back to top |
|
|
| sami.stormrage |
| Posted: Mon Jul 14, 2008 12:11 pm Post subject: |
|
|
Disciple
Joined: 25 Jun 2008
Posts: 186
Location: Bangalore/Singapore
|
but then again u need to take care that ur short retry int and long retry int are subtle enough to take care of the timeouts.
_________________
*forgetting everything * |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Mon Jul 14, 2008 12:28 pm Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| rurki wrote: |
I put a limit on the queue max size, so that only 24 messages can be queued at one time. Going to see if that does the job.
Thanks, |
You had better make sure the application knows what to do about a "Queue Full" situation then.  |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jul 14, 2008 4:33 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Here is your <ideal> solution:
- review the consumer application
Make sure there is no message affinity.
If need be remove it from the DB to make it scalable.
- Scale the consumer application until you have no more messages piling up on the queue
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jul 15, 2008 7:03 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Getting back to the original post:
The general idea of slowing down one application because another can't keep up doesn't make any business sense.
If the db is on a slow platform, upgrade the hardware. I'd be looking at tuning the db to perform better, rather than de-tuning MQ so that it performs worse.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jul 15, 2008 7:40 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Don't set a low max message limit, you will just spill onto the DLQ.
MQ is meant to be time and place independent of the other application.
Simply resource control your receiving DB2 program to an acceptable level, let the queue depth build up if it needs to. That's the advantage of queueing!
If replies are response time critical - then you need to send fewer messages or improve the speed of processing them.
Use message expiry values if you don't want to process messages beyond a certain age. |
|
| Back to top |
|
|
|
|
