| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Can WMQ run well in bad condiction. |
« View previous topic :: View next topic » |
| Author |
Message
|
| wangld |
 Posted: Tue Oct 31, 2006 10:20 pm Post subject: Can WMQ run well in bad condiction. |
 |
|
Novice
Joined: 27 Sep 2006
Posts: 13
|
My case is:
The main server handle 20 sub server.
Per day, a sub server send to the main about 100 transaction data (need persistent) around 32KB each.
Some time, 2 ends maybe exchange archive files (.pdf, .doc, .zip ...)
From the sub to the main use 64 Kbps private line but seem like go down regulary.
The main server using Windows Terminal 2000, Oracle 8i, hardware configure: CPU 1.8 GHz x 2, 512 MB.
Can run Websphere MQ well on this system?
MQ (I mean MQ not MQSeries) is designed for solving for bad connection or it is just a safer solution replace FTP? |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Nov 01, 2006 5:03 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Are you planning to have a queue manager on each sub server as well as the main server? If so, you can use sender/receiver channels which will automatically reestablish communication once the connection is restored. Obviously network outages will affect throughput but it doesn't sound like you're moving a lot of data (20*100*32Kb per day is not much).
If you're going for a single queue manager (and 21 queue managers is potentially a lot of licenses) you'll lose the automatic reconnection ability as everything will be syncronously connectted, but you will gain the ability to tell in your application simply and easily that the link has failed, and the application will be able to reestablish the connection.
Hope that helps. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| wangld |
| Posted: Mon Nov 06, 2006 12:40 am Post subject: |
|
|
Novice
Joined: 27 Sep 2006
Posts: 13
|
Hi Victor,
One of most problem is:
- When a network go error, if using sender - receiver, the channels keep retrying and hold a lot resoucres, then need stop them.
- If using client - server, can ping the server before get or put data to queues to sure the connection is good.
The working will stuck at the point: Can't perform well the automatic delivering task.
1. If I override APIs of MQI like: MQGET, MQPUT by using exits, the background tranfer in case sender - receiver will be update too? If not then there are anyway to control behavior of MQ background process?
2. If the answer for question 1 is yes then how about exits affect WMB?
Thx.
( Sorry, my english is not good >"< ) |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Nov 06, 2006 1:05 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
I'm sure your English is much better than my command of your native language! 
One of the key points of MQ is the automatic reconnection of channels in the event of network failure. If you're going to stop & restart them you're losing a lot of benefits. I would suggest instead you tune the retry intervals if you think they're beating the system to death, modifying the behaviour rather than stopping it.
If you've a client, it should be coded on the assumption the network will sooner or later fail, and attempt to reconnect if it gets an MQ code indicating network failure. Pinging is irrelevant; if the application can connect it's working, if not it isn't.
I don't understand why you'd want to override MQGET & MQPUT, and am not aware of any exits that would allow you to; exits tend to be at channel level. Certainly you can't control the MQ background processes except through the provided interfaces.
I don't see what you're trying to achieve. If it's just dealing with network problems by adding resiliance, you may need 21 queue managers to provide total uptime, but that does seem like overkill for the amount of data you're moving. You could consider having the applications grouped around a smaller number of queue managers, possibly clustered.
Have another try at explaining your requirement and existing problems if this hasn't helped.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Nov 06, 2006 3:29 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
An API exit will get called whenever any program invokes an API call.
At least some of the MQ internal programs invoke normal MQ API calls - for example the Message Channel Agent ("It was the first MQ program ever written").
So if you install an API exit, you can indeed interfere with the normal functioning of MQ.
This is only one reason why API exits are advanced topics, and you shouldn't be messing with them if you don't have to. There are many MORE reasons why API exits shouldn't be used most of the time.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| wangld |
| Posted: Mon Nov 06, 2006 3:45 am Post subject: |
|
|
Novice
Joined: 27 Sep 2006
Posts: 13
|
Thx Victor, my english is not enough to describe my case but I will try.
We need exchange data between financial district centers and financial province center. Because of my country background, Vietnam, we have only one choice for connection line: a line with 64 Kbps, for mountain region case.
We have used Oracle Advance Queue but while the line going to die, the channels is still keep retry sending data and it make the slow network slower, even, it is cause that make the network died. Another problem is when exchange archive files around 5 MB using ftp, if the real tranfer rating down to below 1 KB, it take very long time to finish and because of this, other more important work have to wait.
With OAQ, we can't control the background tranfer and integate with file tranfer system. That why we look for another solution. The new must using MQ protocol (for independent and asynchronous), can do file tranfer job too, and must be more intelligent like can check network condiction; if the network is in great condiction, file tranfers will be priority, if in good case, then do transaction, if in bad or disconnected, then pause system and wait the line recover, for example.
I've overviewed WMQ but still stuck with "channels keep retring sending message without caring network connection" in sender - receiver case, and not automatic in client - server case.
Hope you can know my case now.
Thx again. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Nov 06, 2006 4:10 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
well I'd look at adding priority to the different messages. Send the ftp messages with lowest priority. They will wait until all financial data (with higher priority) has been exchanged. This will allow optimum use of your network.
Reconnection interval behavior can be set by short and long retry intervall and number of attempts (read the interconnection manual) or by client behavior. The batch size may also be relevant. If you need to you could even specify 2 channels for the same destination (one for financials, one for ftp)
Hope this helped a bit
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Nov 06, 2006 5:44 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Sorry for the delay in replying, design meeting broke out & I had to take my position in the trench at short notice!
I echo the excellent comments of fjb_saper. This site uses sender reciever pairs for their auto reconnect and the load on the box while they're retrying is minimal. We've used the reconnect interval for one notorious link so it tries like billy-o to reconnect immediately on a failure, then doesn't try again for 2 hours (the length of time it typically gets us to persuade the guilty party to fix it. Again.)
Additionally for ftp over MQ I recommend you search the forum - it's a populare topic and you should find some useful material. There are a number of propriatory products that can achieve this.
Hope I've helped as much as fjb_saper
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| wangld |
| Posted: Wed Nov 08, 2006 5:21 pm Post subject: |
|
|
Novice
Joined: 27 Sep 2006
Posts: 13
|
Thx Victor, fjb_saper and jefflowrey
Well, the priority is the 2nd key (the 1st one is replaceable ftp with Simple File Tranfer or PM4DATA) when we overviewed WMQ. Because the OAQ have the priority feature too (and we are not the team who write the old applications and they left our organization already), we don't sure MQ can make an GREAT perfomance improved while compare with BIG buck paid for the changing (include licences, hardware upgading, developing new modules). That why we must understanding deeply what can WMQ can offer to us now and the future.
And thx again for your help, I can have better knowledge about it.
^^ |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
