Author |
Message
|
themvv |
Posted: Thu Aug 18, 2005 11:47 pm Post subject: Can Not Send Data between two MQ Server |
|
|
Novice
Joined: 22 Jul 2003 Posts: 15
|
My System using MQSeries Server to send Data. Recently They can't send data. Ping Successfully , Icon show Running, but Data can't send. I had resolve and reset channel
Peple guest It's error because Network, but I think it's verry absurd.
My Network:
- about ten reply ok has one time out
- I can copy file and remote between two computer which setup MQ Server
Reply from 192.168.131.72: bytes=32 time<10ms TTL=128
Reply from 192.168.131.72: bytes=32 time<10ms TTL=128
Reply from 192.168.131.72: bytes=32 time<10ms TTL=128
Reply from 192.168.131.72: bytes=32 time<10ms TTL=128
Reply from 192.168.131.72: bytes=32 time<10ms TTL=128
Reply from 192.168.131.72: bytes=32 time<10ms TTL=128
Reply from 192.168.131.72: bytes=32 time<10ms TTL=128
Reply from 192.168.131.72: bytes=32 time<10ms TTL=128
Reply from 192.168.131.72: bytes=32 time<10ms TTL=128
Reply from 192.168.131.72: bytes=32 time<10ms TTL=128
Request timed out.
Reply from 192.168.131.72: bytes=32 time<10ms TTL=128
Reply from 192.168.131.72: bytes=32 time<10ms TTL=128
Reply from 192.168.131.72: bytes=32 time<10ms TTL=128
Reply from 192.168.131.72: bytes=32 time<10ms TTL=128
Reply from 192.168.131.72: bytes=32 time<10ms TTL=128
Reply from 192.168.131.72: bytes=32 time<10ms TTL=128
Reply from 192.168.131.72: bytes=32 time<10ms TTL=128
Reply from 192.168.131.72: bytes=32 time<10ms TTL=128
Reply from 192.168.131.72: bytes=32 time<10ms TTL=128
Reply from 192.168.131.72: bytes=32 time<10ms TTL=128
Request timed out.
Reply from 192.168.131.72: bytes=32 time<10ms TTL=128 |
|
Back to top |
|
 |
Mr Butcher |
Posted: Thu Aug 18, 2005 11:54 pm Post subject: |
|
|
 Padawan
Joined: 23 May 2005 Posts: 1716
|
why did you resolve and reset channel? was the channel indoubt?
what is the status of your mqseries channel between the mq systems?
what messages in the amqerr* logs? (check both ends) _________________ Regards, Butcher |
|
Back to top |
|
 |
themvv |
Posted: Fri Aug 19, 2005 12:33 am Post subject: |
|
|
Novice
Joined: 22 Jul 2003 Posts: 15
|
yes, first time I see Icon in retrying. I ping successful, but not start. alter that I using resolve and backout.then I using reset channel in two MQ servers. (when have error i usualy resolve and reset).
the Log i wil get it, because my system is running.
I check channel, the bytes sent is increate but a little.
a computer running 24/24 others running from 8 h to 17 h.
My AMQERR.Log
08/19/2005 08:09:22
AMQ9206: Error sending data to host BRV-SVR10 (10.35.64.60).
EXPLANATION:
An error occurred sending data over TCP/IP to BRV-SVR10 (10.35.64.60). This may
be due to a communications failure.
ACTION:
The return code from the TCP/IP(send) call was 10053 X('2745'). Record these
values and tell your systems administrator.
----- amqccita.c : 2052 -------------------------------------------------------
08/19/2005 08:09:22
AMQ9999: Channel program ended abnormally.
EXPLANATION:
Channel program 'TTA7170000THU7170000' ended abnormally.
ACTION:
Look at previous error messages for channel program 'TTA7170000THU7170000' in
the error files to determine the cause of the failure.
----- amqrccca.c : 784 --------------------------------------------------------
08/19/2005 08:21:54
AMQ9002: Channel 'TTA7170000THU7170000' is starting.
EXPLANATION:
Channel 'TTA7170000THU7170000' is starting.
ACTION:
None.
------------------------------------------------------------------------------- |
|
Back to top |
|
 |
Mr Butcher |
Posted: Fri Aug 19, 2005 12:55 am Post subject: |
|
|
 Padawan
Joined: 23 May 2005 Posts: 1716
|
you should not resolve/backout and reset without the need to do so. you may doublicate or delete messages when you follow that procedure.
if a sender channel is indoubt, look why. In most cases, the indoubt state will go away when the connection with the receiving end is established. there are very few cases where this indoubt has to be resolved manually, and the counters at both end will tell you whether to commit or to backout (if you choose the wrong action you will either delete or doublicate messages).
same with reset, a reset is only necessary if the sequence numbers differ. again, in that case, it is important to find out why.
i can not help with the 10053 error, did you search here? there are some threads for this one here....
it could also be helpful to see the log from the receiving end. _________________ Regards, Butcher |
|
Back to top |
|
 |
