What I'm basically suggesting, is to not hold whole 2M request in
memory, if it's not strongly required by your implementation.
If you're implementing Grizzly Adapter - you can create (take from
pool) 4K-8K ByteChunk and use just it to process whole 2M request.
I see this like following:
ByteChunk buffer = new ByteChunk();
while(request.doRead(buffer) > 0) {
processBuffer(buffer);
}
If you have any concerns - pls. share your code, so it could be easier
to advice something more exact.
WBR,
Alexey.
On Aug 11, 2008, at 15:56 , Mark Hig wrote:
>
> Sorry I really dont understand what you are suggesting.
>
> I need a full message from Grizzly to pass onto the processing
> framework via
> the Grizzly adapter.
>
> Are you suggesting (1) passing the message as a stream to the
> processing
> framework or (2) passing it to the parser as a stream?
>
> (1) Cannot do this as the whole processing framework is expecting a
> full
> message.
>
> (2) We are currently using the Grizzly HTTP parser, can this accept a
> message as a stream? Or do we need to write our own parser which can
> accept
> a message as a stream?
>
> --
> View this message in context: http://www.nabble.com/8K-buffer-limit-tp18922684p18926331.html
> Sent from the Grizzly - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>