Hi Alexei,
>> 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,
Agree
> 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.
Right. This is not implemented.
To achieve this behavior - you'll probably need to extend
ParserProtocolFilter and add that logic.
Anyway it's good point, we'd probably need to think about some general
solution for this. Will appreciate any help here!
>> 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.
From you words it definitely looks like a bug!
Can you pls. just elaborate... As I understand here we're talking
about situation, when one thread processes parsing, another one is
doing cancel? Can you pls. provide the steps (one-by-one), when the
situation above will occur?
>> 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.
+1000000 :)
If something needs/could to be fixed on Grizzly side - we should do
that.
>
>>> 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).
Agree, this could happen if you explicitly close a connection on
server side. This situation, IMO, is not very normal, but possible.
Though, not sure synchronization (waiting until protocol chain on
different thread will finish its work) is good solution here. From
other side, protocol chain should not do what it does according to
your previous observation.
Hope with your help and details I asked above - we will be able to
workaround connection close the best way we can.
>
>> If connection has been closed, a
>> protocol chain will end up on ReadFilter.
>
> Only if it is executed in the protocol chain...
Right.
Thanks.
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
>