users@grizzly.java.net

A correct way of dealing with reads appearing after close

From: Alexei Dets <adets_at_idsk.com>
Date: Thu, 01 Oct 2009 16:27:00 -0400

Hi!

I've noticed that it's a quite common situation when protocol chain is
invoked after connection is already closed or while connection is closing
in parallel to protocol chain processing (SelectionKeyHandler.cancel is
called in another thread, i.e. from
AsyncWriteCallbackHandler.onWriteCompleted).

This usually results in various exceptions (depending how far close process
advanced) and unnecessary creation of a new worker thread's byte buffer,
population of a worker thread attachment attributes, creation of a new
ProtocolParser (if ParserProtocolFilter is involved) that will later be
attached to an already cancelled selection key, sometimes even in
successfull parsing of the protocol message that will be just discarded
because there is no any way to know where it should be delivered (because
BaseSelectionKeyHandler.doAfterKeyCancel removed selection key attachment
and cleared the ThreadAttachment attributes effectively destroying all
connection context information).

So, the question is - is the described behavior normal and what are
the "best practices" to deal with this (or avoid this problem)?

        Alexei