Call shutdownOutput to signal the other end that you have written all the data that your are going to write (eg and the end of a non persistent HTTP response). This can be done either by generator (when it is complete) or coordinator or handle - but we need to decide which and have only 1 doing it.
Call shutdownInput to signal your own end that you have read -1 and to allow other local code to check that with an isInputShutdown. Ideally we could get by without any calls at all to shutdownInput, so long as we well handle reading -1 (Currently we don't). This should be done by whatever does the IO read.
Calling close should always be a real TCP close, even with SSL. SSL shutdown
The default handling of an idle callback should be close. But some connections (NOT endpoints) may implement idle as initiating a shutdown exchange (eg websocket close). If they do, this is state that should be held in the connection or parser - ie do-this-exhange-and-then-shutdown
Call close when you want to shutdown Output and you have already read -1, so input is already shutdown. We need to double verify that this is correct and that if a FIN has been received from the other end, that a close will not result in a reset. I'll do that today.
Call close when you want to shutdown Input and output has already been shutdown. This means you have read -1 after having sent a FIN.
Call close on any errors.
The current state is that server HttpConnection appears to be working well. Other connection types have not been updated and/or tested
Reworked StreamEndPoint methods isInputShutdown(), isOutputShutdown(), shutdownInput(), shutdownOutput(), and updated subclasses to call super where appropriate.
The test had to be modified to work properly with SocketConnector, because behavior is different from SelectConnector, but the CPU spinning is fixed.
Greg Wilkins
Jesse McConnell
Simone Bordet