| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Message Request/Response |
« View previous topic :: View next topic » |
| Author |
Message
|
| MQ_Lover |
 Posted: Mon Jul 15, 2013 1:00 pm Post subject: Message Request/Response |
 |
|
Acolyte
Joined: 15 Jul 2013
Posts: 67
|
Hi MQ Gurus,
Need you advise, we have a situation where by we are losing some of the response messages from third party application, we lose the connectivity the VPN goes down, but when the link is back up we see the server/requester channels out of sync and we have to reset the channel sequence number as we do this we lose some of the non-persistent response messages.
As a solution to fix this we are looking to make the messages persistent so we don't lose them, will this be correct approach to avoid message loss? also as the third party is very reluctant to make any changes if we make the request message persistent will the response also be persistent all the way back or does the third party needs to also make the message persistent while sending the response back.
Thanks.
For the setup - Please see below
Request Flow
US - Remote Queue, XmitQ, SenderChannel
THIRD PARTY - Receiver Channel, Local Request Queue
Response Flow
THIRD PARTY - Remote Queue, XmitQ, Server Channel
US - Local Response Queue, Requester Channel |
|
| Back to top |
|
 |
| gbaddeley |
| Posted: Mon Jul 15, 2013 3:58 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
Persistent messages will avoid message loss during channel failure, but you must get the VPN reliability issue fixed, even if its only to eliminate the tedium of resetting the channel each time the VPN goes down. 
_________________
Glenn |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jul 15, 2013 4:07 pm Post subject: Re: Message Request/Response |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| MQ_Lover wrote: |
| ... also as the third party is very reluctant to make any changes. If we make the request message persistent will the response also be persistent all the way back or does the third party needs to also make the message persistent while sending the response back. |
The 3rd-party replying application decides whether the reply messages are persistent or non-persistent.
_________________
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 |
|
|
| mqjeff |
| Posted: Mon Jul 15, 2013 9:23 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You should be able to adjust the channel such that the VPN connectivity failure doesn't cause it to go out of sync. This is a relatively abnormal situation.
If you have not done any tuning of the channel to improve performance and are using default values for things like batchsz and etc, you should look at adjusting channel parameters to better match the workload patterns you're exchanging.
If you have done performance tuning, you'll need to be more cautious about changing channel parameters, to better make tradeoffs between performance and reliability.
A simple thing to try would be to set the channel batch size to 1, such that it commits each and every time it sends a message. This, hopefully obviously, will slow the channel down quite a bit.
Retry timers should also be looked at, and tcp/ip level keepalive. Other parameters as well can be adjusted to make the channel more robust in the face of VPN connection drops.
If the VPN is known to just drop off every night between certain hours, simple scripting to stop and start the channel can make this problem go away, too... |
|
| Back to top |
|
|
| MQ_Lover |
| Posted: Mon Jul 15, 2013 9:45 pm Post subject: |
|
|
Acolyte
Joined: 15 Jul 2013
Posts: 67
|
| Thanks all... gives me a way forward with more options than originally I thought I have..I will also look at fine tuning the MQ channel with the Batchsize and Queue Manager with TCP/KeepAlive parameters as suggested, Many Thanks all again for your input. |
|
| 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
|
|
|
|
