Hi Alexei,
> 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)?
The described behavior is not so normal, but as you mentioned it's
common :)
Most of the time the reason, why a connection gets closed on separate
thread is:
1) Connection was recognized as broken (probably client closed a
connection)
2) Some timeout exceeded
The best practice here. IMO, is stop processing the broken connection
and release associated resources ASAP.
WBR,
Alexey.
>
> Alexei
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>