Nigelg |
Posted: Fri Aug 19, 2005 12:59 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004 Posts: 1046
|
Did you look at the error msg in the log?
Quote: |
The return code from the TCP/IP(send) call was 10053 |
The description of 10053 is
Quote: |
CP/IP error: ECONNABORTED 10053 Software caused connection abort
|
Software in the error msg means TCP software, so the problem is caused by either a TCP erorr or a network error. _________________ MQSeries.net helps those who help themselves.. |
|
Back to top |
|
 |
themvv |
Posted: Fri Aug 19, 2005 3:39 am Post subject: |
|
|
Novice
Joined: 22 Jul 2003 Posts: 15
|
Thank Mr Butcher for your advice.
To Nigelg and Mr Butcher , I don't agree with you and don't have confidence in MQ series if this problem is caused by either a TCP erorr or a network error. Because I Copy files and remote computer well. Why ? Mqseries in tranfer less advance than FTP, Copy file ???
I hope you give more detail why error while FTP, copy file well.!!!
that is my big customers'complaint who have been using a lot of MQ series technology |
|
Back to top |
|
 |
Nigelg |
Posted: Fri Aug 19, 2005 4:31 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004 Posts: 1046
|
You ask what is the cause of the problem, and I tell you.
If you do not like the answer, go ask somebody else. _________________ MQSeries.net helps those who help themselves.. |
|
Back to top |
|
 |
Mr Butcher |
Posted: Fri Aug 19, 2005 4:33 am Post subject: |
|
|
 Padawan
Joined: 23 May 2005 Posts: 1716
|
maybe the error is caused by people resetting or resolving channel that do not have to be resetted or resolved.
again, i would like to see the error log from the receiving mqseries end. _________________ Regards, Butcher |
|
Back to top |
|
 |
themvv |
Posted: Fri Aug 19, 2005 9:19 pm Post subject: |
|
|
Novice
Joined: 22 Jul 2003 Posts: 15
|
Sorry Nigelg. I hope you don't let me now !
many people have answer similar to you , but I hope it's not true because If it's true -->my Customer will upset (80 % using in future) ---> Stop using MQ series technology. I need anwser to resolve my problem and explaint with my Customer.
To Mr Butcher, I will give you error log from the receiving mqseries end on monday, because on weeken my customer's network is Stoped
don't let me now !  |
|
Back to top |
|
 |
fjb_saper |
Posted: Sat Aug 20, 2005 3:39 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
themvv wrote: |
Thank Mr Butcher for your advice.
To Nigelg and Mr Butcher , I don't agree with you and don't have confidence in MQ series if this problem is caused by either a TCP erorr or a network error. Because I Copy files and remote computer well. Why ? Mqseries in tranfer less advance than FTP, Copy file ???
I hope you give more detail why error while FTP, copy file well.!!!
that is my big customers'complaint who have been using a lot of MQ series technology |
This has nothing to do with MQSeries.
FTP is using a different protocol, and a different port....
TCP/IP problems can be legion. From firewalls blocking your protocol (They swear that they are not the cause,,, all MQ ports are open, they just forgot to tell you that they are blocking the protocol you are using...) to firewalls blocking your port, to bandwidth restrictions according to protocol (yes that FTP went fine and no we are not out of bandwidth.... They just did not tell you that all the bandwidth allowed for MQ was used up...)
And don't forget those contact admin interruptions caused by sniffers on MQPorts, or discrete intermittent loss of connectivity... etc...
So enjoy having to play in the justification game...  |
|
Back to top |
|
 |
hopsala |
Posted: Sat Aug 20, 2005 4:13 am Post subject: |
|
|
 Guardian
Joined: 24 Sep 2004 Posts: 960
|
hmm, there's another possibility, though a remote one. Possibily what happened is that the queue on the other end was full (and, if applicable, the deadq was also full) and the channel finished its message retry and went to channel retry.
Look futher up the log for messages such as
Quote: |
AMQ9506: Message receipt confirmation failed.
EXPLANATION:
Channel 'QM1.QM2' has ended because the remote queue manager did not accept
the last batch of messages. |
In fact, best advice I can give you, is to go through all entries in AMQERR01.LOG, starting from about a day or two before the malfunction occured. This may sound extreme, but i've come across errors that originated from something that happened a few days back. And as butch said, do the same for the receiving end.
Btw, concerning the ftp thing, did you try transferring the file exactly when the channel went to retry? I doubt it. You probably tried ftp after the network problem was resolved, the channel was still in retry because it was in the middle of SHORTRTY or LONGRTY. Had you waited a short while longer the channel would have probably gone up. Another option is that you tried transferring a 1KB file in FTP and a 20MB msg in MQ...
I agree with everything people said here: MQ is, if anything, a better more robust protocol with FTP. If FTP works, so does MQ, unless you have such problems as fjb_saper suggested. |
|
Back to top |
|
 |
