|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
AMQ9248 Socket error while Binding |
« View previous topic :: View next topic » |
Author |
Message
|
shashivarungupta |
Posted: Wed May 07, 2014 3:02 am Post subject: AMQ9248 Socket error while Binding |
|
|
 Grand Master
Joined: 24 Feb 2009 Posts: 1343 Location: Floating in space on a round rock.
|
Hi,
In one of the rare cases, I have encountered with following AMQ error, where the sender channel was defined long back and its LOCLADDR field had IP address x.y.z.w on it.
It was fixed later though by replacing the IP with Hostname.
I've seen following error in the queue manager error log, related to this matter.
---------------------------------------------------------------------------------------------
05/03/2014 03:05:29 PM - Process(17954.1) User(mqm) Program(runmqchl)
Host(hostservername)
AMQ9248: The program could not bind to a TCP/IP socket.
EXPLANATION:
The attempt to bind to socket 'x.y.z.w(0)' failed with return code 99. The
failing TCP/IP call was 'bind'. The most likely cause of this problem is
incorrect configuration of the TCP/IP local address or incorrect start and end
port parameters.
ACTION:
Contact the system administrator. If the problem persists save any generated
output files and use either the WMQ Support site:
http://www.ibm.com/software/integration/wmq/support/, or IBM Support Assistant
(ISA): http://www.ibm.com/software/support/isa/, to see whether a solution is
already available. If you are unable to find a match, contact your IBM support
center.
----- amqccita.c : 1359 -------------------------------------------------------
05/03/2014 03:05:29 PM - Process(17954.1) User(mqm) Program(runmqchl)
Host(hostservername)
AMQ9999: Channel program ended abnormally.
EXPLANATION:
Channel program 'TCP.CHANNEL.NAME' ended abnormally.
ACTION:
Look at previous error messages for channel program 'TCP.CHANNEL.NAME' in
the error files to determine the cause of the failure.
-----------------------------------------------------------------------------------
As per IBM manual, LOCLADDR could have IP / hostname on it. It is not mandate to have hostname as its value.
Still hostname has got IP x.y.z.w when I do nslookup on it.
The Qmgr attribute IPADDRV is IPv4.
The question is why LOCLADDR didn't resolve binding when IP was mentioned as its value , on that sender channel 'TCP.CHANNEL.NAME'?
What are the other possibilities when LOCLADDR doesn't work and shoots AMQ9248 ?
 _________________ *Life will beat you down, you need to decide to fight back or leave it. |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed May 07, 2014 4:34 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Well it really depends from where the connection was initiated.
Assume the connection was initiated from a different network where the ip is not routable or points to a different host (NAT involved).
The DNS name might then point to an IP that is different from the one shown on your MQ server but that routes correctly to it (Firewall + NAT + etc...).
This is why the raw IPV4 is not always advisable.  _________________ MQ & Broker admin |
|
Back to top |
|
 |
shashivarungupta |
Posted: Wed May 07, 2014 4:44 am Post subject: |
|
|
 Grand Master
Joined: 24 Feb 2009 Posts: 1343 Location: Floating in space on a round rock.
|
fjb_saper wrote: |
Well it really depends from where the connection was initiated.
Assume the connection was initiated from a different network where the ip is not routable or points to a different host (NAT involved). |
LOCLADDR had the connection IP of the host/server where the queue manager is defined. Or you can say LOCLADDR was local IP to host server where the queue manager is defined.
Code: |
As per the IBM manual 'This attribute specifies the local communications address for the channel.' Also...
'When LOCLADDR includes a network address, the address must be a network addresses belonging to a network interface on the system where the channel is run.' |
So, the connection was initiated from the server, in the network, where the queue manager/channel was running.
when I did 'nslookup hostservername' , I got following IP which was correctly mentioned in LOCLADDR of channel 'TCP.CHANNEL.NAME'.
IP = x.y.z.w
 _________________ *Life will beat you down, you need to decide to fight back or leave it. |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed May 07, 2014 4:50 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Something wrong in that server's ip stack that got circumvented by forcing DNS resolution?  _________________ MQ & Broker admin |
|
Back to top |
|
 |
shashivarungupta |
Posted: Wed May 07, 2014 4:58 am Post subject: |
|
|
 Grand Master
Joined: 24 Feb 2009 Posts: 1343 Location: Floating in space on a round rock.
|
fjb_saper wrote: |
Something wrong in that server's ip stack that got circumvented by forcing DNS resolution?  |
I doubt if I have that information.
When the problem has occurred , the channel was in retrying state with above mentioned error logs. AND when asked, network & firewall teams did mention that they didn't have encountered any issue with firewall / network at that time.
I am not sure what all was there in the IP stack for the hosting server.
The issue was fixed cause LOCLADDR's value was replaced with host name of that server as 'servername.domain.com'. I don't know why the IP was not getting resolved to hostname, whereas the hostname was.
 _________________ *Life will beat you down, you need to decide to fight back or leave it. |
|
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
|
|
|
|