You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Jonathan Valliere (JIRA)" <ji...@apache.org> on 2018/03/05 17:30:00 UTC

[jira] [Comment Edited] (DIRMINA-1068) Mina 2.0.7 cpu load 100% on windows server 64

    [ https://issues.apache.org/jira/browse/DIRMINA-1068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386397#comment-16386397 ] 

Jonathan Valliere edited comment on DIRMINA-1068 at 3/5/18 5:29 PM:
--------------------------------------------------------------------

Windows limits the number of sockets per selector to a small number; I want to say 128 but its been a very long time.  Basically the JDK NIO creates lots of threads which run concurrent {{select}} operations on behalf of the one called from NIO.  This allows the JDK NIO to have larger sockets per selector count than Windows would typically allow.  All these threads spin up and block on each other until one or all of them resolve.  Remember when we discussed the ulimit error in {{accept}} ?  Well, in Windows they have to keep creating and destroying {{Selectors}} internally, its possible that the internal Windows NIO is hitting a ulimit style exception and is unable to create these dozens of selector threads.  The whole issue is probably related reaching [max open file limit|https://blogs.technet.microsoft.com/markrussinovich/2009/09/29/pushing-the-limits-of-windows-handles/].


was (Author: johnnyv):
Windows limits the number of sockets per selector to a small number; I want to say 128 but its been a very long time.  Basically the JDK NIO creates lots of threads which run concurrent {{select}} operations on behalf of the one called from NIO.  This allows the JDK NIO to have larger sockets per selector count than Windows would typically allow.  All these threads spin up and block on each other until one or all of them resolve.  Remember when we discussed the ulimit error in {{accept}} ?  Well, in Windows they have to keep creating and destroying {{Selectors}} internally, its possible that the internal Windows NIO is hitting a ulimit style exception and is unable to create these dozens of selector threads.  The whole issue is probably related reaching [https://blogs.technet.microsoft.com/markrussinovich/2009/09/29/pushing-the-limits-of-windows-handles/|max open file limit].

> Mina 2.0.7 cpu load 100% on windows server 64
> ---------------------------------------------
>
>                 Key: DIRMINA-1068
>                 URL: https://issues.apache.org/jira/browse/DIRMINA-1068
>             Project: MINA
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.0.7
>         Environment: windows server 64
> JDK 1.8.0_121 
>            Reporter: gunker
>            Priority: Major
>         Attachments: $V350`0YL5A@`FQ)5GFJ97S.jpg, )XDXFZF(26)(25UK0OVL)WW.jpg, ABN)]7BCUMHZLESQVUO%4@P.jpg, F5}3O~0_4K1KH(XJDXG`_RR.jpg, O`AUL[7]JG5QVKFY4K~`[$M.jpg, _HB%JVLZW`NW]~JW4L0766J.png
>
>
> in my case:
> I deploy this service on windows server(64).
> At beginning, all is normal. But after servrial days (not a fixed time) the cpu load 100%, I dump the theads info, it shows has a lot of "Thread-" threads, and the mina NioSocketAcceptor thread load 100%.     



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)