Obviously netty fixed this with a workaround.
Am 27.02.2016 um 18:06 schrieb Buddy Butterfly:
>
> This bug from netty seesm to be related:
>
> https://github.com/netty/netty/issues/3857
>
> Am 27.02.2016 um 17:38 schrieb Buddy Butterfly:
>> Am 26.02.2016 um 13:03 schrieb Emmanuel Lécharny:
>>> Le 26/02/16 12:07, Buddy Butterfly a écrit :
>>>> Hi,
>>>>
>>>> we still experience isse DIRMINA-1006. We have an RFID device that
>>>> rejects connections when connection limit is reached. Our mina client
>>>> thread then goes into 100% cpu usage. Any idea if the patch maybe
>>>> did not cover the all situations?
>>>>
>>>> Cheers,
>>>> Buddy
>>>>
>>>>
>>>>
>>>>
>>> Cr*p...
>>>
>>> Can you reopen the issue, and attach a stacktrace (kill -3) when you
>>> observe a 100% CPU ?
>>>
>>
>> "NioProcessor-22" - Thread t@2977
>> java.lang.Thread.State: RUNNABLE
>> at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll0(Native Method)
>> at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll(Unknown Source)
>> at sun.nio.ch.WindowsSelectorImpl$SubSelector.access$400(Unknown Source)
>> at sun.nio.ch.WindowsSelectorImpl.doSelect(Unknown Source)
>> at sun.nio.ch.SelectorImpl.lockAndDoSelect(Unknown Source)
>> - locked <6ad192> (a sun.nio.ch.Util$2)
>> - locked <e4f17d> (a java.util.Collections$UnmodifiableSet)
>> - locked <aa5042> (a sun.nio.ch.WindowsSelectorImpl)
>> at sun.nio.ch.SelectorImpl.select(Unknown Source)
>> at
>> org.apache.mina.transport.socket.nio.NioProcessor.select(NioProcessor.java:98)
>> at
>> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1059)
>> at
>> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
>> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>> at java.lang.Thread.run(Unknown Source)
>>
>> Any Idea?
>>
>> Cheers,
>> Buddy
>>
>>
>>
>
>
