Hi!
Oleksiy Stashok wrote:
> That's strange. If ReadFilter is able to read data - it should mean
> connection is alive.
However, this works only if ReadFilter executes always. It the parsing is
done using ParserProtocolFilter + ProtocolParser then this assumption is
wrong - if large enough (for some logical protocol messages) block of data
was received by ReadFilter then ProtocolChain will be re-invoked and
ParserProtocolFilter will not call ReadFilter.execute. This can be
desirable - if it was remote end that send some data and closed the
connection - we need to read and parse everything, or undesirable - if it
was the application itself that closed the connection - and so it is not
interested anymore in anything that could have left.
> As for memory allocation, ReadFilter tries to use already allocated
> buffer, if there is no buffer associated with the current thread - it
> really allocates new one. If error occurs during reading bytes from a
> channel, the buffer will not be lost, it will be reused during the
> next request processing.
I think that if you'll get a WorkerThread that is associated with a
ThreadAttachment that was reset (in SelectionKeyHandler.cancel) then it'll
allocate a new buffer. And after protocol chain execution completes and
ParserProtocolFilter attaches ThreadAttachment to SelectionKey in
postExecute then ThreadAttachment, SelectionKey, buffer & ProtocolParser
will be pending garbage collection. ProtocolParser will be created because
ThreadAttachment & SelectionKey were cleared in SelectionKeyHandler.cancel
and so ParserProtocolFilter will think that this is a new connection
without a protocol parser. BTW, ProtocolParser will also think that this is
a new connection and will parse accordingly.
> Not sure we need synchronization mechanism here. What we will
> synchronize?
Unfortunately, I have no answer for this one. It just feels wrong then
ProtocolChain execution continues even after connection was explicitly
closed by the app itself. I think there should be some mechanism in place
that interrupts protocol chain execution and data parsing after application
decided that it's done with this connection.
>> BTW, "release associated resources ASAP" is another interesting
>> topic - who
>> will care about this after SelectionKeyHandler.cancel already cleared
>> ThreadAttachment and SelectionKey but ProtocolChain was called after
>> this
>> and so its filters re-populated ThreadAttachment & attached it to
>> SelectionKey? ;-)
> Not sure this is possible scenario.
Definitely it is possible and it happens, see my description of events
above. It is not necessary that they will be exactly the same as
ProtocolChain execution can take place during different stages of
connection closing/clearing code. It's possible that processing will end
with some exception, i.e. ConcurrentModificationException if some filter
will try to manipulate attributes while they are cleared in
SelectionKeyHandler.cancel (actually this was the exception that grabbed my
attention to this behavior).
> If connection has been closed, a
> protocol chain will end up on ReadFilter.
Only if it is executed in the protocol chain...
Alexei