fjb_saper |
Posted: Sat Aug 20, 2005 7:51 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Talking about channel problems I had another foisted on me last week.
MQ was not "working".
The fact was that all channels had been used up (100).
The reason was a network malfunction. This led to all the client applications connecting multiple times, loosing the connection and not cleaning up the resources....
I had the applications using the client channel (svrconn) shut down.
Did a force shutdown of the channel(svrconn).
Restarted the channel(svrconn).
Everything was fine. The applications reconnected and we went from 100 channels in use to 10 channels in use.
The cause: not MQ but a network malfunction !! Which of course they had fixed by the time they called me. However they were gracious and admitted to it when I asked...
Why it had to be resolved manually? We could not wait around for the usual connection timeout of 2 hours...
Enjoy  |
|
Back to top |
|
 |
themvv |
Posted: Sun Aug 21, 2005 11:20 pm Post subject: |
|
|
Novice
Joined: 22 Jul 2003 Posts: 15
|
Thank you for your idea.
I check my system, a litle data has sent ---> It send very slow. It's still working but not well.
Do you give resolve to config on MQ for sending more data on problem network ?
This is error log from the receiving mqseries end
08/22/2005 10:15:16
AMQ9002: Channel 'TTA7170000THU7170000' is starting.
EXPLANATION:
Channel 'TTA7170000THU7170000' is starting.
ACTION:
None.
-------------------------------------------------------------------------------
08/22/2005 10:19:16
AMQ9213: A communications error for TCP/IP occurred.
EXPLANATION:
An unexpected error occurred in communications.
ACTION:
The return code from the TCP/IP(recv) [TIMEOUT] 180 seconds call was 0 (X'0').
Record these values and tell the systems administrator.
----- amqccita.c : 2727 -------------------------------------------------------
08/22/2005 10:19:16
AMQ9999: Channel program ended abnormally.
EXPLANATION:
Channel program 'TTA7170000THU7170000' ended abnormally.
ACTION:
Look at previous error messages for channel program 'TTA7170000THU7170000' in
the error files to determine the cause of the failure.
----- amqrmrsa.c : 467 --------------------------------------------------------
08/22/2005 10:35:20
AMQ9002: Channel 'TTA7170000THU7170000' is starting.
EXPLANATION:
Channel 'TTA7170000THU7170000' is starting.
ACTION:
None.
On other Log (Websphere Root\Log)
05/16/2005 08:19:40
AMQ6120: An internal WebSphere MQ error has occurred.
EXPLANATION:
An error has been detected, and the MQ error recording routine has been called.
ACTION:
Use the standard facilities supplied with your system to record the problem
identifier, and to save the generated output files. Contact your IBM support
center. Do not discard these files until the problem has been resolved.
----- amqxfdcp.c : 628 --------------------------------------------------------
05/16/2005 08:19:40
AMQ6184: An internal WebSphere MQ error has occurred on queue manager
THU7170000_.QMGR.
EXPLANATION:
An error has been detected, and the WebSphere MQ error recording routine has
been called. The failing process is process 1868.
ACTION:
Use the standard facilities supplied with your system to record the problem
identifier, and to save the generated output files. Contact your IBM support
center. Do not discard these files until the problem has been resolved.
----- amqxfdcp.c : 662 -------------------------------------------------------- |
|
Back to top |
|
 |
hopsala |
Posted: Mon Aug 22, 2005 9:50 am Post subject: |
|
|
 Guardian
Joined: 24 Sep 2004 Posts: 960
|
Um...
Quote: |
08/22/2005 10:19:16
AMQ9213: A communications error for TCP/IP occurred. |
and
Quote: |
05/16/2005 08:19:40
AMQ6120: An internal WebSphere MQ error has occurred. |
Look at the dates... |
|
Back to top |
|
 |
themvv |
Posted: Mon Aug 22, 2005 8:50 pm Post subject: |
|
|
Novice
Joined: 22 Jul 2003 Posts: 15
|
well
My Problem happen from 08/15/2005 --> today 08/23/2005
- The error log from the receiving mqseries end in folder MQ Root \Qmgrs...\errors ----> Log file write on 08/22/2005
- On other Errors Log (Websphere Root\Log)
---> Log file write on 05/16/2005 ---> from 08/15/2005 --> 08/23/2005 Errors in System MQ not have error log |
|
Back to top |
|
 |
|