Ok, so you're talking about binding and unbinding to DS. I thought you were talking about calling bind()/unbind() on a MINA IoAcceptor! :) So you are basically creating a lot of clients which all connect to a running DS instance. Then the ThreadModel thing I was talking about could very well be the issue.
I just did an svn up and it seems like Trustin fixed this bug some hours ago. Could you please verify that this isn't an issue anymore with the latest trunk? /Niklas Emmanuel Lecharny wrote: > Niklas Therning (JIRA) a écrit : > > Hi Niklas, > > I'm switching to the ML because JIRA may have a problem with too many > threads used ;) > >> [ >> 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? > > Yep > >> There are no clients connecting at all? > > I have wrote an injector that simulates clients. Right now, I just do N > times Bind/Unbind. > >> If there are no clients I can't understand why a ThreadPoolFilter >> would be created in the first place. > > Each Bind is issued by what we can call a Client. So it makes sense that > a thread handle the request. > >> Maybe you could post your test code to clarify things? >> >> > yep, of course. Attached. > >> If there are clients connecting I think the problem could be that a >> new ThreadPoolFilter is created for each new session. > > That's it. > >> 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. >> >> > I don't know. However, I was expecting the thread to be destroyed when I > unbind, as I'm closing the socket. Another solution is to create a > threads pool to deal with all those sessions. I suppose that the > PooledThreadModel is the perfect class for that, but ... > >> 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. > > Yeah, maybe. However, the PooledThreadModel, which is a subclass of > ThreadModel is supposed to be a pool, but it only pools worker threads. > I don't why if it's a bug in the design, or if it's done on purpose. > Trustin might know ! > >> 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. :) >> >> > Me neither :) Mina is still a mistery to me. I never had time to deepen > my knowledge of MINA. > > Thanks a lot for the help ! >
