On 31 May 2012 11:51, Remy Maucherat <rmaucher_at_redhat.com> wrote:
> With option c), the container has to keep a reference to the one GB byte
> array, so the same memory is still referenced.
Exactly!! the same memory is used! The container does not need to
make a copy and use twice the memory!
Worse still, the application might create a large buffer (let's say
256K) and then send it to 1000 different connections. The container
now has to copy that same memory 1000 times
If you want a scalable container, you cannot let the application give
it unconstrained memory requirements.
> But this sort of
> application will never be able to actually work anyway, so why are we
> discussing it ?
Why will it not work? OK 1G is a bit extreme, but I can certainly
imagine real applications that have multi MB resources cached in
memory to be served.
> If it makes you more comfortable, maybe it would be reasonable to
> restrict write(byte[]) to a maximum size when using it in async mode
> (maybe to a multiple of the Servlet buffer size).
That would make me very uncomfortable. The app would then have to do
it's own fragmentation. This is simply not the concern of an
application!
> [The "one GB array" is the main use of the memory mapped ByteBuffer -
> since it's the only way to avoid killing the server -, with a new
> write(ByteBuffer), but the consensus about it was "maybe later"; like
> Tomcat's sendfile, it effectively bypasses the Servlet API IO]
Note at all - just this week I'm dealing with a user that creates
large dynamic images in memory and serves them to multiple clients.
OK they are not 1G, but they are multi MB and are large enough to
cause flow control to kick in while being written.
> In my current API/implementation, this is not illegal however: it simply
> triggers blocking if you insist with multiple writes - or reads - after
> the ready flag flips. So this is more sophisticated for some, but others
> may not understand what they are doing.
So without a tight specification we have an implementation difference.
An app run on your code will block (using the nonblocking API), while
on others it will be deemed "illegal" through an unspecified
mechanism. Great!
> Since the API remains the same, unless it says that some behavior
> changes, what is described elsewhere in the specification is unchanged.
> Although I believe that things related to the threading model, the
> state, and errors should be detailed more, I am not convinced this
> particular item needs more attention.
You're joking right?