[
https://issues.apache.org/jira/browse/AMQ-3448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13108411#comment-13108411
]
mikab PENG edited comment on AMQ-3448 at 9/20/11 7:12 AM:
----------------------------------------------------------
I found this issue too.
I use a very old version(4.1.1) of ActiveMQ server, and use a very old version
of NMS client to connect to the MQ server. I use the default configuration of
the ActiveMQ Release. I found in the default configuration , ActiveMQ create a
dedicated thread to dipatch message, these thread are the the threads you
talking about. in my system, if the client connection doesn't provide the
MaxInactivityDuration parameter or the value of this parameter less than 0 ,
the monitor thread will not started, so if the socket closed before we call the
connection's close method, the dispatch thread will not close.
the error is occour in the method onException of class
org.apache.activemq.transport.InactivityMonitor in 4.1.1. I have saw the
newwest code, this code have been move to
org.apache.activemq.transport.AbstractInactivityMonitor, I don't think it have
been fixed.
you can disable the asynchronous dispatch in the
#{ACTIVEMQ_HOME}/conf/activemq.xml, or don't use dedicated thread to dipatch
message in the cmd line, set the system property
org.apache.activemq.UseDedicatedTaskRunner to false in the
#{ACTIVEMQ_HOME}/bin/activemq.
i hope this is useful for you.
was (Author: mikab):
I found this issue too.
I use a very old version(4.1.1) of ActiveMQ server, and use a very old version
of NMS client to connect to the MQ server. I use the default configuration of
the ActiveMQ Release. I found in the default configuration , ActiveMQ create a
dedicated thread to dipatch message, these thread are the the threads you
talking about. in my system, if the client connection doesn't provide the
MaxInactivityDuration parameter or the value of this parameter less than 0 ,
the monitor thread will not started, so if the socket closed before we call the
connection's close method, the dispatch thread will not close.
the error is occour in the method onException of class
org.apache.activemq.transport.InactivityMonitor in 4.1.1. I have saw the
newwest code, this code have been move to
org.apache.activemq.transport.InactivityMonitor.AbstractInactivityMonitor, I
don't think it have been fixed.
you can disable the asynchronous dispatch in the
#{ACTIVEMQ_HOME}/conf/activemq.xml, or don't use dedicated thread to dipatch
message in the cmd line, set the system property
org.apache.activemq.UseDedicatedTaskRunner to false in the
#{ACTIVEMQ_HOME}/bin/activemq.
i hope this is useful for you.
> Zombie ActiveMQ Connection Dispatcher threads - seems to consume all process
> File Descriptors (FD leak)
> -------------------------------------------------------------------------------------------------------
>
> Key: AMQ-3448
> URL: https://issues.apache.org/jira/browse/AMQ-3448
> Project: ActiveMQ
> Issue Type: Bug
> Affects Versions: 5.3.2
> Environment: Active MQ 5.3.2
> java version "1.6.0_23"
> Java(TM) SE Runtime Environment (build 1.6.0_23-b05)
> Java HotSpot(TM) Server VM (build 19.0-b09, mixed mode)
> LSB Version:
> :core-3.1-amd64:core-3.1-ia32:core-3.1-noarch:graphics-3.1-amd64:graphics-3.1-ia32:graphics-3.1-noarch
> Distributor ID: CentOS
> Description: CentOS release 5.5 (Final)
> Release: 5.5
> Codename: Final
> Reporter: Carl Allain
> Priority: Critical
>
> Somehow linked to https://issues.apache.org/jira/browse/AMQ-3286 which was
> closed. I am opening here as I cannot reopen the old bug and I hope that with
> the information I provide here, someone will be able to have some insight of
> the possible cause and a fix.
> I don't know how to reproduce with a test case, but I have found 800+ of such
> "ActiveMQ Connection Dispatcher" threads. I also noted that the number of FDs
> for the process keeps increasing and after a few days, we have a "too many
> files opened" when going beyond the 1024 limit. Most of those FDs (hundreds)
> do look like:
> java 6700 lexo-ext 904u sock 0,5 1741176200 can't identify protocol
> There is not much activity on the system and that is still enough to get the
> problem.
> When we reach the limit of FDs, we get tons of stack traces in the logs,
> filling up the hard disk...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
