On 28/05/07, Jeanfrancois Arcand <Jeanfrancois.Arcand_at_sun.com> wrote:
> I've implemented that algorithm in Grizzly 1.0 but the performance
> wasn't as good as the current approach. Now reading this I think it
> explain why we are seeing a huge performance difference when running
> AsyncWeb. This approach might be good for some protocol, but for http
> this is not optimized as you gonna read the request body even if the use
> doesn't request for it (and worse, you will buffer it). Now I now how to
> crash MINA by sending a large post :-). Seriously, would it be a problem
> when the network is slow and packet arrives slowly? It will means MINA
> will creates a lot of ByteBuffer containing little number of bytes?
In the case where the bytes are stored because the request is
incomplete it copies the data into another buffer. The original buffer
would be eligible for GC. So you might have one 32k buffer that is
being gradually filled but you would not keep a huge amount of
redundant data.
The issue of a mismatches in performance between client and broker is
another interesting challenge with this type of app. "Slow consumer"
is well documented but with MINA we had the issue that a very active
client trying to write out lots of data faster than the broker could
process it could cause large buffer build up in the client (encoded
byte buffers are queued up for writing as mentioned before). We did
fix this by creating a special filter that block the client thread
when the backlog gets above a certain configurable threshold although
I'm not sure if that made it into MINA core.
RG