ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General IBM MQ Support » Batch interval setting on channels

Post new topic  Reply to topic
 Batch interval setting on channels « View previous topic :: View next topic » 
Author Message
BBM
PostPosted: Mon Nov 13, 2006 11:58 pm    Post subject: Batch interval setting on channels Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Tue Nov 14, 2006 12:41 am    Post subject: Reply with quote

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
View user's profile Send private message
Mr Butcher
PostPosted: Tue Nov 14, 2006 1:46 am    Post subject: Reply with quote

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
View user's profile Send private message
BBM
PostPosted: Tue Nov 14, 2006 2:00 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Tue Nov 14, 2006 2:06 am    Post subject: Reply with quote

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
View user's profile Send private message
Nigelg
PostPosted: Tue Nov 14, 2006 2:20 am    Post subject: Reply with quote

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
View user's profile Send private message
BBM
PostPosted: Tue Nov 14, 2006 3:28 am    Post subject: Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Tue Nov 14, 2006 4:14 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General IBM MQ Support » Batch interval setting on channels
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.