| Author |
Message
|
| mq_crazy |
 Posted: Thu Feb 28, 2008 11:27 am Post subject: Interesting Scenario |
 |
|
Master
Joined: 30 Jun 2004
Posts: 295
|
I do have a customer who has a bandwith of 64kb/sec on their line to their client, so they have issues when they have lot of messages piled up at the senders side as it reached the limit, is there anyway in the MQ that i can change that makes the channel to wait after it send some messages or maybe slow down the sending speed something that can help this situation???
MQ 6.0.2.3 running on solaris and the volume of messages are very low maybe 100-150 each day of around 1kb size. The problem arises only if the messages pile up for some reason. Thx |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Thu Feb 28, 2008 4:04 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
When a producer produces something faster than a consumer can consume it, queuing occurs. I hear MQ is pretty good at this. What's the problem? Let MQ do its job and queue up. If you don't have enough disk space to hold all the messages then have the producer slow down its production of messages or buy more disk space.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mq_crazy |
| Posted: Fri Feb 29, 2008 1:21 pm Post subject: |
|
|
Master
Joined: 30 Jun 2004
Posts: 295
|
| Thanks for your reply peter. The problem is not with the disk space, the problem is the network bandwith limit between the sender and receiving queue manager (64kb/sec) so if somehow the messages fills up on the sender side then while its sending bulk of messages at once, it reaches the bandwith limit and its failing, so i was wondering if there is anything we can do in MQ to set a limit of data to send for certain time interval or maybe setup a delay after every few messages?? Please let me know if thats possible in MQ? |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Feb 29, 2008 1:53 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mq_crazy wrote: |
| it reaches the bandwith limit and its failing |
What's failing? If the link fails, the channel should retry until it comes back. Piling the messages at the sender end is just a question of disc.
What am I missing?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Feb 29, 2008 3:01 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Vitor wrote: |
| mq_crazy wrote: |
| it reaches the bandwith limit and its failing |
What's failing? If the link fails, the channel should retry until it comes back. Piling the messages at the sender end is just a question of disc.
What am I missing? |
If your connection is really poor you might want to reduce the batch size of the channel
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Feb 29, 2008 4:13 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| If your connection is really poor you might want to reduce the batch size of the channel |
Or, as an alternative, you might want to increase batch size to reduce all that chit-chat channel ends do.
_________________
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 |
|
|
| fjb_saper |
| Posted: Sat Mar 01, 2008 4:54 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| bruce2359 wrote: |
| Quote: |
| If your connection is really poor you might want to reduce the batch size of the channel |
Or, as an alternative, you might want to increase batch size to reduce all that chit-chat channel ends do. |
Sure but you'd do that only if you have a "good" connection.
If your connection is poor increasing the batch size (which is negotiated to the lowest of sending/receiving) will just end up in more need for bandwidth or longer times as you will get more rollbacks on the channel.
The longer the transmit time the more chances of a rollback on a poor/bad connection. The lower the size of the batch the more chances it will go through without being rolled back / the lower the roll back quantity / the more overhead in handshakes...
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Mar 01, 2008 8:08 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| it reaches the bandwith limit and its failing |
A 64kb line isn't bad because it's 64kb. The original post did not say why the line is failing (if it is, in fact, failing).
Blocking (batchsize) increases throughput due to reduced MCA chit-chat pre- and post- batch.
If the comm line is experiencing hardware or network failures, the best MQ can do is to try to recover. Fix the hardware/network problem, if there is one.
_________________
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 |
|
|
| ashoon |
| Posted: Sat Mar 01, 2008 9:46 am Post subject: I have a similar scenario |
|
|
Master
Joined: 26 Oct 2004
Posts: 235
|
however on the other end of the link is an MQ client connection... is there anything you can do on client channel configurations to help with such a scenario?
_________________
IBM Certified - SOA Solution Designer & WebSphere Datapower SOA Appliances |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Mar 01, 2008 10:34 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| do have a customer who has a bandwith of 64kb/sec on their line to their client |
| Quote: |
| however on the other end of the link is an MQ client connection... |
In the original post mq_crazy didn't really specify that the channel was a client-svrconn channel. The term "client" has multiple meanings. I work with clients/customers that have clients/customers; some of which have client-svrconn channels, some don't.
Color me confused.
_________________
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 |
|
|
| fjb_saper |
| Posted: Sat Mar 01, 2008 2:47 pm Post subject: Re: I have a similar scenario |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| ashoon wrote: |
| however on the other end of the link is an MQ client connection... is there anything you can do on client channel configurations to help with such a scenario? |
The only thing you can do on the fast (troubleshooting tcp/ip over the wide area lan is always time consuming) is to have the client side set up an MQ server and deliver the messages there. The clients will then connect locally and hopefully be immune to microcuts.
We had the problem doing a client connect from one location to the other. Having a server in each location greatly reduced the client disconnects with nearly no impact on performance... however we had more than a 64K line between locations...
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Sun Mar 02, 2008 12:17 pm Post subject: Re: I have a similar scenario |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ashoon wrote: |
| however on the other end of the link is an MQ client connection... is there anything you can do on client channel configurations to help with such a scenario? |
No, because client connections are syncronious. Bad (or poor connections) will just kill them.
As other posters have said, if the link is unreliable then you're much better off putting queue managers at each end and letting the MCAs work it out.
If there's a question about license costs, then do a cost analysis of cost of a 2nd license v cost of fixing the link.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mq_crazy |
| Posted: Mon Mar 03, 2008 7:38 am Post subject: |
|
|
Master
Joined: 30 Jun 2004
Posts: 295
|
| Thanks for the replies guys. To make your doubts clear this is sender channel between two queue managers. I thought reducing the bacth size may not solve the problem as it keeps processing at the same speed that MQ is capable of and might exceed 64kb/sec of data(which is the bandwith limit my client purchased from third party) So i thought if there is anything on the chanel that we can do to limit the speed of transmission or wait for an interval after certain no. of messages sent???? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Mar 03, 2008 7:40 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
There's no "speed" control on a channel like that.
The batch size does cause MQ to "pause after some number of messages", because MQ has to do work at the end of each batch to commit the batch and start a new one.
So the smaller you make your batch size, relative to the number of waiting messages, the more often MQ has to do this work.
But it may not be very noticeable, depending on your disk speed and the size of the messages.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
