Message disorder between modjk and JBoss

The specific reasons are as follows:
In data interaction, one party separately deems the business interaction failed, and the logic is recycled instead of physically disabled multiplexing channels, when the other party completes the business operation, it pushes the business data to the channel that has been recycled by logic again, which will cause the request and corresponding dislocation.
Code layer design problems:
1. The unique session code is missing for multiple message interactions in a channel's one-time business interaction. As a result, any interaction in the middle may fail, and subsequent data may be misplaced to reuse other requests in this channel.
2. channel reclaim and exception handling at the underlying layer, instead of directly processing at the channel layer, throwing errors through the Service Stack to the management pool of the AJP protocol parsing thread at the outermost layer, the Spring framework encounters a serial number, whether it is a service capture exception or a servlet capture exception.
Solution:
1. Add a session code at the protocol layer to detect session misplacement and disable the channel.
2. Let the underlying channel have an exception and reclaim and close the channel. When the connection pool gets the connection, it determines whether the connection is invalid. If the connection is invalid, it is immediately removed. (The error stack is not required)
Follow-up:
The top side is already considering the asynchronous Web request processing method. In the future, with security requirements, we can adopt a similar channel multiplexing web server + application server mode with nginx.
For details, see the following content:
Use two images to describe the problem.
The first one is a request interaction process between JK and JBoss-web.

The problem occurs in Step 4. When JBoss-Web requests body data to JK, it may cause timeout or other IO exceptions. At this time, it will directly go to step 9, because the exception is caught, the connection will not be physically closed.

The Call Sequence for one request processing is as follows: in the numerical order, when there is a problem in step 5, ajpaprprocessor does not physically close itself, but relies on the exception throwing method, return to ajpaprprotocal to disable ajpaprprocessor. To do this simply, you only need to process it locally at 5, close the connection, although it will be put into the connection pool, however, you only need to check the connection status when using the connection pool in step 2 to discard these invalid connections.