| Author |
Message
|
| BBM |
 Posted: Mon Nov 13, 2006 11:58 pm Post subject: Batch interval setting on channels |
 |
|
Master
Joined: 10 Nov 2005
Posts: 217
Location: London, UK
|
Hi,
We have a requirement to limit message flow across a channel to 1 message per minute.
This is because the receiving application cannot differentiate between two messages received in the same minute - it uses the time as the unique identifier!
I have already asked the app team to use another part of the message to track different messages in the application. In the interim they would like me to limit message message flow to 1 per minute.
On reading the Intercommunication manual it appears by setting batch interval to 60000 this should only complete a batch regardless of batch size after 1 minute.
However, on testing this I find that my messages are delivered immediately regardless of batch interval.
Any ideas?
Cheers
BBM |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Nov 14, 2006 12:41 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
From the Command Reference:
| Quote: |
BATCHINT(integer)
The minimum amount of time, in milliseconds, that a channel keeps a
batch open.
The batch is terminated by whichever of the following occurs first:
- BATCHSZ messages have been sent, or
- The transmission queue is empty and BATCHINT is exceeded
The default value is zero, which means that the batch is terminated as soon as the transmission queue becomes empty (or the BATCHSZ limit is
reached).
|
So batch size is a factor - what's yours set to?
I remain unconvinced that this is a workable mechanism to throttle messages in the way you require. If you set BATCHSZ to a ludicrously high value so that BATCHSZ is not reached within BATCHINT it still allows for 2 messages in the batch within the minute.
(Crazy app design by the way - I know you've asked for it to be changed, but in the meantime ask whoever designed it if they can spell "scaleable"  )
Is it impossible to throttle the sending app, so it only transmits one message a minute? It sounds like an easier / simpler / quicker proposition. The case could be made that if the time is a "key" value (!) then the sending app is in error sending "duplicate key" messages... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Tue Nov 14, 2006 1:46 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
as vitor said - it will not work.
if you are looking for a unique identifier of a message, why dont you use messageid and/or correlid? thats what they are for.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| BBM |
| Posted: Tue Nov 14, 2006 2:00 am Post subject: |
|
|
Master
Joined: 10 Nov 2005
Posts: 217
Location: London, UK
|
Thanks Vitor for the clarification the bit I read in the manual was:
If you do not specify a batch interval, the batch closes when the number of messages specified in BATCHSZ has been sent or when the transmission queue becomes empty.
And I incorrectly used reverse logic to deduce that with BATCHINT specified the batch would close only after it had expired regardless of BATCHSZ - you live and learn.
And I have already highlighted the bad application design, unfortunately its not one application's fault, this is as a result of several applications along the way manipulating the message. But your comments are pretty much spot on.
Mr Butcher:
Totally agree - but by the time the receiving app deals with the messages message id etc has been stripped out and only the time remains.
They are going to code a solution but need an interim workaround to slow message flow down.
Figures they didn't see this in testing as they sent messages through 1 at a time. Doh!
Any other ideas on how to throttle back message flow using MQ and my bare hands alone?
BBM |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Nov 14, 2006 2:06 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| BBM wrote: |
Any other ideas on how to throttle back message flow using MQ and my bare hands alone?
|
You could use a channel exit to hold back the messages. Get the exit to loop for 60 seconds before returning zero... 
I wouldn't. Not if you paid me. 
Especially for an "interim" solution.
I repeat, can you get the sending app fixed?
_________________
Honesty is the best policy.
Insanity is the best defence.
Last edited by Vitor on Tue Nov 14, 2006 2:42 am; edited 1 time in total |
|
| Back to top |
|
|
| Nigelg |
| Posted: Tue Nov 14, 2006 2:20 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
BATCHINT is the length of time a batch is kept open if no more msgs arrivce on the xmitq, i.e. after the xmitq is empty the channel waits BATCHINT ms for more msgs. If any more msgs are put to the xmitq, they are sent immediately, and the batch interval is reset.
As far as I can tell from your description, the msgs are being put to the xmitq faster than 1 per minute, in which case all the msgs will flow down the channel as described above. BATCHINT only applies where there are no more msgs to send.
Your only recourse is to limit the putting app to put msgs at intervals of more than 60 seconds.
One way to do this would be to interpolate a local queue between the putting app and the xmitq. The existing apps could put to this local queue, and another app could be written to get a msg from the local queue, put it to the remote queue, and then wait 60+ seconds before getting another msg.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| BBM |
| Posted: Tue Nov 14, 2006 3:28 am Post subject: |
|
|
Master
Joined: 10 Nov 2005
Posts: 217
Location: London, UK
|
Thanks for the suggestion. We have no access to the sending app. you have given me an idea though. We could set up a scheduled job on our MQ box that takes a message from a test queue and copies it to the app queue every 90 seconds.
I believe from a colleague MA01 should be able to do this...
Very Heath Robinson but it should work.....until they fix the app - which they promise will occur at the next release..
BBM |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Nov 14, 2006 4:14 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Bizzarre bizzarre.... I would have thought their architect should have realized they needed something at the milisecond level if not below...
And how would he have handled the commit of multiple messages at the same time?....
Well I guess this is all water under the bridge now...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
