On 30 March 2012 21:35, Remy Maucherat <rmaucher_at_redhat.com> wrote:
>> Besides, it is much better to just let the app pass the entire content
>> buffer and then try to write as much as possible. The app can then
>> keep the unwritten data and it knows the volatility of the buffer, so
>> it can copy it or not as needed.
>
> No it's not better, it is much worse actually. An application using big
> buffers is an easy DoS target. All you need is to read slowly and the
> container has to sit on its buffer until the write is complete.
That is only the case if the buffer is in the implementation and
accumulates unrelated writes.
But I'm proposing that the buffers written are created by the
application to be large enough to contain the entity being sent. This
could be a fixed sized frame of a protocol or a growing array buffer
to convert an object to JSON. Such buffers do not grow when the
consumer is slow. They are created by the application in order to
write the entity.
> Let's pretend that my example was with 20KB buffers then, that remains
> reasonable.
> ...
>
> I can do a single os.write(my20KBuffer); too ...
No you can't. The max size of the write is imposed by the internal
buffer of the implementation and the writer does not get to chose the
size of the write. As you pointed out, the internal buffers are
likely to be small, so you probably can't increase it to 20K!. Even if
they know their entity is 4k+1 bytes, then they have to do it in 2
writes if can writes returns 4k.
> No, the NIO 2 has one callback per write. So it has more callbacks, it is simple logic.
If you can write a large entity in a single write, then you will have
less callbacks with NIO.2 style than if you have to write it in many
partial writes. If you have to write many small entities, then NIO.2
style will have more callbacks. So unfortunately there is no
convenient simple one-size-fits all solution.
As you say, the EE expense on the call backs makes getting the right
style for the right entities critical.
> BTW, you seem most interested in pushing a solution that would require the least changes in your container.
Not at all. We currently don't expose any async IO to the servlet
container and either style is about the same effort to implement.
However, I guess that makes my advocacy in the other thread for the
option of having no async IO somewhat biased. Oh well, we all have
our baggage.