You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Niklas Therning (JIRA)" <ji...@apache.org> on 2006/08/01 09:41:21 UTC
[jira] Commented: (DIRMINA-231) SocketConnector thread leak
[ http://issues.apache.org/jira/browse/DIRMINA-231?page=comments#action_12424782 ]
Niklas Therning commented on DIRMINA-231:
-----------------------------------------
You're right. destroy() won't be called unless the PooledThreadModel uses a ReferenceCountingIoFilter to wrap the ThreadPoolFilter. Previously destroy() was called automatically by MINA when a filter wasn't used anymore. This caused deadlock problems with the ThreadPoolFilter (see DIRMINA-169). Because of some other changes made to the way filters work in MINA 0.9 (as compared to 0.8) init/destroy would be called very often in some circumstances causing the deadlocks. You will either have to call destroy() manually in your test after the session has been closed or create your own ThreadModel which wraps the ThreadPoolFilter in a ReferenceCountingIoFilter.
I suggest that you either reuse the connector or at least make sure all the connectors you create use the same thread model instance. What you get now is seperate thread pools for each connection. Is that really what you want?
> SocketConnector thread leak
> ---------------------------
>
> Key: DIRMINA-231
> URL: http://issues.apache.org/jira/browse/DIRMINA-231
> Project: Directory MINA
> Issue Type: Bug
> Affects Versions: 0.9.5
> Environment: jdk1.5.0_06
> Reporter: Brad Harvey
> Assigned To: Niklas Therning
> Priority: Critical
> Attachments: ConnectionTest.java, ConnectionTest.java
>
>
> A few new threads are created for new SocketConnectors when they attempt to connect to a remote host. Two of these (AnonymousIoService-x-y) are not cleaned up which can eventually lead to OutOfMemoryError or other strange behaviour.
> It can be avoided by reusing SocketConnectors, but I don't think this should be necessary.
--
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