Details
-
Type:
Bug
-
Status:
Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 6.1.12.rc5, 6.1.14
-
Fix Version/s: 6.1.15.pre0
-
Component/s: Security and SSL
-
Labels:None
-
Environment:Several linux, firefox, and jdk1.6.0.
Tried with jetty 6.1.12rc5 and upon discovery also with 6.1.14
-
Number of attachments :
Description
When a client aborts a larger upload, for example by navigating away from the page in which the upload is done, jetty may hang with full cpu.
Jetty in this state will continuously output the following lines;
unwrap {} Status = BUFFER_UNDERFLOW HandshakeStatus = NOT_HANDSHAKING
bytesConsumed = 0 bytesProduced = 0 null
...
Tracking the problem showed that Jetty has a partial SSL packet that cannot be decoded. The SSL engine will return a BUFFER_UNDERFLOW status indicating it requires more bytes to be added to the packet. Jetty however cannot provide anymore (the connection is gone), but Jetty will keep on trying to decode the (same) remaining data.
By checking _channel.isOpen and setting _closing=true accordingly when the BUFFER_UNDERFLOW occurs, the expected EofException will be generated by Jetty and the problem is gone.
In SslHttpChannelEndPoint.unwrap I changed the checking of the status to the following;
switch(_result.getStatus())
{
case BUFFER_UNDERFLOW:
if(!_channel.isOpen())
/* fall through */
case BUFFER_OVERFLOW:
.....
Obviously, I am not sure that this fix is in the apprioprate place in the Jetty pipeline. Maybe _channel.isOpen() should actually have been checked earlier. I do not know the internal jetty code and flow to decide this.
I forgot to mention that I did not look into the fact that Jetty also did not timeout this connection, while the connector has connector.setMaxIdleTime(30000); set. Not sure if that requires other changes or if channel.isOpen accounts for that already.