| Author |
Message
|
| dzifchock |
 Posted: Tue Apr 29, 2008 1:06 pm Post subject: 2 sender to 1 receiver scenario mqv6 |
 |
|
Apprentice
Joined: 21 Feb 2007
Posts: 41
|
We have had a 2 sender (windows) 1 receiver (HPUX) setup for quite some time. The two senders being on different queue managers on different physical servers. Every once in awhile we would have a sender go into retry mode because of message sequence number differences with no other errors leading up to this, and sometimes there is a scratchpad error stating that the object %CHLBATCH.# is in use. These channels use non persistent messaging and are in fast mode, once they get to the destination xmitq they become persistent (this being the first time we have actually lost messages). We ran into issues where sending persistent messages over this 2 to 1 setup didnt work.
It seems to be a viable supported setup, however this message sequence issue has shown up more often in in the last few months. A reset channel sequence number on the retrying sender fixes the issue but then the issue eventually comes up on the other queue manager's sender channel. I then found the below information on IBM's support site, one of the causes of this AMQ9526 can be two instances of the same receiver channel.
AMQ9526 Message sequence number error for channel <insert_3>
Explanation:
The local and remote queue managers do not agree on the next message sequence number. A message with sequence number <insert_1> has been sent when sequence number <insert_2> was expected.
Response:
Determine the cause of the inconsistency. It could be that the synchronization information has become damaged, or has been backed out to a previous version. If the situation cannot be resolved, the sequence number can be manually reset at the sending end of the channel using the RESET CHANNEL
command.
Most common cause:
Manually resetting a receiver channel message sequence number
Deleting and redefining a channel
Two instances of the same Receiver channel
Diagnostic hints and tips:
Never reset a Receiver channel's message sequence number.
Reset the Sender channel message sequence number to correct this situation.
My question is, does anyone else have this type of setup and experience similar problems? I'm trying to push splitting up this 2 to 1 environment and setup a 1 to 1 to see if this fixes the issue but am looking for some more hard information to back my cause.
Regards,
Dave |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Apr 30, 2008 12:30 am Post subject: Re: 2 sender to 1 receiver scenario mqv6 |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| dzifchock wrote: |
| once they get to the destination xmitq they become persistent (this being the first time we have actually lost messages). |
No, they don't. Message persistence is set when the message is put & isn't changed by any default persistence settings of any queues it may pass through. Also the message doesn't enter the xmitq on the receiving side.
| dzifchock wrote: |
| We ran into issues where sending persistent messages over this 2 to 1 setup didnt work. |
What issues? I've used this kind of 2 into 1 setup with persistent messaging and it works fine.
| dzifchock wrote: |
My question is, does anyone else have this type of setup and experience similar problems? I'm trying to push splitting up this 2 to 1 environment and setup a 1 to 1 to see if this fixes the issue but am looking for some more hard information to back my cause.
|
I've been on sites using this kind of setup (with persistent messages) and there have been no problems. It does have a number of features you need to be aware of; noteably a single point of failure on the receiver side. If the receiver channel goes down all message traffic into that box potentially stops, it's also less easy to obtain channel status at a glance. The rational I've most often heard is to eliminate channels like a poor man's cluster, but IMHO if that's what you want to do build a real cluster.
Having said all that AFAIK it's a legal & supported way of point to point clustering & I've seen it working. When you say "one receiver" you do actually mean a single receiver on the target box don't you? Is all the WMQ in this set up v6, and all with maintenance applied.?
I wonder if the "issues" you had with persistent messages were another symptom of a configuration problem you've got someplace.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| dzifchock |
| Posted: Wed Apr 30, 2008 6:59 am Post subject: Re: 2 sender to 1 receiver scenario mqv6 |
|
|
Apprentice
Joined: 21 Feb 2007
Posts: 41
|
| Vitor wrote: |
No, they don't. Message persistence is set when the message is put & isn't changed by any default persistence settings of any queues it may pass through. Also the message doesn't enter the xmitq on the receiving side.
|
Thanks for your reply, I won't argue that we have a configuration problem  . So with the above being said, when a message is put onto a remote queue with persistence turned on it passes to the xmitq which is set to non-persistent which passes over the channel and put to the destined localq which is persistent. So because the xmitq on the sender side is non-persistent the message is NOT actually persistent when put to the local queue on the other queue manager, but when it reaches the destined local queue which has persistence turned on, if the queue manager goes down the message should still be retained because that queue is persistent? I need to do some reading on persistence....
| Vitor wrote: |
| What issues? I've used this kind of 2 into 1 setup with persistent messaging and it works fine. |
It has been awhile since this has been setup, but we kept getting scratchpad errors and they went away when we turned persistence off. I had a PMR open for it but it never got anywhere and was eventually closed.
| Vitor wrote: |
| Having said all that AFAIK it's a legal & supported way of point to point clustering & I've seen it working. When you say "one receiver" you do actually mean a single receiver on the target box don't you? Is all the WMQ in this set up v6, and all with maintenance applied.? |
Yes, one single receiver on the target box. All the WMQ setups are 6.0.2.2
We just upgraded about 5 months ago from 5.3 csd13. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Apr 30, 2008 7:08 am Post subject: Re: 2 sender to 1 receiver scenario mqv6 |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| dzifchock wrote: |
| So with the above being said, when a message is put onto a remote queue with persistence turned on |
At this point, the message is persistent, forever.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Apr 30, 2008 7:16 am Post subject: Re: 2 sender to 1 receiver scenario mqv6 |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| dzifchock wrote: |
| So because the xmitq on the sender side is non-persistent the message is NOT actually persistent |
| Vitor wrote: |
| Message persistence is set when the message is put & isn't changed by any default persistence settings of any queues it may pass through. |
So if the message is put to a remote or alias queue, the default persistence of the xmitq is completely, utterly irrelevant because the message's persistance is already set.
| dzifchock wrote: |
| It has been awhile since this has been setup, but we kept getting scratchpad errors and they went away when we turned persistence off. |
If you've got the setup I described above, changing the default persistence of the xmitq had no effect on the messages or the problem!
| dzifchock wrote: |
Yes, one single receiver on the target box. All the WMQ setups are 6.0.2.2
We just upgraded about 5 months ago from 5.3 csd13. |
I've used this setup on v5.3.11 & v6.0.2.0. I'll admit the v6 install was a dev one, but the v5.3 was production & really rather heavily loaded.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| dzifchock |
| Posted: Tue May 06, 2008 10:42 am Post subject: A little more information |
|
|
Apprentice
Joined: 21 Feb 2007
Posts: 41
|
I have a little more information on our 2 to 1 channel problems. We have a Siebel product which has MQ components which are tied into MQ. This product is clustered at the Siebel level each having their own queue manager on each side of the cluster. Both of these queue managers are named the same do to a siebel configuration constraint where there is only 1 option for a queue manager name.
Our messages are persistent, so when the receiver channel receives the message it tries to write to a scratchpad object, please correct me if im wrong here. It seems there is only 1 scratchpad object for the 2 sender channels. The error in the log before we get the sequence issue is:
AMQ9588: Program cannot update queue manager object.
EXPLANATION:
The attempt to update object '%CHLBATCH.16' on queue manager
'x.queue.manager' failed with reason code 2042.
ACTION:
Use the standard facilities supplied with your system to record the problem
identifier. Contact your IBM support center.
2042 being object in use.
I know it was said that people use this 2 to 1 scenario in production without any problems. I am now thinking that because the queue manager name is the same on both of the sender channels it is not creating its own scratchpad and thus receives an object in use error.
I have opened a case with IBM and am interested to hear what they have to say. |
|
| Back to top |
|
|
| dzifchock |
| Posted: Fri May 16, 2008 7:30 am Post subject: Resolved |
|
|
Apprentice
Joined: 21 Feb 2007
Posts: 41
|
| Our setup has both remote queue managers using the same name even though they are on different hosts. This is an unsupported config. With Persistence, MQ indexes channel sync info based on remote qmgr name. So thats why we were getting object in use followed by channel sequence numbers. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon May 19, 2008 11:53 am Post subject: Re: Resolved |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| dzifchock wrote: |
| Our setup has both remote queue managers using the same name even though they are on different hosts. This is an unsupported config. |
Just to be clear, having 2 senders into a single receiver is supported. 2 queue managers with the same name is not.
I think that's what you meant, but wanted to underline it. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| standa |
| Posted: Thu May 22, 2008 12:08 am Post subject: Is it documented? |
|
|
Novice
Joined: 08 Sep 2006
Posts: 10
Location: CZECHREP
|
Is it documented somewhere? "It" = 2 (or more?) senders to 1 receiver scenario ?
If I list channel info, I can see CURSEQNO number but there is no coupling to some specific queue manager. So if one of the senders pointing to the receiver is in-doubt, how can I display info referencing the queue manager with in-doubt channel?
_________________
standa. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu May 22, 2008 12:15 am Post subject: Re: Is it documented? |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| standa wrote: |
| So if one of the senders pointing to the receiver is in-doubt, how can I display info referencing the queue manager with in-doubt channel? |
With difficulty.
Please see my post above. This configuration works, it is supported (IIRC the Intercommunication manual simply says each end of the channel must have the same name not that they must be unique) and like I say above I've used it.
This doesn't mean I think it's best practice or even a good idea, for reasons including the one you've found! If you obtain the channel status of the receiving end this should list all the statuses (stati?) including the indoubt one.
It's a pain though.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| dzifchock |
| Posted: Thu May 22, 2008 7:39 am Post subject: |
|
|
Apprentice
Joined: 21 Feb 2007
Posts: 41
|
| Vitor, yes that is what I meant. 2 (senders) to 1 (receiver) is supported, but have the qmgrs named the same w/using persistent messaging is not. IBM Support said that they were going to append their documentation to specify this. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Thu May 22, 2008 5:31 pm Post subject: Re: 2 sender to 1 receiver scenario mqv6 |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| Vitor wrote: |
| dzifchock wrote: |
| So because the xmitq on the sender side is non-persistent the message is NOT actually persistent |
| Vitor wrote: |
| Message persistence is set when the message is put & isn't changed by any default persistence settings of any queues it may pass through. |
So if the message is put to a remote or alias queue, the default persistence of the xmitq is completely, utterly irrelevant because the message's persistance is already set.
|
The persistence of a message is actually determined by the MQMD settings at the time the message is put by the application, and it can't be changed on a message after it has been put on a queue or transferred over a channel.
MQMD.Persistence can be set to "persistent", "non persistent" or "as per the queue definition". The 3rd option is the default, where MQ determines the persistence from the DEFPSIST setting on the queue object (QLOCAL, QMODEL, QALIAS or QREMOTE).
_________________
Glenn |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu May 22, 2008 7:04 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
The PERSISTENCE_AS_Q_DEF determines the persistence from the DEFPSIST setting on the FIRST queue object that the application explicitly MQOPENs (QLOCAL, QMODEL, QALIAS or QREMOTE), and not the persistence setting of the resolved name - the resolved xmit queue from an MQOPEN of a qremote definition.
_________________
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 |
|
|
|
|
