activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carl Allain (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMQ-3448) Zombie ActiveMQ Connection Dispatcher threads - seems to consume all process File Descriptors (FD leak)
Date Thu, 08 Sep 2011 14:43:09 GMT

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

Carl Allain commented on AMQ-3448:
----------------------------------

Seems too like the host from where the leaking threads/connections come from is creating a
connection 
everysecond or so. Could it be the problem? From the dev team, I obtained the "spring" config:

<!-- ActiveMQ connection factory -->
<bean id="activemqConnectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory">
<property name="brokerURL" value="failover${JmsQueueManager.brokerUrl})?startupMaxReconnectAttempts=1"/>
<property name="redeliveryPolicy" ref="redeliveryPolicy"/>
<property name="prefetchPolicy" ref="activemqPrefetchPolicy"/>
<property name="userName" value="${JmsQueueManager.userName}"/>
<property name="password" value="${JmsQueueManager.password.encrypted}"/>
</bean>

<bean id="redeliveryPolicy" class="org.apache.activemq.RedeliveryPolicy">
<property name="maximumRedeliveries" value="0"/>
</bean>

<bean id="activemqPrefetchPolicy" class="org.apache.activemq.ActiveMQPrefetchPolicy">
<property name="queuePrefetch" value="1"/>
</bean>

<bean id="pooledConnectionFactory" class="org.apache.activemq.pool.PooledConnectionFactory"
destroy-method="stop">
<property name="connectionFactory" ref="activemqConnectionFactory"/>
</bean>

<!-- Message listener for the ticketing queue -->
<bean id="tktMessageListener" class="com.xyz.rex.broker.jms.TktMessageListener"/>

<bean id="transactionManager" class="org.springframework.transaction.jta.JtaTransactionManager"/>

<!-- Container for the ticketing queue -->
<bean id="tktJmsContainer" class="org.springframework.jms.listener.DefaultMessageListenerContainer">
<property name="connectionFactory" ref="pooledConnectionFactory"/>
<property name="destinationName" value="${JmsQueueManager.ticketingQueue.name}"/>
<property name="messageListener" ref="tktMessageListener"/>
<property name="recoveryInterval" value="${JmsQueueManager.connectionRetryInterval}"/>
<property name="transactionManager" ref="transactionManager"/>
</bean>



> 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

        

Mime
View raw message