| Author |
Message
|
| shashivarungupta |
 Posted: Fri Sep 24, 2010 5:47 am Post subject: Messages Eaten up on the way ! |
 |
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
Hi,
Here is the interesting case..
Between 2 qmgrs on diff. servers , a sender-receiver channel pair exists with SSL on it. (After implementing the SSL on them, did the Refresh Security for type SSL, once.)
Channel pair comes to the Running state.
Appl. wants to send the message from Qmgr A to Qmgr B, using RQD.
On qmgr A : qalias points to TARGQ i.e. RemoteQDef. which has XMITQ in its definition.
QALIAS > RQD > XMITQ
Suppose sender channel A.B is STOPPED.
Now, When appl. is putting the messages on qmgr A on Qalias (say 7 msgs), it goes to xmitq and there is pile up.
Now when I, START sender channel A.B it goes to RETRYING state and xmitq gets empty (that means messages are accepted over the sender side of the channel A.B).
When we check the status of Sender channel it says MSGS(7) , but after sometime sender channel comes to the RUNNING state, BUT messages do not get delivered to QLOCAL at qmgr B.
Messages do not go to DLQ (checked at both the ends) !
Messages are not on expected queues ! Where are they gone ??
*(MQv6.0.2.8, AIX5.3)
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Sep 24, 2010 5:56 am Post subject: Re: Messages Eaten up on the way ! |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| shashivarungupta wrote: |
| Messages are not on expected queues ! Where are they gone ?? |
Are the messages persistent (and don't[/b] say "yes, the queue has DEFPSIST(YES)"!!!)?! I mean what is the [u]actual persistence of the messages in question?
Do the messages expire?
| shashivarungupta wrote: |
| Messages do not go to DLQ (checked at both the ends) ! |
Did you look in SYSTEM.DEAD.LETTER.QUEUE or the dead letter queue the queue manager is actually using (if any)?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Fri Sep 24, 2010 6:30 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
beside what has already been asked .... are you using the message retry facility on the receiving end? if yes, then sometimes the channel is "running" but no messages are transferred (as the current batch is in the defined retry loop for a specific point fo time). then the channels falls back to retry, and on the next retry intervall the channel is "running" again as long as the receiving mca performs its put - retry.
xmitq seems to have 0 messages then, but "uncomitted messages" if you look at the queue status.
(if you stop (or stop-force) the sending channels, are the messages "back" in the senders xmitq ?!?
_________________
Regards, Butcher |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Fri Sep 24, 2010 9:16 am Post subject: Re: Messages Eaten up on the way ! |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| Vitor wrote: |
| shashivarungupta wrote: |
| Messages are not on expected queues ! Where are they gone ?? |
Are the messages persistent (and don't[/b] say "yes, the queue has DEFPSIST(YES)"!!!)?! I mean what is the [u]actual persistence of the messages in question?
Do the messages expire?
| shashivarungupta wrote: |
| Messages do not go to DLQ (checked at both the ends) ! |
Did you look in SYSTEM.DEAD.LETTER.QUEUE or the dead letter queue the queue manager is actually using (if any)? |
No, messages were not PERSISTENT and DEFPSIST was NO on that RQD.
Yes, the Qmgr was using the DLQ ( I did check it ) and Messages were not in it.
Messages were not expiring , I checked it too. BY looking at the MQMD of those messages.
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Fri Sep 24, 2010 9:21 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| Mr Butcher wrote: |
beside what has already been asked .... are you using the message retry facility on the receiving end? if yes, then sometimes the channel is "running" but no messages are transferred (as the current batch is in the defined retry loop for a specific point fo time). then the channels falls back to retry, and on the next retry intervall the channel is "running" again as long as the receiving mca performs its put - retry.
xmitq seems to have 0 messages then, but "uncomitted messages" if you look at the queue status.
(if you stop (or stop-force) the sending channels, are the messages "back" in the senders xmitq ?!? |
No, Message Retry is not ON on receiving end.
When I STOP the sender channel , messages are not coming back to it. BY the way.. as I said.. when I start the sender channel it goes in RETRY State for a while and comes to the RUNNING state automatically and messages gets lost within the network. No clue where !!
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Sep 24, 2010 9:27 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| shashivarungupta wrote: |
| Mr Butcher wrote: |
beside what has already been asked .... are you using the message retry facility on the receiving end? if yes, then sometimes the channel is "running" but no messages are transferred (as the current batch is in the defined retry loop for a specific point fo time). then the channels falls back to retry, and on the next retry intervall the channel is "running" again as long as the receiving mca performs its put - retry.
xmitq seems to have 0 messages then, but "uncomitted messages" if you look at the queue status.
(if you stop (or stop-force) the sending channels, are the messages "back" in the senders xmitq ?!? |
No, Message Retry is not ON on receiving end.
When I STOP the sender channel , messages are not coming back to it. BY the way.. as I said.. when I start the sender channel it goes in RETRY State for a while and comes to the RUNNING state automatically and messages gets lost within the network. No clue where !! |
If the messages are not persistent and there is a problem with the channel (as evidenced by the Retry state) the channel agent will end up discarding the non persistent messages in flight.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Sep 24, 2010 9:28 am Post subject: Re: Messages Eaten up on the way ! |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| shashivarungupta wrote: |
| [color=green]No, messages were not PERSISTENT and DEFPSIST was NO on that RQD. |
That's where they're gone then.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Fri Sep 24, 2010 9:28 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
and One more interesting thing I noticed.. that if I do GET(disabled) on xmitq and I start the sender channel, it sets the TRIGGER ON on xmitq ( where no Process Name is mentioned on it) but INITQ is there as system.channel.initq !!!
And again messages flows through the sender end, shows MSGS(7) on it ( when i hit display chs(A.B) all ) , A.B sender channels goes to retry and then in the Running state !
Also checked the channel's Receiving End and it shows MSGS(0) , that means Messages has been rejected over receiving end.
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Fri Sep 24, 2010 9:32 am Post subject: Re: Messages Eaten up on the way ! |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| Vitor wrote: |
| shashivarungupta wrote: |
| [color=green]No, messages were not PERSISTENT and DEFPSIST was NO on that RQD. |
That's where they're gone then. |
Ahh... that is , if DEFPSIST would have been YES then Channel would have been in RETRYING State ONLY !!!! And Messages were at xmitq. And Sender Channel would have been in INDOUBT(YES) state.
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Fri Sep 24, 2010 9:45 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| fjb_saper wrote: |
| shashivarungupta wrote: |
| Mr Butcher wrote: |
beside what has already been asked .... are you using the message retry facility on the receiving end? if yes, then sometimes the channel is "running" but no messages are transferred (as the current batch is in the defined retry loop for a specific point fo time). then the channels falls back to retry, and on the next retry intervall the channel is "running" again as long as the receiving mca performs its put - retry.
xmitq seems to have 0 messages then, but "uncomitted messages" if you look at the queue status.
(if you stop (or stop-force) the sending channels, are the messages "back" in the senders xmitq ?!? |
No, Message Retry is not ON on receiving end.
When I STOP the sender channel , messages are not coming back to it. BY the way.. as I said.. when I start the sender channel it goes in RETRY State for a while and comes to the RUNNING state automatically and messages gets lost within the network. No clue where !! |
If the messages are not persistent and there is a problem with the channel (as evidenced by the Retry state) the channel agent will end up discarding the non persistent messages in flight.
|
very nice quote.
Actually, if the problem would have been with Channel pair then it should not come to the Running State at all.
I did couple of things...
1. reset the channels seq. no.
2. I just STOPPED the channels and REFRESHED the Security for type SSL again.
and I believe reset 'seq.no to 1' had nothing to do with that because channel was coming up earlier.
And I think , refresh security did the Job for me, now.
But I think, WHY it DID'NT work when I first refreshed the security for ssl type after configuring the ssl on the channel pair !!!!
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Sep 24, 2010 10:06 am Post subject: Re: Messages Eaten up on the way ! |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| shashivarungupta wrote: |
| Ahh... that is , if DEFPSIST would have been YES then Channel would have been in RETRYING State ONLY !!!! |
At risk of sounding like a cracked record (or a CD with a spot of dirt) that's not the persistence value of the message; just the value that will be used if the application chooses not to choose.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Sep 24, 2010 1:20 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Is the sender channel attribute NPMSPEED(FAST)?
Is there a DLQ defined at the receiving end? Is the name of the DLQ defined in the qmgr object at the receiving end?
_________________
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 |
|
|
| shashivarungupta |
| Posted: Mon Sep 27, 2010 7:54 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| bruce2359 wrote: |
| Is the sender channel attribute NPMSPEED(FAST)? |
Nope.
| bruce2359 wrote: |
| Is there a DLQ defined at the receiving end? Is the name of the DLQ defined in the qmgr object at the receiving end? |
Yes, DLQ is defined there and its mentioned in qmgr obj.
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Mon Sep 27, 2010 8:04 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
also checked the scenario by setting the DEFPSIST to YES, then the Sender channel was in INDOUBT(YES) and messages were not being descarded and as I said before channel remained in RETRYING state.
And was able to solve this issue, by refresh security type for ssl (on both qmgrs). I'm not sure why it did'nt work first time when I did the SSL setup on the channels.
Is it required to stop&start the channel and hit refresh security ssl on qmgrs, after setting the ssl over the channel and before sending the first message b/w qmgrs ?
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Sep 27, 2010 8:36 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| shashivarungupta wrote: |
| ...Is it required to stop&start the channel and hit refresh security ssl on qmgrs, after setting the ssl over the channel and before sending the first message b/w qmgrs ? |
No. The refresh will cause the channels to be restarted, but if you have a lot of them, it can take some time.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
|
|
