Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Do not flush cancelled writes. #2209
My experience with Netty is pretty limited, so I'm not sure if this is an issue or not. The fact is that the following lines will result in an actual channel write when I expected none:
A thorough example can be found here. Were there any plans to support such use cases in Netty? Looks like my changes don't break anything, the project compiles with all tests passed.
@normanmaurer you're welcome. Will wait for your fix.
Since you're considering to prohibit the cancellation of a write, let me outline my use case to justify why I think it should be allowed:
The target is to serve a live bitstream, live meaning that the stream is generated on the fly and a client may connect and start receiving it at any point. In my particular use case it happens to be an audio stream. A server component manages the stream server-side, and this component may be 'up' or 'down'. When 'up' clients may connect, when 'down' clients connections are rejected. When a connection is accepted, the component immediately starts writing stream data to the client's channel.
Once a connection request is received the following steps take place:
Now since the stream component does not switch states so frequently, one could write/flush a confirmation in 3) and then simply close the connection in the rare cases where 6) occurs. Yet if it is possible to cancel the confirmation and write/flush a rejection response instead, why not? I mean it makes perfect sense to me to be able to cancel a write when it is not yet flushed.
Sorry for this lengthy comment. It is only a week or so that I started using Netty, so if there is a simpler way to think of the above use case, hints are welcome!
@xfrag I think I see why you want to cancel a write even if I think you could just also make it work without canceling. It is more a question if we want to pay the extra price to support it. As this will maybe slow down things (as we need to check for isCancelled() etc all the time.,
pushed a commit
this pull request
Feb 7, 2014
@normanmaurer I get your point and I agree, most of the times there is no need to cancel a write so the potential overhead of checking would be a waste of resources.
But then, why should one write and then flush? I don't have a clear understanding of the reason for having to break the write operation in two steps, when the first step doesn't have a meaning without the second. The public API could simply expose a write() method that would be internally handled like writeAndFlush, and hide the flush() method. Is this backwards-compatibility related?
Another thought: could the ability to cancel writes be made optional, in order to reduce the checking overhead? This way, the user will have to enable cancellation support for the period of time during which a cancellation might occur, then disable and return back to the not-cancel-able mode. Checking a boolean state will practically impose no overhead. I will try to implement this and if I get into anything actually functional, will issue another pull request.
Having write and flush seperated allows to easily implement pipelining. So a user call multiple times write and then flush to try to write everything to the socket with one syscall