Strange, I've just checked one more time - the call-flow we see in
stacktrace:
at
com
.sun
.grizzly
.SelectorHandlerRunner.continueSelect(SelectorHandlerRunner.java:154)
is possible only if leaderFollower is enabled, otherwise it's not
possible.
Other reason to think that leader/follower is enabled - is that
SelectorHandlerRunner.run() is called from DefaultThreadPool, not
kernel one, which supposed to be used, when leader/follower is off
at com.sun.grizzly.util.FixedThreadPool
$BasicWorker.run(FixedThreadPool.java:360)
So, Tigran, can we agree to wait for more info from your side and
probably other folks, which will use 1.9.19, whether the issue will
occur in normal circumstances (without OOM).
Thanks.
WBR,
Alexey.
On Jan 15, 2010, at 15:32 , Tigran Mkrtchyan wrote:
> It returns false.
> Here is how I initialize it:
>
> private final Controller _controller = new Controller();
>
> .....
> DefaultSelectionKeyHandler keyHandler = new
> DefaultSelectionKeyHandler();
> keyHandler.setTimeout(-1);
>
> final TCPSelectorHandler tcp_handler = new
> TCPSelectorHandler();
> tcp_handler.setPortRange(portRange);
> tcp_handler.setSelectionKeyHandler(keyHandler);
> _controller.addSelectorHandler(tcp_handler);
>
> final UDPSelectorHandler udp_handler = new
> UDPSelectorHandler();
> udp_handler.setPortRange(portRange);
> udp_handler.setSelectionKeyHandler(keyHandler);
> _controller.addSelectorHandler(udp_handler);
>
> _controller.addStateListener(
> new ControllerStateListenerAdapter() {
>
> @Override
> public void onReady() {
> _serverReady.countDown();
> }
> });
>
> DefaultThreadPool defp;
> ExecutorService executorService = _controller.getThreadPool();
>
> if (executorService instanceof DefaultThreadPool) {
> defp = (DefaultThreadPool) executorService;
> } else {
> defp = new DefaultThreadPool();
> _controller.setThreadPool(defp);
> }
>
> .....
>
> Regards,
> Tigran.
> On 01/15/2010 03:09 PM, Oleksiy Stashok wrote:
>>
>>> On 01/15/2010 02:46 PM, Oleksiy Stashok wrote:
>>>>
>>>>> 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?
>>>
>>> Since restart haven't seen it yet ( > 24h ). Unfortunately, I cant
>>> say how many requsts
>>> was processed (probably have to build a JMX bean). But it's a NFS
>>> server mounted on
>>> ~1000 clients.
>> I see.
>> If you can - pls. check Controller, whether it uses LeaderFollower
>> or not?
>>
>> Thanks.
>> 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
>>>>>
>>>>
>>>
>>
>