Hi!
Oleksiy Stashok wrote:
> 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? 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!). 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 :-(
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). Or it can just ignore all exceptions appearing inside Grizzly -
but is it wise? 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? ;-)
Alexei