java.nio.channels.CancelledKeyException in Jetty client

We run a system where we have an embedded Jetty client doing a lot of small HTTP requests to an HTTP server. During a stress test, the following error occurred:

java.nio.channels.CancelledKeyException
at sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:55)
at sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:59)
at org.mortbay.io.nio.SelectChannelEndPoint.updateKey(SelectChannelEndPoint.java:325)
at org.mortbay.io.nio.SelectChannelEndPoint.scheduleWrite(SelectChannelEndPoint.java:309)
at org.mortbay.jetty.client.HttpConnection.send(HttpConnection.java:131)
at org.mortbay.jetty.client.HttpDestination.doSend(HttpDestination.java:503)
at org.mortbay.jetty.client.HttpDestination.send(HttpDestination.java:459)
at org.mortbay.jetty.client.HttpClient.send(HttpClient.java:143)
...

Looking at the code in 6.1.25:

if (getChannel().isOpen())

{ => ops = ((_key!=null && _key.isValid())?_key.interestOps():-1); _interestOps = ((!_dispatched || _readBlocked) ? SelectionKey.OP_READ : 0) | ((!_writable || _writeBlocked) ? SelectionKey.OP_WRITE : 0); }

there is a race condition where the key can be cancelled between the _key.isValid() check and calling _key.interestOps() which is likely to cause this exception. Looking at the Jetty-7 code:

try

{ ops = ((_key!=null && _key.isValid())?_key.interestOps():-1); }

catch(Exception e)

{ _key=null; Log.ignore(e); }

This catches a possible exception and sets the key to null. I suspect this code will fix the intermittent java.nio.channels.CancelledKeyException that we are seeing. Can this code be backported to Jetty-6?