2011-01-19 2 views
0

Недавно я установил некоторые записи в AcitveMQ в качестве службы огня и забывания, чтобы приложение могло просто отправить сообщение в «ActivityLoggingChannel» и не иметь дело с перекрестные проблемы лесозаготовок.JMS & Spring Integration, устраняя зависимость от наличия экземпляра ActiveMQ

Все отправлено на ActivityLoggingGateway, который является просто интерфейсом с каналом по умолчанию. Затем он запрашивает Pojo (dyanmic router) для имени канала, чтобы получить конечную точку сообщения. Для динамического маршрутизатора есть точка входа JMX, которая позволяет мне переключаться на конечные точки «на лету». Если конечная точка сообщения установлена ​​в jmsChannelSender и не может разрешить URL-адрес ActiveMQ, это приведет к падению всей системы.

Проблема, с которой я столкнулась, заключается в том, что если URL-адрес ActiveMQ недоступен, я хотел бы, чтобы система возвращалась к другому каналу сообщений, который использует простой многопоточный подход к процессу.

Ниже приведена конфигурация интеграции пружин. Использование версии 2.0.0.RELEASE

<?xml version="1.0" encoding="UTF-8"?> 
<beans xmlns="http://www.springframework.org/schema/beans" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xmlns:tx="http://www.springframework.org/schema/tx" 
    xmlns:context="http://www.springframework.org/schema/context" 
    xmlns:int="http://www.springframework.org/schema/integration" 
    xmlns:jms="http://www.springframework.org/schema/integration/jms" 
    xmlns:int-jmx="http://www.springframework.org/schema/integration/jmx" 
    xsi:schemaLocation="http://www.springframework.org/schema/jms http://www.springframework.org/schema/jms/spring-jms-3.0.xsd 
     http://www.springframework.org/schema/integration http://www.springframework.org/schema/integration/spring-integration-2.0.xsd 
     http://www.springframework.org/schema/integration/jmx http://www.springframework.org/schema/integration/jmx/spring-integration-jmx-2.0.xsd 
     http://www.springframework.org/schema/integration/jms http://www.springframework.org/schema/integration/jms/spring-integration-jms-2.0.xsd 
     http://www.springframework.org/schema/integration/stream http://www.springframework.org/schema/integration/stream/spring-integration-stream-2.0.xsd 
     http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd 
     http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.5.xsd 
     http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd"> 

    <import resource="dm-activitylogging-services.xml"/> 

    <bean name="decisionActivityLoggingAspect" class="com.idna.dm.aspects.logging.activity.DecisionActivityLogAspect" 
     factory-method="aspectOf"> 
     <property name="activityLoggingGateway"> 
      <ref bean="activityLoggingGateway" /> 
     </property> 
    </bean> 

<!-- New Activity Logging Services Reference dm-activity-logging -->  
<!-- JMS Channel Adapter --> 
    <int:channel id="jmsSenderChannel" /> 

    <bean id="destinationLocalQueue" class="org.apache.activemq.command.ActiveMQQueue"> 
     <constructor-arg index="0" value="${activemq.queuename.activitylogging}" /> 
    </bean> 

    <bean id="connectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory"> 
     <property name="brokerURL" value="${activemq.url}" /> 
    </bean> 

    <bean id="activityLogConverter" class="com.idna.dm.domain.activitylogging.jms.ActivityLogConverter" /> 
    <jms:outbound-channel-adapter channel="jmsSenderChannel" destination="destinationLocalQueue" connection-factory="connectionFactory" message-converter="activityLogConverter"/> 

<!-- In Process Adapter --> 

    <int:channel id="inProcessChannel" /> 
    <int:outbound-channel-adapter channel="inProcessChannel" ref="inProcessAdapter" method="persistLog" /> 
    <bean id="inProcessAdapter" class="com.idna.dm.logging.activity.impl.InProcessActivityLoggingImpl" > 
     <property name="activityLoggingService" > 
      <ref bean="activityLogging" /> 
     </property> 
    </bean> 

    <int:channel id="asyncInProcessChannel" /> 
    <int:outbound-channel-adapter channel="asyncInProcessChannel" ref="asyncInProcessAdapter" method="persistLog" /> 
    <bean id="asyncInProcessAdapter" class="com.idna.dm.logging.activity.impl.AsyncInProcessActivityLoggingImpl" > 
     <property name="activityLoggingService"> 
      <ref bean="activityLogging" /> 
     </property> 
    </bean> 

<!-- Custom channel for console output using the router --> 

    <!-- Console Channel 
    <int:channel id="consoleAdapterChannel" /> 
    <int:outbound-channel-adapter channel="consoleAdapterChannel" ref="consoleAdapter" method="printToStdout" /> 
    <bean id="consoleAdapter" class="com.idna.dm.logging.activity.util.StdoutTargetAdapter" /> 
    --> 

    <!-- Log4j Channel --> 
    <int:channel id="loggingChannel" /> 
    <int:logging-channel-adapter auto-startup="true" level="INFO" log-full-message="true" channel="loggingChannel" /> 

<!-- Router --> 
    <int:gateway id="activityLoggingGateway" 
     service-interface="com.idna.dm.logging.activity.logger.ActivityLoggingGateway" /> 


    <int:channel id="activityLoggingChannel" /> 

    <int:router input-channel="activityLoggingChannel" ref="dynamicRouter" 
     method="route" default-output-channel="asyncInProcessChannel" 
     ignore-channel-name-resolution-failures="true" /> 

    <bean id="dynamicRouter" class="com.idna.dm.logging.activity.router.DynamicRouter"> 
     <constructor-arg index="0" value="asyncInProcessChannel" /> 
    </bean> 
+0

Хорошая идея, так что в чем вопрос? – iwein

+0

Извините, мой вопрос здесь больше не уместен, но я спрашивал о том, как найти способ вернуться к асинхронному каналу в качестве сбоя для ActiveMQ. Поэтому, если бы MQ опустился, я бы просто передал MQ. Теперь у нас есть отдельный активный экземпляр MQ в качестве сервера отказоустойчивости, поэтому это уже не проблема. – DeliveryNinja

ответ

0

Вы можете достичь его с помощью failover механизма:

<channel id="input"> 
    <dispatcher load-balancer="none"/> 
</channel> 

<service-activator input-channel="input" order="1"/> 

<service-activator input-channel="input" order="2"/> 

В этом случае первый <service-activator> будет всегда вызывается первым. И второй, только если первый не удастся.

failover - true по умолчанию.

+0

Только 3 года опоздали;) В эти дни мы продолжили использование Spring интеграции с RabbitMQ. – DeliveryNinja

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