Hi, On Wed, Jun 1, 2016 at 2:26 PM, Pavel Rappo <pavel.ra...@oracle.com> wrote: > Simone, may I ask you what you think about current `Listener.onPong()` > behaviour? Do you think it should also send Pong unconditionally upon > completion > of returned CS?
I'm not sure it's worth encouraging to write application data from a onPing() or onPong() listener. My take on the issue is that upon receiving a Ping, the implementation should send a Pong "as soon as it is practical". I don't think sending the Pong should be done from within onPing(). The implementation should do it, and may even do it _before_ calling onPing(), internally. In this interpretation, onPing() can return void (no need for CF) because there is no need to wait for the CF to send the Pong: the implementation sends the Pong either before or just after onPing(). The onPing() implementation can be empty, and there is no risk that overriding it, the Pong is not sent. On the other hand, sending application data from onClose() can be important: a goodbye message, a message that says what was the last message processed by the peer (similar to the last_stream_id in HTTP/2), etc. I would add the CF to onClose(), but not to onPing(), nor to onPong(). -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
