WebSphere MQ
Special case of message sending and receiving errorsAuthor: Zheng Zuo Date: 2007-11-6
SummarySome time ago, when the organization implemented the BizTalk Server 2006 application integration project, when using the MQSeries adapter, it encountered packet data loss during transmission in the message queue, the WebSphere MQ Queue Manager channel will be disconnected and retry failed. This problem already exists at the beginning. Because my colleagues are trying to find the cause, the author has not caught any attention. After a while, the problem will be stranded. This time, the author is responsible for a BizTalk application integration project that needs to use MQSeries to implement data transmission from a microcomputer to a minicomputer. The legacy problems still need to be solved, but it's a good luck to deal with it all night. The cause of this problem is a bit special, so I wrote down the Solution Process for your reference.
Application EnvironmentMultiple hardware servers are configured as hp1_g5160, hp1_g5130, and hp580. System: Windows Server 2003 Enterprise Edition message middleware: IBM WebSphere MQ v6.0 for Windows deploy WebSphere MQ v6.0 on two servers and connect them using the server. Application Integration Platform: Biztalk Server 2006 Enterprise Edition 6 BizTalk servers implement 3 BizTalk creation processing groups + 1 Esso + 2 database servers for active/active mode clusters. Database: SQL Server 2005 Enterprise Edition
Error displayStart the sender channel in the MQ Queue Manager and place messages to the Remote Queue. The receiver channel automatically starts, the sent packets can be viewed on the local queue corresponding to the MQ server where the receiver channel is located. However, after a while, the channel is automatically in the inactive status, and the connection fails again. The system logs generated when the retry fails are described as follows: Error 1: Event Type: Error
Event Source: WebSphere MQ event type: None event ID: 9206 Date: 2007-10-29 event: 19:55:49 User: N/a computer: NB-TFR1 Description: an error that data is sent to the host NB-ZZ (192.168.1.66.
An error occurred while sending data over TCP/IP to the NB-ZZ (192.168.1.66. The cause may be a communication fault. The return code of the TCP/IP (send) call is 10054X('20140901 '). Record these values and notify the system administrator. Error 2: Event Type: Error
Event Source: WebSphere MQ event type: None event ID: 9208 Date: 2007-10-29 event: 20:00:05 User: N/a computer: NB-TFR1 Description: Error received by host 192.168.1.66. An error occurred while receiving data from 192.168.1.66 through TCP/IP. The cause may be a communication fault. The return code for a TCP/IP (Recv) call is 10053 (x '20140901 '). Record these values and notify the system administrator. Note: A trigger has been set on the transmission queue. If the channel is inactive, it will be automatically started when the message enters the transmission queue. In addition, I tried to use the client server to access the MQ Queue Manager. The same error occurs. However, this issue does not occur if the same test is performed on the Dell server of the Organization.
Find the reasonBased on the error message, you can determine that the error is not a BizTalk Server problem. According to the call return code 10054 X ('20140901') and 2746 (x '20160901'), I searched Google and Baidu and found no solution to the problem. Find a solution on the IBM website and get some clues: csqx208e trptype = TCP rc = 00000461 or amq9208 10054 http://www-1.ibm.com/support/docview.wss? Rs = 171 & context = ssfksj & context = sswhkb & Q1 = 10054 & uid = swg21237211 & loc = en_us & cs = UTF-8 & lang = en
Amq9206 10054 (x '20140901') econnreset from TCP/IP on a client channel connection to a local server
Http://www-1.ibm.com/support/docview.wss? Rs = 171 & context = ssfksj & context = sswhkb & Q1 = 10054 & uid = swg21106218 & loc = en_us & cs = UTF-8 & lang = en:
Return code 10054 or RC 461 means the connection is reset by peer (econnreset ). this usually indicates a problem in the TCP/IP network. there are numerous reasons TCP/IP will sent a reset.
Reasons for TCP/IP resets
- An application request a connect to a port and IP address for which no server is listening
- An application closes a socket with data still in the application receive buffer. The connection is reset to allow the remote partner to know that the data was not delivered.
- Any data that arrives for a connection that has been closed can cause a reset.
- An application closes a socket and sets the linger socket option to zero. This will allow y TCP/IP that the connection shoshould not linger.
Note **MQ does not code the linger socket option, therefore MQ will not cause a reset.
- An invalid TCP segment arrives for a connection, for example, a bad acknowledge or sequence number can cause a reset.
- The CONNECT request times out. TCP gives up trying to connect to an particle port and IP address and resets the connection.
- A firewall can reset connections if the packet does not adhere to the firewall rules and related ies. For example a source or destination port or IPaddress does not match the firewall rule or policy.
- The retransmit timer expires. TCP gives up trying to retransmit a packet and resets the connection.
- A bad hardware device can cause resets
It was preliminarily determined that it was the reason for setting the bottom layer of the system network. I think that a new batch of colleagues in the HP Server O & M group have installed the HP Network Configuration Utility tool, some network settings may conflict with MQSeries. Connect to the server and open HP Network Configuration Utility.
Select a network adapter to open the Properties dialog box.
First, some settings in advanced settings are incorrect. Therefore, perform a group test on the attributes with IP or TCP in the preceding attributes. Finally, the Enabled value option for TCP offload engine is deselected. The MQSeries channel is automatically disconnected. In the same dialog box, you can see that the TCP offload engine function is described as follows:
TCP offload engine (toe) reduces the CPU cycles required to process network traffic by shifting processing to the adapter. Toe cannot be enabled on a port that has jumframes enabled.
SummaryIt can be seen that some default settings of the server or the optimization settings of the enhancement program may not apply to some applications, and may cause conflicts, in the case of software problems, it is often difficult to find the cause of the problem.
