| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Listener issue |
« View previous topic :: View next topic » |
| Author |
Message
|
| Al Pacino |
 Posted: Mon Jun 12, 2006 10:07 am Post subject: Listener issue |
 |
|
Centurion
Joined: 19 Aug 2005
Posts: 114
|
Hi there ,
We have a channel going from mainframe to an Intel box . Queue manager on the Intel box was restarted and the sender channel on the mainframe went into retry status. When the Queue manager restated the listener on the Intel server would start complaining that something else is using port 1414. I believe it is still the mainframe holding the old process since it takes longer for it to time out. It only happen with listeners listening to channels connection coming from mainframe. If we wait a little and restart the listener , then will get it to work. Is there anyway to avoid this issue, seems like the listener is restarting before the old process died. Can someone advice ? thanks
MQ 5.3 CSD 10
Windows Server 2003
_________________
"We can't solve problems by using the same kind of thinking we used
when we created them." |
|
| Back to top |
|
 |
| vennela |
| Posted: Mon Jun 12, 2006 10:15 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| I have seen this kind of problem before. Except the problem was in between an AIX and NCR's MP-RAS. The only solution I knew was to wait. On the other hand sometimes, AIX admins did something to get rid of the open sockets. You should talk to your Windows admin and see if they have someway of getting rid of them. |
|
| Back to top |
|
|
| tleichen |
| Posted: Mon Jun 12, 2006 12:13 pm Post subject: Re: Listener issue |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
What you are dealing with is the socket timeouts at various levels of TCP/IP. I'm not a network guru, but have dealt with this on various platforms. You can tweak the IP configuration, but you will still probably wind up taking other action to avoid the conflict. On most mainframe systems, we had a programmed wait set up when we cycled a queue manager, to avoid things starting back up too soon. Keep in mind, if the system really gets bogged down, it may take TCP even longer than what is typical to shut things down. 
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| dutchman |
| Posted: Tue Jun 13, 2006 5:05 am Post subject: |
|
|
Acolyte
Joined: 15 May 2001
Posts: 71
Location: Netherlands
|
Hi,
Can I just take this back to first principles...
You wrote
1. "Queue manager on the Intel box was restarted and the sender channel on the mainframe went into retry status."
- yes, as expected
2. "When the Queue manager restated the listener ..."
- When you actioned 1, did you not only stop the queue manager but also the listener? The listener can remain running even when the qmgr is down.
Cheers ... R |
|
| Back to top |
|
|
| Al Pacino |
| Posted: Tue Jun 13, 2006 5:50 am Post subject: |
|
|
Centurion
Joined: 19 Aug 2005
Posts: 114
|
It is a good point you brought that the listener might still running when the queue manager started , however , that was not the case since I had to manually start it. Also, I confirmed the box was rebooted at the time which was the cause for the QM to go down , but still don't understand why port 1414 was in used when the listener tried to start after the QM started .
_________________
"We can't solve problems by using the same kind of thinking we used
when we created them." |
|
| 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
|
|
|
|
