In mod_jk 1.2.30 a servlet flush/close in JBoss causes duplicate requests
Environment
- JBoss Enterprise Application Platform (EAP) 4.3
- mod_jk 1.2.30
Issue
- A servletOutput stream flush() after the close() causes an empty type 0x03 (body chunk) packet to be sent. It seems receipt of that packet by mod_jk sets the last_op value, which triggers the 'did not receive END_RESPONSE'ccondition. In fact END_RESPONSE was received, just not as the last op.
Resolution
the close() will call flush() This is the same as calling
stream.flush();
stream.flush();1.2.30 will complain about that, cause it might come from either faulty user servlet (like this example) or from a broken container. In any case this is not acceptable by mod_jk. Before 1.2.30 the flush packet in such situation would
hang inside the AJP stream packet data and would cause a flush to happen for a new client request (and was actually caused by a previous client flush)The solution here is to fix the application not to do this, nothing to fix here in mod_jk.
On the JBoss side of things in the AJP flush() does not take into consideration if a close() has been called, which a close() doesn't actually close the socket, just sends a message down the wire. The following JIRAs have been created to address this https://jira.jboss.org/browse/JBWEB-169 and https://jira.jboss.org/browse/JBPAPP-4409
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.
Comments