Aborted SSL connections may cause jetty to hang with full cpu

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.

Hi Steve,

Have you tried running this on java1.5 ?
There have been some ssl problems reported on java1.5 before and thought this might be related to it.
If you can check, that be grand.

Thanks!

Hi,

With 1.5.0_06 on Fedora 6 the upload does not work at all for me, but in a different way than this issue. It spits out BUFFER_OVERFLOWs (so not UNDERFLOWs) the moment the upload is started (not when aborting the client connection). So using the "fix" as I described in the issue makes no difference.

However the javadocs from jdk7 have some more info in them (http://download.java.net/jdk7/docs/api/javax/net/ssl/SSLEngine.html). Each BUFFER_XX status requires an appriopriate action. In case of underflow, obtain and offer more bytes for the SSL packet so it can be decoded. In case of overflow enlarge the destination buffer and retry to unwrap.

So using that suggestion, I, today, tried again playing with buffer sizes and apparantly also on 1.5 I can get that problem to go away by allocating larger buffers, larger than indicated by corresponding methods in the SSLSession (I modified SslSelectChannelConnector.doStart and added +2048 for all buffer allocs just to test).

But again, it is a different issue so I am not sure it is wise to discuss here. In any case I think the way jetty handles the results from an (un)wrap operation should be checked and matched against the SSLEngine documentation.

Err.. that was a typo... "There have been some ssl problems reported on java1.5" (not 1.5 but actually 1.6)
The jetty-recommended version to use is jdk1.5.0_13 (and up)

If you can post a sample webapp to demonstrate the problem, we'd appreciate it.
Meanwhile, I"ll try to replicate this behavior on jdk1.5.

Btw, are u using jetty's upload filter or commons-file-upload?

Thanks

This is taken from the emails on user mailing list;

I have attached a sample project. You will have to add the jetty 6.1.14 libs yourself as the list only accepts 500KB.
It is somewhat tedious to recreate, but what you should do is (using Firefox unsure if that is relevant);

• start the test java -server -cp
  build-ide/:lib/jetty.jar:lib/jetty-sslengine.jar:lib/jetty-util.jar:lib/servlet-api-2.5.jar nl.test.jetty.upload.TestUpload

• goto https://localhost:8080/Upload?step=threads

• in the same window (so you can use the back button later) goto:
  https://localhost:8080/Upload?step=index

• select a 2MB+ file for upload, click go and while uploading click back
  to navigate away

• Wait for the correct exception to occur or the mentioned output.

• In case of the eof exception (which is ok ofcourse) click forward to
  try again, click go, click back etc..

I'll try it another machine as well.

......

I now tried on a different machine (Ubuntu 8.04 all latest updates) with
sun jdk-1.6.0_07 and firefox 3.0.4. It is somewhat less frequent, but
still occurs.
....

David, As you can see in the attached sample project that reproduces the problem no multipart library is used at all. Simply the inputstream is read.

You're absolutely right. It triggers an endless loop on parsing when the endpoint has already been closed.
Thanks for the sample app ... fix is on the way.

Fixed for jetty 6&7

Thanks!

David,

I'm not 100% sure this fix is in the right spot.
Also some client SSL tests are failing now and pass if I back out the fix.

Looking at this, I suspect this issue is with the call to unwrap(Buffer)
This does a check of isOpen and returns true if progress is made.
I suspect it should throw on EOF exception if no progress is made and isOpen() is false.

But before trying that.... can you tell me the extent of the infinite loop. Does it loop
within a call to handle (in which case at what while loop), or does the loop exit and
re-enter handle (in which case we probably have some other loops we need to catch).

cheers

This patch (JETTY-817.patch) seems like the better fix (harmless on jetty-client)

applied the alternate fix (JETTY-817.patch attached)
jetty-client tests passed this time