Salut,
I was able to reproduce the problem:
https://grizzly.dev.java.net/issues/show_bug.cgi?id=193
The idea is when the synchronous mode is used, we create a large byte
buffer for storing the response and avoid to many I/O operations. When
ARP is enabled (async mode), we gonna run out of memory if we create
that large byte buffer. The workaround is to reduce the size of the byte
buffer or install the latest nightly from here:
http://download.java.net/maven/2/com/sun/grizzly/
That one doesn't have the problem.
Thanks for the help!
-- Jeanfrancois
charlie hunt wrote:
> And, I'll add that a heap dump generated from
> -XX:+HeapDumpOnOutOfMemoryError can easily be read by VisualVM
> (https::/visualvm.dev.java.net). VisualVM has a subset of the NetBeans
> Profiler and a heap walker in it which may help you (more quickly) find
> the culprit who's consuming all the memory.
>
> charlie ...
>
> Jeanfrancois Arcand wrote:
>> Salut,
>>
>> easier way. Add:
>>
>> -XX:+HeapDumpOnOutOfMemoryError
>>
>> Thanks
>>
>> -- Jeanfrancois
>>
>> Mark Hig wrote:
>>> Hi,
>>>
>>> Is there any way of protecting Grizzly from running out of memory. At
>>> the
>>> moment I am loading my Grizzly server and, as you would expect,
>>> eventually
>>> it runs out of heap space as more and more requests queue up for
>>> processing:
>>>
>>> 07-Jul-2008 15:17:17 com.sun.grizzly.util.WorkerThreadImpl run
>>> SEVERE: WorkerThreadImpl unexpected exception:
>>> java.lang.OutOfMemoryError: Java heap space
>>> 07-Jul-2008 15:16:49 com.sun.grizzly.http.DefaultProcessorTask
>>> parseRequest
>>> INFO: SocketChannel request
>>> linejava.nio.channels.SocketChannel[connected
>>> local=/127.0.0.1:8000 remote=/127.0.0.1:1834] is: R(
>>> xmlns:directive="directive")
>>> 07-Jul-2008 15:17:19 com.sun.grizzly.arp.AsyncProcessorTask doTask
>>> SEVERE: Java heap space
>>> java.lang.OutOfMemoryError: Java heap space
>>> 07-Jul-2008 15:17:18 com.sun.grizzly.http.DefaultProcessorTask
>>> parseRequest
>>> INFO: SocketChannel request
>>> linejava.nio.channels.SocketChannel[closed] is:
>>> R( xmlns:directive="directive")
>>> 07-Jul-2008 15:17:16 com.sun.grizzly.http.DefaultProcessorTask
>>> parseRequest
>>> INFO: SocketChannel request
>>> linejava.nio.channels.SocketChannel[closed] is:
>>> R( xmlns:directive="directive")
>>> 07-Jul-2008 15:17:12 com.sun.grizzly.arp.AsyncProcessorTask doTask
>>> SEVERE: Java heap space
>>>
>>> Is there anyway of identifying that this situation is about to occur OR
>>> after the error has been thrown, to be able to stop the listener, allow
>>> Grizzly to continue processing to clear its queues and hence free up
>>> memory
>>> and then to re-start the listener to accept more requests?
>>>
>>> Thanks in advance for any help.
>>>
>>> Mark
>>
>> ---------------------------------------------------------------------
>> 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
>