| Author |
Message
|
| smurthy485 |
 Posted: Tue May 22, 2007 8:42 am Post subject: Channel not able to transmit data |
 |
|
Newbie
Joined: 22 May 2007
Posts: 8
|
Hi,
I have an scenario where we are migrating from a old router which is going end of service to a new router.
On the exisiting environment our QMGR is able to connect to the other QMGR through the VPN tunnel using a SDR / RCVR pair through the old router. We have firewall rules in place between the Queue Managers.
When we try to point the SDR Channel to the new router ( basically changing the conname on the SDR channel ) the SDR and RCVR establish a connection and starts running. But when the application starts sending messages the SDR channel goes into Retrying then binding and starts running again. When the messages are trying to be sent the SDR channel goes into retrying for 30 Secs, binding for 30 secs and running for 1 min and keeps repeating this cycle. The messages are stuck on my XMIT.
The error logs shows
Sender Channel
AMQ9206: Error sending data to host xx.xx.xxx.xx
EXPLANATION:
An error occurred sending data over TCP/IP to xx.xx.xxx.xx. This may be due to
a communications failure.
ACTION:
The return code from the TCP/IP(send) call was 10054 X('2746'). Record these
values and tell your systems administrator.
Receiver Channel
17/05/07 03:11:13 PM
AMQ9213: A communications error for TCP/IP occurred.
EXPLANATION:
An unexpected error occurred in communications.
ACTION:
The return code from the TCP/IP(select) [TIMEOUT] 360 seconds call was 0 (X'0'). Record these values and tell the systems administrator.
Everything starts working fine when we go back out the change and revert back to the old setting.
Has anyone faced this situation. Why would the Sender channel be able to connect but not be able to transmit data?
Thanks
Sri |
|
| Back to top |
|
 |
| rparti |
| Posted: Tue May 22, 2007 9:29 am Post subject: |
|
|
Voyager
Joined: 05 Oct 2005
Posts: 86
Location: U.S.A.
|
|
| Back to top |
|
|
| smurthy485 |
| Posted: Tue May 22, 2007 10:19 am Post subject: |
|
|
Newbie
Joined: 22 May 2007
Posts: 8
|
Thanks for the reply.
We have already tried Stopping the channels and restarting.
The Channels establish connection, but go into the cycle of retrying / binding and running once the application puts messages to be sent across. |
|
| Back to top |
|
|
| tleichen |
| Posted: Tue May 22, 2007 10:47 am Post subject: Re: Channel not able to transmit data |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
| smurthy485 wrote: |
| ...When we try to point the SDR Channel to the new router ( basically changing the conname on the SDR channel ) the SDR and RCVR establish a connection and starts running. But when the application starts sending messages the SDR channel goes into Retrying then binding and starts running again. When the messages are trying to be sent the SDR channel goes into retrying for 30 Secs, binding for 30 secs and running for 1 min and keeps repeating this cycle. The messages are stuck on my XMIT... |
Prior to switching routers did you stop the channel? Also, after you made the switch, did you do a channel reset before sending any data over it? 
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| smurthy485 |
| Posted: Tue May 22, 2007 11:29 am Post subject: |
|
|
Newbie
Joined: 22 May 2007
Posts: 8
|
We used the following script to make the change
STOP CHANNEL(CHL_Name) MODE(FORCE)
ALTER CHANNEL(CHL_Name) CHLTYPE(SDR) CONNAME('xx.xx.xxx.xx(xxxx)')
RESET CHANNEL(CHL_Name) SEQNUM(1)
START CHANNEL(CHL_Name)
I am able to send messages using amqsput, but the application messages are not going through the new connection.
Thanks
Sri |
|
| Back to top |
|
|
| rparti |
| Posted: Tue May 22, 2007 11:49 am Post subject: |
|
|
Voyager
Joined: 05 Oct 2005
Posts: 86
Location: U.S.A.
|
| smurthy485 wrote: |
I am able to send messages using amqsput, but the application messages are not going through the new connection.
|
Could it be an authentication issue?
amqsput can send the data obviously using the profile that u are logged in as.
Maybe the application is using a different profile? |
|
| Back to top |
|
|
| smurthy485 |
| Posted: Tue May 22, 2007 12:27 pm Post subject: |
|
|
Newbie
Joined: 22 May 2007
Posts: 8
|
I dont think it is an authentication issue as there are no errors pointing to that.
The error logs point to a TCP/IP issue, but the problem occurs only when there is data to be sent. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue May 22, 2007 12:32 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It sounds like maybe the firewall is not playing nice.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| smurthy485 |
| Posted: Tue May 22, 2007 1:28 pm Post subject: |
|
|
Newbie
Joined: 22 May 2007
Posts: 8
|
| I discussed with the Network admins who set up the Firewall and they say everything is working fine on their side. |
|
| Back to top |
|
|
| rparti |
| Posted: Tue May 22, 2007 1:42 pm Post subject: |
|
|
Voyager
Joined: 05 Oct 2005
Posts: 86
Location: U.S.A.
|
I think it is some network/firewall issue
Hence, u see this
The return code from the TCP/IP(select) [TIMEOUT] 360 seconds call was 0 (X'0'). Record these values and tell the systems administrator.
The system admin needs to look at it more closely. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Tue May 22, 2007 2:31 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| Quote: |
| I discussed with the Network admins who set up the Firewall and they say everything is working fine on their side. |
They always say that. I have never come across a network administrator who admits there is anything wrong with the network until you get the thumbscrews out.
Step back and look at what has changed - the network/router layer. The channel starts, so the link is capable of handling small packets. When larger msgs flow, the link drops. Clearly, there is some misconfiguration somewhere which allows small amounts of data to pass, but blocks large amounts. I do not know very much about networks, but I think the MTU (?) size may be blocking the larger packets.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| smurthy485 |
| Posted: Tue May 22, 2007 5:17 pm Post subject: |
|
|
Newbie
Joined: 22 May 2007
Posts: 8
|
As you said the network admin is very adamant. As per his logic since the Channel is making a connection the network is ready and working well.
Is there any other test i can carryout from a MQ perspective. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed May 23, 2007 1:31 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| smurthy485 wrote: |
As you said the network admin is very adamant. As per his logic since the Channel is making a connection the network is ready and working well.
Is there any other test i can carryout from a MQ perspective. |
Try and telnet to the destination host and MQlistenerport.
If you cannot establish a connection tell your network admin the firewall needs to be open both ways.
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| smurthy485 |
| Posted: Thu May 24, 2007 6:05 am Post subject: |
|
|
Newbie
Joined: 22 May 2007
Posts: 8
|
I did a telnet and it works.
If my amqsput binaries are going through it must be a issue with the way the firewall rules are set up. What size messages are allowed to pass through. Any thoughts on this ?
We are trying to put messages of various sizes and see at what stage the messages dont go through.
Thanks
Sri |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu May 24, 2007 2:36 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
make sure that the max msg size on the channels corresponds at both ends.
Make sure the max msg size of the xmitq <= chl max msg size
Make sure the max msg size of the receiving queue >= max msg size on chl.
Finally make sure that the DLQs have also an appropriate max msg size...
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
