| Author |
Message
|
| RogerLacroix |
 Posted: Mon Mar 30, 2015 8:42 am Post subject: New: MQ Channel Throttler v1.0.0 |
 |
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
All,
Capitalware Inc. would like to announce the official release of MQ Channel Throttler v1.0.0.
MQ Channel Throttler (MQCT) provides the ability to control/throttle the number of messages or bytes that flow over a channel. MQCT operates with IBM MQ (aka WebSphere MQ & MQSeries) v6.0, v7.0, v7.1, v7.5 and v8.0 in Windows, Unix, IBM i (OS/400) and Linux environments. It operates with Sender, Receiver, Server, Requester, Cluster-Sender, Cluster-Receiver, Server Connection and Client Connection channels of the WMQ queue managers.
MQCT is a simple drop-in solution that provides throttling for MQ queue managers. The throttling can be configured for queue manager to queue manager channels or for client application to queue manager channels. The MQCT can be configured as a queue manager channel message exit or as a channel sender/receive exit.
On IBM i, Linux, Unix and Windows, MQCT can be configured and used with a non-default installation of MQ in a multi-install MQ environment.
For more information about MQCT, please go to: http://www.capitalware.com/mqct_overview.html
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
 |
| zpat |
| Posted: Tue Mar 31, 2015 12:44 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Can this exit also be used to limit the rate of MQI operations against a channel (regardless of the amount of data transferred).
For example an application performing rapid MQGETs (without wait) on an empty queue?
Or an application using MQCONN or MQOPEN too frequently due to poor programming?
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Mar 31, 2015 4:14 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| zpat wrote: |
Can this exit also be used to limit the rate of MQI operations against a channel (regardless of the amount of data transferred).
For example an application performing rapid MQGETs (without wait) on an empty queue?
Or an application using MQCONN or MQOPEN too frequently due to poor programming? |
I would have thought that an activity trace would allow you to catch those offenders pretty quickly? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Mar 31, 2015 5:10 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fjb_saper wrote: |
| zpat wrote: |
Can this exit also be used to limit the rate of MQI operations against a channel (regardless of the amount of data transferred).
For example an application performing rapid MQGETs (without wait) on an empty queue?
Or an application using MQCONN or MQOPEN too frequently due to poor programming? |
I would have thought that an activity trace would allow you to catch those offenders pretty quickly? |
Who's got time to sit and watch Activity Traces all day and night?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Mar 31, 2015 8:08 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| zpat wrote: |
Can this exit also be used to limit the rate of MQI operations against a channel (regardless of the amount of data transferred).
For example an application performing rapid MQGETs (without wait) on an empty queue? |
MQCT was designed to control/limit/throttle messages (or bytes) flowing over a channel. Since a message correlates to an MQGET or MQPUT/1 then yes, if you use
| Code: |
MessageRate=5/s
ClientAction=G |
It says to limit the MQGETs to 5 per second (and ignore any MQPUT/1s).
The default value for ClientAction is 'B' (Both) which means MQCT counts both MQGETs and MQPUT/1s.
The flip-side for controlling the MQPUT/1s would be:
| Code: |
MessageRate=80/m
ClientAction=P |
which says to only allow 80 MQPUT/1s per minute (and ignore any MQGETs).
| zpat wrote: |
| Or an application using MQCONN or MQOPEN too frequently due to poor programming? |
Not in MQCT but did you read my posting on Excessive Client Connections feature I am adding to MQAUSX & z/MQAUSX (and to MQSSX & z/MQSSX).
90% of everything I create, products and/or features, is driven out of customer requests, so if you think there is a particular need then let me know.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Mar 31, 2015 12:18 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
It's not just about identifying these (I can often see them in the BlockIP2 log) but to constrain them.
But it's not easy to get code changed (and it might be vendor written) but the ability to insert a delay between their MQI operations might be useful.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Mar 31, 2015 12:46 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| zpat wrote: |
It's not just about identifying these (I can often see them in the BlockIP2 log) but to constrain them.
But it's not easy to get code changed (and it might be vendor written) but the ability to insert a delay between their MQI operations might be useful. |
So, you are saying that 'ClientAction' should support 4 values: C, O, G & P for MQCONN/X, MQOPEN, MQGET and MQPUT/1. And 3 rate keywords: Rate, MessageRate and ByteRate.
So, you want to be able to have no more than 8 connections per second:
| Code: |
ClientAction=C
Rate=8/s |
Or no more than 100 opens per minute:
| Code: |
ClientAction=O
Rate=100/m |
Is this what you are thinking?
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Mar 31, 2015 1:17 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
That sort of thing.
Doesn't mean we would necessarily purchase the exit of course, corporate mentality being what it is!
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| tczielke |
| Posted: Tue Mar 31, 2015 1:39 pm Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
It is too bad you can't write these exits in Java. That would help get things slowed down. Just kidding. 
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Wed Apr 22, 2015 2:20 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
All,
To bring this topic full circle, I took T.Rob's and zpat's comments regarding MQ Channel Throttler (MQCT) and implemented them.
So the new and improved MQCT v1.0.0 also includes:
- the ability to throttle by connection calls (MQCONN & MQCONNX)
- the ability to throttle by open calls (MQOPEN)
- will (optional) emit an alert to an event queue if MQCT inserts a delay
- will (optional) write a syslog message if MQCT inserts a delay
- if the MQCT IniFile is changed, MQCT will dynamically update itself
I changed the ClientAction keyword to APIType because MQCT is no longer about just throttling messages.
APIType supports:
- C means that MQCT will throttle for MQCONN and MQCONNX calls
- O means that MQCT will throttle for MQOPEN call
- G means that MQCT will throttle for MQGET call
- P means that MQCT will throttle for MQPUT and MQPUT1 calls
i.e.
I have updated the documentation and the web site.
If anyone has any other comments, please share them.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
|
|
