Hi,
>
> Thanks for the prompt reply.
>
> If I do as you suggest does this just reserve a fixed amount of
> memory for
> each message? If this is the case Grizzly will run out of memory very
> quickly.
No, it's per processor thread, not per message.
> Our application will be receiving messages >2Mb on a regular basis.
> Ideally
> I am looking for a way to implement/integrate an expandable byte
> buffer so
> that only as much memory as is needed to read a complete message is
> reserved
> on a message by message basis.
Expandable bytebuffer, IMHO, is not perfect solution, as you'll need
to allocate/reallocate all the time - which could cost perf. And smart
memory-pool implementation, IMHO, is very complex to implement.
If your request in 2M, does it mean you need whole the 2M message to
have in buffer?
For example, if it's acceptable for you to process the message in
stream-like manner - then you can have just 4-8K memory view (window)
to work with the request. Will it work for you?
Thanks.
WBR,
Alexey.
>
>
>
>
>
> Oleksiy Stashok wrote:
>>
>> Hello Mark,
>>
>> with HTTP it should be possible by doing following:
>>
>> 1) Create own pipeline, which extends
>> com.sun.grizzly.http.LinkedListPipeline
>>
>> public class MyPipeline extends LinkedListPipeline {
>> public MyPipeline() {
>> initialByteBufferSize = <byte_buffer_size>;
>> }
>> }
>>
>> 2) Set your custom pipeline class name to the SelectorThread
>>
>> selectorThread.setPipelineClassName(MyPipeline.class.getName());
>>
>> Hope this will help.
>>
>> WBR,
>> Alexey.
>>
>> On Aug 11, 2008, at 11:46 , Mark Hig wrote:
>>
>>>
>>> Hi all,
>>>
>>> I am using the Grizzly NIO framework along with the Grizzly HTTP
>>> Engine to
>>> process incoming messages. My question is how do I get around the
>>> inherent
>>> 8K buffer limit for incoming messages?
>>>
>>> Other posts I have read achieve this by directly coding to the
>>> buffer API
>>> when people are creating their own protocol parsers, however, I am
>>> using
>>> the Grizzly HTTP Engine and cannot see how to do this.
>>>
>>> Surely the HTTP engine must (needs to) use some kind of expandable
>>> byte
>>> buffer to cope with variable length messages in an efficient manner?
>>>
>>> TIA, Mark
>>> --
>>> View this message in context:
>>> http://www.nabble.com/8K-buffer-limit-tp18922684p18922684.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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/8K-buffer-limit-tp18922684p18924795.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
>