The reason why Tomcat reports BAD packet signature 18245 error

When starting the server today, a BAD packet signature 18245 error was reported

The detailed error is as follows:

1. 2009-6-5 11:09:11 org.apache.jk.common.MsgAjp processHeader  
   严重: BAD packet signature 18245  
   2009-6-5 11:09:11 org.apache.jk.common.ChannelSocket processConnection  
   严重: Error, processing connection  
   java.lang.IndexOutOfBoundsException  
       at java.io.BufferedInputStream.read(BufferedInputStream.java:306)  
       at org.apache.jk.common.ChannelSocket.read(ChannelSocket.java:626)  
       at org.apache.jk.common.ChannelSocket.receive(ChannelSocket.java:583)  
       at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:691)  
       at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:895)  
       at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)  
       at java.lang.Thread.run(Thread.java:595)  

This is a package handled by the AJP protocol.

Check the configuration file in Tomcat's server.xml

1. <Connector port="8009"   
                  enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />  

It is preliminarily determined that some requests that are not AJP protocol request this port.

Solution:

Use a port scanning tool (optimization master, firewall, ewido, etc.) to scan the network connection status of the system to check whether there is a program accessing port 8009.

Close the program and it's OK.

On my side, because the IDE self-starts IE, the access path port has been changed to: http://localhost:8009. Change the port back to port 8080 and it will be OK.

References:

 AJP agreement

AJP is a directed packet protocol. For performance reasons, a binary format is used to transmit human-readable text. The WEB server connects with the SERVLET container through a TCP connection. In order to reduce the cost of socket generation by the process, a persistent TCP connection is attempted between the WEB server and the SERVLET container, and a connection is reused for multiple request/reply cycles. Once a connection is assigned to a particular request, it will not be reassigned until the request processing loop is complete. In other words, requests are not multiplexed on a connection. This eases coding at both ends of the connection, although this results in many connections at a time.
　　Once the WEB server opens a connection to the Servlet container, the connection is in the following states:
◆ Idle
There are no requests processed on this connection.
◆ Dispatched
The connection is processing a specific request.
　　Once a connection is assigned to a specific request, the basic request information sent on the connection is highly compressed. At this point, the Servlet container is probably ready to start processing the request, and when it does, it can send the following information back to the WEB server:
◆ SEND_HEADERS
sends a set of headers to the browser.
◆ SEND_BODY_CHUNK
　　　sends a piece of body data to the browser.
◆ GET_BODY_CHUNK
Get the next data from the request. If the transmission has not been completed yet, if the packet length of the request content is very large or the length is uncertain, this is very necessary. For example uploading a file. Note that this has nothing to do with HTTP chunk transfers.
◆ END_RESPONSE
ends the request processing cycle.