> no, even don't know about them. Is there a documentation available
> (except source code)?
It's one of the approaches to process I/O events on NIO Connection. By
default it's disabled, but from exception stacktrace you sent - it
looks like it's enabled in your testcase.
You can check it by calling controller.useLeaderFollowerStrategy().
How often do you this exception? Is it reproducible?
Alexey.
>
> On 01/15/2010 01:15 PM, Oleksiy Stashok wrote:
>> Tigran,
>>
>> have you configured controller to use Leader/Follower feature?
>>
>> Alexey.
>>
>> On Jan 15, 2010, at 13:00 , Tigran Mkrtchyan wrote:
>>
>>> Hi Alexey,
>>>
>>> On 01/15/2010 12:04 PM, Oleksiy Stashok wrote:
>>>> Hi Tigran,
>>>>
>>>> I'd probably need more details on that.
>>>> Do you know what was the reason of OOM?
>>>
>>> I hope wrong config option. It looks like we need 3 GB of memory
>>> while only 1GB was configured.
>>> Since config change looks more stable.
>>>
>>>> ConcurrentModificationException exception occurred after you got
>>>> OOM during server stopping?
>>> ConcurrentModificationException occurred after OOM. There was some
>>> others as well. In addition
>>> UDP listener was gone and probably clients as well:
>>>
>>> java.nio.channels.ClosedChannelException
>>> at
>>> sun.nio.ch.DatagramChannelImpl.ensureOpen(DatagramChannelImpl.java:
>>> 107)
>>> at
>>> sun.nio.ch.DatagramChannelImpl.send(DatagramChannelImpl.java:216)
>>> at
>>> com.sun.grizzly.util.OutputWriter.flushChannel(OutputWriter.java:
>>> 295)
>>> at
>>> com.sun.grizzly.util.OutputWriter.flushChannel(OutputWriter.java:
>>> 256)
>>>
>>> But OOM was the first one.
>>>
>>> Regards,
>>> Tigran.
>>>
>>>>
>>>> Thanks.
>>>>
>>>> WBR,
>>>> Alexey.
>>>>
>>>> On Jan 15, 2010, at 9:17 , Tigran Mkrtchyan wrote:
>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>> java.util.ConcurrentModificationException
>>>>> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
>>>>> at java.util.HashMap$KeyIterator.next(HashMap.java:828)
>>>>> at
>>>>> com
>>>>> .sun
>>>>> .grizzly
>>>>> .SelectorHandlerRunner
>>>>> .handleSelectedKeys(SelectorHandlerRunner.java:255)
>>>>> at
>>>>> com
>>>>> .sun
>>>>> .grizzly
>>>>> .SelectorHandlerRunner.continueSelect(SelectorHandlerRunner.java:
>>>>> 154)
>>>>> at
>>>>> com
>>>>> .sun
>>>>> .grizzly.SelectorHandlerRunner.run(SelectorHandlerRunner.java:114)
>>>>> at com.sun.grizzly.util.FixedThreadPool
>>>>> $BasicWorker.dowork(FixedThreadPool.java:379)
>>>>> at com.sun.grizzly.util.FixedThreadPool
>>>>> $BasicWorker.run(FixedThreadPool.java:360)
>>>>> at java.lang.Thread.run(Thread.java:619)
>>>>>
>>>>>
>>>>> This is grizzly 1.9.19-SNAPSHOT. The exception popup after we
>>>>> got out of memory exception.
>>>>>
>>>>> Regards,
>>>>> Tigran.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>