Каков правильный способ гарантировать, что потребители jms закрыты с помощью интеграции с пружиной?

Я использую интеграцию spring, чтобы вызвать службу на другом конце активного mq. Моя конфигурация выглядит следующим образом:Каков правильный способ гарантировать, что потребители jms закрыты с помощью интеграции с пружиной?

<bean id="jmsConnectionFactory" class="org.springframework.jms.connection.CachingConnectionFactory"> 
     <constructor-arg> 
      <bean class="org.apache.activemq.ActiveMQConnectionFactory" 
        p:brokerURL="${risk.approval.queue.broker}" 
        p:userName="${risk.approval.queue.username}" 
        p:password="${risk.approval.queue.password}" 
        /> 
     </constructor-arg> 
     <property name="reconnectOnException" value="true"/> 
     <property name="sessionCacheSize" value="100"/> 
    </bean> 

    <!-- create and close a connection to prepopulate the pool --> 
    <bean factory-bean="jmsConnectionFactory" factory-method="createConnection" class="javax.jms.Connection" 
      init-method="close" /> 

    <integration:channel id="riskApprovalRequestChannel"/> 
    <integration:channel id="riskApprovalResponseChannel"/> 

    <jms:outbound-gateway id="riskApprovalServiceGateway" 
          request-destination-name="${risk.approval.queue.request}" 
          reply-destination-name="${risk.approval.queue.response}" 
          request-channel="riskApprovalRequestChannel" 
          reply-channel="riskApprovalResponseChannel" 
          connection-factory="jmsConnectionFactory" 
          receive-timeout="5000"/> 

    <integration:gateway id="riskApprovalService" service-interface="com.my.super.ServiceInterface" 
         default-request-channel="riskApprovalRequestChannel" 
         default-reply-channel="riskApprovalResponseChannel"/>

То, что я заметил, что с этим конфиг потребителей создан, чтобы захватить запрос согласования с активной квадратных метров никогда близко. Каждый запрос увеличивает количество пользователей.

Я могу остановить это происходит путем добавления

<property name="cacheConsumers" value="false" />

К CachingConnectionFactory.

Однако в соответствии с ява документы для CachingConnectionFactory:

Обратите внимание, что долговечные абоненты будут кэшировать только до логического закрытия ручки сессии.

Это говорит о том, что сессия никогда не закрывается.

Это плохо? Есть ли лучший способ остановить накопление потребителей?

Приветствия, Peter

источник

2012-05-03 Peter Wilkinson

Во-первых, вам не нужно Init-метод на вашем заводе-боб - это ничего не делает - сеанс фабрика имеет только одно соединение и вызов близко() на это нет -op. (CCF является подклассом SingleConnectionFactory).

Второй; кэширование потребителей по умолчанию; сеансы никогда не закрываются, если количество сеансов не превышает sessionCacheSize (который вы установили равным 100).

Когда close() вызывается в кешированном сеансе, он кэшируется для повторного использования; это то, что завод кэширования соединений для - избегая накладных расходов на создание сеанса для каждого запроса.

Если вы не хотите повышения производительности сеансов кеширования, производителей и потребителей, вместо этого используйте SingleConnectionFactory. См. JavaDoc для CachingConnectionFactory.

источник

2012-05-03 12:27:21

Спасибо за хорошую информацию. Причиной закрытия потребителей является то, что у всех есть переключатели идентификаторов корреляции, поэтому они никогда не будут кандидатами на повторное использование. Учитывая, что у меня нет других потребителей, я думаю, что я переключусь на SingleConnectionFactory, как вы предложили. –

Однако, вы также потеряете кеширование сессий и продюсеров. Вы на самом деле делали правильные вещи раньше - используя фабрику кеширования соединений с cacheConsumers = false. Таким образом, вы получаете лучшее из обоих миров. –

При использовании cachingConnectionFactory работает следующее:

В файле конфигурации яровой добавить в соединение заводской детали конфигурации что-то вроде этого: cacheConsumers="false"

По умолчанию Поведение правда, который вызывает утечку соединения в очереди.

источник

2013-06-11 13:29:25 Gowtham

Каков правильный способ гарантировать, что потребители jms закрыты с помощью интеграции с пружиной?

ответ

Смежные вопросы