>> The best practice here. IMO, is stop processing the broken connection
>> and release associated resources ASAP.
>
> I agree :-)
>
> I guess the question is how to _reliably_ find out that this is a
> broken
> connection?
Here we're limited by JDK. Talking about TCP channels, the most
reliable way, IMO, is to get -1 or IOException, when trying to read
data. It's exactly what ReadFilter is doing. If ReadFilter found, that
connection is closed - it will stop processing and close the connection.
> I wasn't able to find any examples of such checks in Grizzly
> sources (of course I didn't check every file...). On the contrary I
> see
> that usually framework doesn't do any checks at all - i.e. on dead
> connections ReadFilter allocates a new buffer, ParserProtocolFilter
> creates
> a new parser instance, SelectionKeyHandler.cancel closes already
> closed
> connections (and repeats close notifications!).
That's strange. If ReadFilter is able to read data - it should mean
connection is alive.
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 guess there is a good
> reason for this behavior without any checks and synchronizations
> (i.e. they
> can hurt performance a lot) but it is not clear what should be done
> with
> this _in_practice_ on the application level :-(
As I mentioned ReadFilter is the most reliable "check".
> For example, application can try to introduce some synchronization
> (though
> it can be very difficult as whole Grizzly API is based on selection
> keys
> instead of channels but after introduction of LinuxSpinningWorkaround
> selection keys are not persistent anymore) but this will probably
> affect
> performance (and much more compared to possible synchronization
> inside the
> framework).
Not sure we need synchronization mechanism here. What we will
synchronize?
> Or it can just ignore all exceptions appearing inside Grizzly -
> but is it wise?
Ignoring all exceptions is not wise, but if it's exception related to
IOException, what you can do about it? The connection is not operable
anymore - you can just release associated resources, right?
> What is advisable, what is a big "NO-NO"? ;-) It'll be
> interesting, and I guess not only for me, to get the
> opinion/recommendations of the framework authors and "success
> stories" of
> the framework users.
>
> 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. If connection has been closed, a
protocol chain will end up on ReadFilter. If you see different
behavior - it's bug, which should be fixed.
To intercept connection closing - you need to implement
ConnectionCloseHandler and register it on SelectionKeyHandler.
Hope this will help.
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
>