| Author |
Message
|
| tychak |
 Posted: Mon May 29, 2006 7:19 pm Post subject: AMQ9213: A communications error for TCP/IP occurred |
 |
|
Novice
Joined: 16 Mar 2004
Posts: 19
|
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] 2 seconds call was 0 (X'0').
Record these values and tell the systems administrator.
The channels are set with HBINT(1) and DISCINT(0) to keep the channels always ACTIVE. However, the channels are always down every 1-2 hours and the above error message is found. What does the error message mean?
Thanks. |
|
| Back to top |
|
 |
| vinoth |
| Posted: Mon May 29, 2006 10:30 pm Post subject: |
|
|
Apprentice
Joined: 03 Mar 2005
Posts: 31
|
please post ur Channel definition
Vinoth |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Tue May 30, 2006 5:52 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
The message means that you were waiting for a response from the other end and didn't get one.
The
| Quote: |
| [TIMEOUT] 2 seconds |
is the giveaway.
I would investigate the other end to see why it keeps on dropping you although only giving it 2 seconds seems a little bit 'aggressive' to me. (You can calculate the duration for timeout as twice the HBINIT value)
While I understand the idea of wanting to keep the channel ACTIVE having a DISCINT(0) is often asking for trouble for just the reason you are experiencing. Personally I trigger all the channels and have a DISCINT specified depending on the activity.
Having said that if you can't bear the pain of the overhead for starting the channel then you will need to address what is happening at the 'other end' or be less aggressive on the heartbeat intervals. |
|
| Back to top |
|
|
| tleichen |
| Posted: Wed May 31, 2006 9:43 am Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
I don't know how many times I've seen this and I don't know what people's motivation is to set channel timeout values so low. There really is no viable reason for it. Because of network and processor delays by other tasks, etc., it is normally not viable to set a timeout much less than 10 seconds. I mean, what would it gain anyone to do so? 
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| tychak |
| Posted: Wed May 31, 2006 8:06 pm Post subject: |
|
|
Novice
Joined: 16 Mar 2004
Posts: 19
|
Here's the channel definition:
CHANNEL(xxxxxxxxxxxxxx) CHLTYPE(SDR)
TRPTYPE(TCP) DESCR( )
XMITQ(xxxxxxxxxxxxx) MCANAME( )
MODENAME( ) TPNAME( )
BATCHSZ(50) DISCINT(0)
SHORTRTY(1200) SHORTTMR(5)
LONGRTY(999999999) LONGTMR(30)
SCYEXIT( ) SEQWRAP(999999999)
MAXMSGL(4194304) CONVERT(NO)
SCYDATA( ) USERID( )
PASSWORD( ) MCATYPE(PROCESS)
CONNAME(xxxxxxxx) HBINT(1)
BATCHINT(0) NPMSPEED(FAST)
SSLCIPH( ) BATCHHB(0)
LOCLADDR( ) KAINT(AUTO)
MCAUSER( ) ALTDATE(2005-06-01)
ALTTIME(16.32.31) SSLPEER()
MSGEXIT( )
SENDEXIT( )
RCVEXIT( )
MSGDATA( )
SENDDATA( )
RCVDATA( )
In my situation:
1. If I change DISINT to 120, the channel will be disconnected every 120 seconds. If I set it to 0, the channel will be disconnected about every 1-2 hours.
2. If the channel is not available, I have to tell application program to use another channel to send the data to another queue manager. So, I'm checking at the status of the channels all the time.
Is there other ways to better than setting HBINT(1) and DISCINT(0)?
Thanks for your advice! |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jun 01, 2006 5:14 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| tychak wrote: |
If I set it to 0, the channel will be disconnected about every 1-2 hours.
|
That's not true. Why do you think that?(hint:read the manuals)
| tychak wrote: |
2. If the channel is not available, I have to tell application program to use another channel to send the data to another queue manager.
|
That's not true. Applications don't care about Sender channels. They have no way of knowing about SNDR channels. All they should care is whether their put worked. Whether the channel is running or not to take the messages from the XMITQ is not their problem.
| tychak wrote: |
Is there other ways to better than setting HBINT(1) and DISCINT(0)?
|
You really need to read about the basics of MQ. Look for the MQ manual called Intercommunications. You are lacking a basic understanding of how MQ channels work.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| tychak |
| Posted: Mon Jun 12, 2006 9:10 pm Post subject: |
|
|
Novice
Joined: 16 Mar 2004
Posts: 19
|
| Quote: |
That's not true. Why do you think that?(hint:read the manuals)
|
That's what I observed in my servers.
| Quote: |
That's not true. Applications don't care about Sender channels. They have no way of knowing about SNDR channels. All they should care is whether their put worked. Whether the channel is running or not to take the messages from the XMITQ is not their problem.
|
Let me explain. QM A connects to QM B and QM C. If the channels between QM A and B are running, application program will send the message to QM B. If the channels are down, then it will send the message to QM C. Application will check the channel status periodically before sending out the message. It's done by writing program with MQAI to query the channel status.
Thanks very much for your advice. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jun 13, 2006 3:27 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Sounds to me you need to read the intercommunications and the clustering manual.
You can achieve just what you are looking for through clustering.
However in your case the channel not running after 2 hours has a cause that is not related to MQ, assuming of course that the target system is up and running. Anyway I would use a triggered channel. Just for that cause.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| tychak |
| Posted: Tue Jun 13, 2006 8:03 pm Post subject: |
|
|
Novice
Joined: 16 Mar 2004
Posts: 19
|
| Quote: |
Sounds to me you need to read the intercommunications and the clustering manual.
|
Clustering cannot be used in my case. For simplicity, if the application knows that the channel is active, then it will put the message to the queue manager. If the channel is not active, it will not put the message to the queue manager and process the user request in another way.
| Quote: |
| However in your case the channel not running after 2 hours has a cause that is not related to MQ, assuming of course that the target system is up and running. Anyway |
The error "AMQ9213: A communications error for TCP/IP occurred." occurs and the channel is down.
| Quote: |
I would use a triggered channel. Just for that cause.
|
I've setup triggering in the transmission queue to start an inactive channel when there's message. However, the channel is not active before the application tries to put a message to the queue manager. Is this the triggered channel you're talking about?
Thanks very much for your advise. |
|
| Back to top |
|
|
| EddieA |
| Posted: Wed Jun 14, 2006 12:46 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| If I set it to 0, the channel will be disconnected about every 1-2 hours. |
That sounds more like a firewall issue.
| Quote: |
| Let me explain. QM A connects to QM B and QM C. If the channels between QM A and B are running, application program will send the message to QM B. If the channels are down, then it will send the message to QM C. Application will check the channel status periodically before sending out the message. It's done by writing program with MQAI to query the channel status. |
That kinda goes "against the grain" of MQ. Why not just use your "process the user request in another way" all the time, and not bother with MQ.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| tychak |
| Posted: Thu Jun 15, 2006 10:38 pm Post subject: |
|
|
Novice
Joined: 16 Mar 2004
Posts: 19
|
| Quote: |
That sounds more like a firewall issue.
|
The servers are connected to the same switch.
| Quote: |
| That kinda goes "against the grain" of MQ. Why not just use your "process the user request in another way" all the time, and not bother with MQ. |
I can only try to make to MQ to work in my situation. I cannot choose not to use MQ.
Thanks. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jun 15, 2006 11:15 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| tychak wrote: |
For simplicity, if the application knows that the channel is active, then it will put the message to the queue manager. If the channel is not active, it will not put the message to the queue manager and process the user request in another way.
|
I'm kind of on the side of EddieA here. If you've got to use MQ, it's best to work with the product not try and bend it double to meet your needs - it's only going to break sooner or later!
When you say "process the request in another way", do you actually mean a different non-MQ process or just the other MQ channel? If the latter, use fjb_saper's suggestion and set up a cluster.
If the former, why use MQ in the first place?? 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| tychak |
| Posted: Fri Jun 16, 2006 12:04 am Post subject: |
|
|
Novice
Joined: 16 Mar 2004
Posts: 19
|
Let me explain:
The application needs to send the request to another server and get a reply. If the MQ channel is not active, it means that the application need to switch to "not to" send the request the server. However, in this mode, there is some limitation which is not preferred.
So, if MQ and channels are stable, the application should work properly. However, if the channels are always disconnecting periodically, it will make the application switch to "not sending request" mode often. When the channels are disconnecting, it shows "AMQ9213: A communications error for TCP/IP occurred." My job is to check with this error and find the solution so that the channels can be always running. If the channels must be stopping sometimes, I have to try to make it up again as soon as possible or to make it stops less frequently.
I cannot change the design as I have no right to do so and many application programs may have to be changed, too.
Thanks very much for your advice. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jun 16, 2006 12:18 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| tychak wrote: |
many application programs may have to be changed, too.
|
In an ideal world, the applications should be isolated from the channels and other parts of the transport mechanism; they shouldn't care where their messages are going or how. Certainly I've not experienced a situation where applications are checking channel status before doing a PUT!
"I cannot change the design as I have no right to do so" - your site's a bit draconian! 
Still - the solution to your problem, as mentioned above, is to have the channels triggered. This way, when they're disconnected for any reason they automatically restart and hence solve your problem. I've certainly found this easier than trying to solve all the network problems so that channels stay up for extended periods. Experience teaches something always goes wrong not matter how short the connection between the two end point.
You might also want to consider putting your QM B & QM C in a cluster. Even if that's a "change to the design" which you have no right to make, I can't believe you're so stifled in inovation you can't make suggestions...
Though I have worked on government projects so I do understand about inertia and the difficulties of making suggesting radical (i.e. different) ways of doing things in some organisations. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jun 16, 2006 2:31 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Okay. So, really, what you need to do is monitor your channels and your error logs.
You've apparently decided or the requirement has said that you must put some monitoring logic in your application program - which breaks one of the central design advantages of MQ to isolate the sender from the receiver. But that's only as bad as it has to be, and as you've said you can't change it.
You're getting TCP/IP errors on the channel, and in the log file. You should troubleshoot those, first of all. Under what conditions do you see this error occur?
Making the channels triggers is not a bad idea - it means that as long as the channel is not in a "stopped" state, then your program will be able to run in it's "MQ mode".
If it is really not feasible for whatever reason to make the channels triggered, then you should write a separate program that basically triggers the channels - it runs all the time and if the channel is stopped then it starts it again.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
