Author |
Message
|
widnewbie |
Posted: Wed Jan 21, 2009 11:59 pm Post subject: MQ intercommunication fails |
|
|
Newbie
Joined: 21 Jan 2009 Posts: 2
|
I have set up 2 queue managers, say Q1 and Q2, on my system (Note that its 1 single windows box, so both the QMs reside on the same physical system).
And have set up 1 transmission queue (XMITQ), 1 remote queue (REMOTEQ) and 1 sender channer (q12q2) on Q1
Also I have set up 1 receiver queue (RECEIVERQ) and 1 receiver channel (q12q2) on the other queue manager Q2.
So this setup should be fine and I should ideally be able to send messages from Q1 to Q2. And in fact this setup was running fine. However, currently whenever, I try to start the sender channel, it keeps retrying.
On running default tests, I got 2 errors -
5 errors have been written to FFST directory
Channel(q12q2) returned error(4016) when pinged
I am using MQ 7, but, I believe, the version would not play any role.
Any help would be appreciated. |
|
Back to top |
|
 |
Vitor |
Posted: Thu Jan 22, 2009 12:16 am Post subject: Re: MQ intercommunication fails |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
widnewbie wrote: |
5 errors have been written to FFST directory
|
Check the ProbeId in any FDC files, and ensure any firewalls on the machine will allow communication between the ports you're using. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
rgprasanna |
Posted: Thu Jan 22, 2009 1:45 am Post subject: |
|
|
 Voyager
Joined: 02 May 2007 Posts: 91 Location: Chennai - India
|
also you may check the listener program is running or not? or ensure the port no is listening by using netstat -a command _________________ Prasanna |
|
Back to top |
|
 |
widnewbie |
Posted: Thu Jan 22, 2009 3:05 am Post subject: |
|
|
Newbie
Joined: 21 Jan 2009 Posts: 2
|
Firewall is not really an issue, as both the queue managers are running on the same system and in any case the firewall is already disabled.
Listener is definitely running.
The ProbeId is UN514000. But I dont know, how should ProbeId be used for debugging the issue. |
|
Back to top |
|
 |
Vitor |
Posted: Thu Jan 22, 2009 3:14 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
widnewbie wrote: |
The ProbeId is UN514000. But I dont know, how should ProbeId be used for debugging the issue. |
Typically one asks Mr Google, but he's not heard of that one.
Please post the box at the top of the FDC file (where the ProbeId is); not the whole stack trace which is only of use to IBM.
Also check the queue manager logs for channel related errors. You said it was running fine but now the sender retries; look for configuration changes since the last successful channel. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
masteringmq |
Posted: Thu Jan 22, 2009 5:45 am Post subject: |
|
|
Master
Joined: 20 Oct 2008 Posts: 200
|
Channel retrying possibilities:
1. Firewall issue
2. Channel definition incorrect
3. SSL Cert expired
4. SSL Cert updated
5. Both end of the channel is unable to negotiate the encryption protocol.
6. Network incompatibility (IPv6 vs IPv4)
7. Channel not used for a very long time
8. Listener not up
9. Network down so connection is down
10. Channel not triggered
11. Incorrect userid
- Message userid - PUTAUT(CTX)
- MCAUSER - PUTAUT(DEF)
Last edited by masteringmq on Thu Jan 22, 2009 10:16 pm; edited 2 times in total |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Jan 22, 2009 2:26 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
masteringmq wrote: |
Channel retrying possibilities:
1. Firewall issue
2. Channel definition incorrect
3. SSL Cert expired
4. SSL Cert updated
5. Both end of the channel is unable to negotiate the encryption protocol.
6. Network incompatibility (IPv6 vs IPv4)
7. Channel not used for a very long time
8. Listener not up
9. Network down so connection is down |
How about channel not triggered? _________________ MQ & Broker admin |
|
Back to top |
|
 |
Vitor |
Posted: Thu Jan 22, 2009 2:54 pm Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
fjb_saper wrote: |
How about channel not triggered? |
Wouldn't that give you a channel that remained inactive?  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
zhanghz |
Posted: Thu Jan 22, 2009 4:47 pm Post subject: |
|
|
Disciple
Joined: 17 Jun 2008 Posts: 186
|
masteringmq wrote: |
Channel retrying possibilities:
...
7. Channel not used for a very long time
... |
Can anyone elaborate on this? |
|
Back to top |
|
 |
masteringmq |
Posted: Thu Jan 22, 2009 6:52 pm Post subject: |
|
|
Master
Joined: 20 Oct 2008 Posts: 200
|
Quote: |
7. Channel not used for a very long time |
Well there is a channel in our box that was not used for several months. I had to reset the channel and the status changed from retrying to running.
Quote: |
How about channel not triggered? |
Please check the transmission queue definition. It should look like:
DEFINE QL(A.XMIT) USAGE(XMITQ) TRIGGER TRIGTYPE(FIRST) TRIGDATA(<channelname>) |
|
Back to top |
|
 |
masteringmq |
Posted: Thu Jan 22, 2009 6:58 pm Post subject: |
|
|
Master
Joined: 20 Oct 2008 Posts: 200
|
Could the OAM (Object Authority Manager) applied on the QM be causing the channel to retry?. Also after applying the OAM on the QM, without running a REFRESH SECURITY command, could this cause the channel to retry?. Can anyone comment on this?. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Thu Jan 22, 2009 9:43 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
masteringmq wrote: |
Quote: |
7. Channel not used for a very long time |
Well there is a channel in our box that was not used for several months. I had to reset the channel and the status changed from retrying to running.
|
There is nothing in the MQ code base that would cause a channel to go retrying strictly because it hadn't been used for x days / weeks / months or years. Your channel had problems for reasons unrelated to the length of time since it ran. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
PeterPotkay |
Posted: Thu Jan 22, 2009 9:44 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
masteringmq wrote: |
Could the OAM (Object Authority Manager) applied on the QM be causing the channel to retry?. Also after applying the OAM on the QM, without running a REFRESH SECURITY command, could this cause the channel to retry?. Can anyone comment on this?. |
Put a bogus ID in the MCAUSER of the RCVR channel and watch the SNDR retry. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
bruce2359 |
Posted: Thu Jan 22, 2009 9:45 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Quote: |
7. Channel not used for a very long time ... Well there is a channel in our box that was not used for several months. I had to reset the channel and the status changed from retrying to running.
|
MQ objects don't become stale with age. A reset may have been necessary for other reasons that have been discussed here many times. _________________ 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 |
|
 |
zhanghz |
Posted: Fri Jan 23, 2009 1:57 am Post subject: |
|
|
Disciple
Joined: 17 Jun 2008 Posts: 186
|
masteringmq wrote: |
Quote: |
7. Channel not used for a very long time |
Well there is a channel in our box that was not used for several months. I had to reset the channel and the status changed from retrying to running.
... |
I also don't think the retrying is related to "not used for a very long time". RESET CHANNEL SEQNUM is necessary when SEQNUM on both side does not match. Usually SEQNUM does not match when there is an IP change.. |
|
Back to top |
|
 |
|