| Author |
Message
|
| Esa |
 Posted: Tue Jan 24, 2012 11:43 pm Post subject: |
 |
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| gbaddeley wrote: |
| Esa wrote: |
| Is it because the connection is opened from another ip address? |
AFAIK, Yes. |
I agree. That was a rhetorical question, part of a brigde to the conclusion in the following paragraph. It's a question of style, trying to avoid over-using the word "probably"... ... yes, it seems I'm trying to avoid it now that I finally have learned how to spell it properly 
But thanks for the confirmation 
Let's hope somebody can confirm the conclusion, too. |
|
| Back to top |
|
 |
| Esa |
| Posted: Wed Jan 25, 2012 12:49 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| Esa wrote: |
The messages that are in precommitted state on the sender side are trapped. You cannot resolve the channel because the Sender you are running is talking to another instance of the Receiver channel.
|
Now here I go again giving the problem imaginary features that nobody has reported. Please ignore.
I should read much more carefully what other people write. So the actual problem is just that a sequence number mismatch occurs, the channel stops and you have to reset it.
Could it be that the failover sometimes just happens too fast, before the receiver channel has shut down? Then adjusting heartbeat, keepalive and disconnect intervals for the channel might help?
If that doesn't help you can always configure NAT between the senders and the receiver? |
|
| Back to top |
|
|
| Koit |
| Posted: Wed Jan 25, 2012 12:58 am Post subject: |
|
|
Novice
Joined: 02 Jan 2006
Posts: 12
|
| I just want to add that this behaviour started after updating MQ on the receiver side from 6 something to 7.0.1.3. Senders are still at version 6. |
|
| Back to top |
|
|
| Esa |
| Posted: Wed Jan 25, 2012 1:23 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| Koit wrote: |
| I just want to add that this behaviour started after updating MQ on the receiver side from 6 something to 7.0.1.3. Senders are still at version 6. |
OK, then it's not about multi-instance queue manager failover at all.
Maybe you are using an HA that does not forge ip addresses?
The channel status table saves ip address in conname column and the MCA obviously uses it as (at least a part of) the key when it looks after saved statuses. If the connection is from another ip address there is no match and a new instance of the receiver is started. The problem is that after a failover the sender channel instance is still the same - or actually a reincarnation of it. Regardless if it's a multi-instance queue manager or a queue manager made highly available some other way.
It could be that the way receivers work has been changed in V 7.0.1 to protect multi-instance queue managers from exactly this situation and it's too smart now for highly available V6 senders ... |
|
| Back to top |
|
|
| sharonv |
| Posted: Sun Feb 09, 2014 2:33 am Post subject: same behavior in my system |
|
|
Apprentice
Joined: 03 Feb 2011
Posts: 27
|
HI
We recently moved from windows server to linux server running mq 7
i notice the same behavior on this issue
the reciever is shutting down after disconnection interval has been reached
when it starts up it looses syncronization
i know the clients didnt change at all , the only change was moving to this new linux server
i'm running MQ 7.0.1 11
what i see in the logs which i think might indicate an issue on the linux server
is that i get several AMQ 6209 and then AMQ6026 and they corrleated to the time i see the reciever channel is going down and up |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Feb 09, 2014 5:22 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If MQ is running inside an MSCS cluster the outgoing ip address is not the vip address but the ip of each of the nodes (see mscs clustering info). That might cause a problem on failover, especially if the other end of the channel is not on windows... Maybe they need to add a runmqsc script resetting the sender seq numbers in their failover scripts... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| sharonv |
| Posted: Sun Feb 09, 2014 6:05 am Post subject: |
|
|
Apprentice
Joined: 03 Feb 2011
Posts: 27
|
HI
we are running on the linux with veritas cluster
i did the folowwing test
i set the disconeect time on the client system (server channel) to 1 minute
started it and checked everything is working ( sent messages)
after a minute the sender channel went to inactive
i then send another message the sender went into retrying
checking the log , the message sequence number of the reciever side was higer and the channel was out of sync
, no failover on either side
just this simple secnario |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Feb 09, 2014 7:47 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Exactly what type of channel pair are you using - Sender Channel or Server Channel on the sending side? Receiver or Requestor on the receiving side?
It should work without needing a reset, even if one or both sides are using a O/S clustering solution like VCS or MSCS.
| Quote: |
message sequence number of the reciever side was higer and the channel was out of sync |
What are the details? Always off by one? Or, the sending side goes back to 1? Or the sending side stays correct but the receiving side goes up some random amount?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Tue Feb 11, 2014 7:11 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
| Please post the relevent Qmgr's qm.ini files. |
|
| Back to top |
|
|
|
|
