[ http://issues.apache.org/jira/browse/DIRMINA-197?page=comments#action_12373020 ]
Niklas Therning commented on DIRMINA-197: ----------------------------------------- You say that you only call bind/unbind? There are no clients connecting at all? If there are no clients I can't understand why a ThreadPoolFilter would be created in the first place. Maybe you could post your test code to clarify things? If there are clients connecting I think the problem could be that a new ThreadPoolFilter is created for each new session. You see, when a new session is created the ThreadModel, used when binding the Acceptor to the port, will be asked to modify the new session's filter chain. I've had a look at the code and it seems to me that the default ThreadModel implementation (PooledThreadModel) creates a new ThreadPoolFilter for each new session which it adds to the start of the session's chain. I don't think this is what was intended. It could be bug. To verify that this is the problem you could implement your own ThreadModel and in its buildFilterChain() method you always add the same ThreadPoolFilter instance to the chain instead of creating a new every time like PooledThreadModel does. You can set a non-default ThreadModel by specifying an IoServiceConfig when calling bind() on your acceptor. All of this is only my guess though and I may have completely misunderstood how the new ThreadModel stuff work. :) > CPU exhaustion on heavy bind/unbind > ----------------------------------- > > Key: DIRMINA-197 > URL: http://issues.apache.org/jira/browse/DIRMINA-197 > Project: Directory MINA > Type: Bug > Reporter: Emmanuel Lecharny > Priority: Blocker > Attachments: stack.txt > > Still doing smoke tests... > So now, I have a program that bind and unbind one thousand times to ADS. > Everything works just fine, but now, ADS is trying to transform my CPU to a > popcorn machine. It uses 75% of my CPU just doing nothing seious. I have > created a thread dump with jstack, attached. > Any help welcomed ! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
