Integriert Tomcat mit ActiveMQ und Spring DefaultMessageListenerContainer - zu JMS msg wieder

Question

Ich habe folgendes Setup: Tomcat mit eingebetteter ActiveMQ

Ich benutze Frühling Integrationen JmsMessageDrivenChannelAdapter des Adapters zu schaffen, die Nachrichten von ActiveMQ Warteschlange verbraucht wie folgt:

Jms.messageDrivenChannelAdapter(jmsConnectionFactory, TransactedMessageListenerContainer.class) 
     .destination(destination) 
     .errorChannel(errorChannel) 
    .get(); 

wo TransactedMessageListenerContainer ist

public class TransactedMessageListenerContainer extends DefaultMessageListenerContainer { 

    public TransactedMessageListenerContainer() { 
     this.setSessionTransacted(true); 
    } 
} 

Wenn eine Ausnahme auftritt, gibt der ActiveMQ-Broker die Nachricht nicht erneut zurück.

Wenn ich org.apache.activemq.broker.BrokerService für einfache Integrationstests, JMS-Nachrichten erneut zugestellt werden, das heißt ich Wiederholungsmechanismus

erreichen können Wie kann ich das gleiche für die Tomcat mit ActiveMQ erreichen?

fand ich hier: http://activemq.apache.org/tomcat.html, dass manuell Integration ActiveMQ mit Tomcat erlaubt für Topic, Queue und ConnectionFactory- Injektion aber nicht transaktionale Senden und Lieferung, aber ich bin nicht sicher, ob es eine Abhilfe ist oder nicht

unterstützt

Danke für Hilfe!

UPDATE: ich auch rethrow Ausnahme in Fehlerbehandlung wie folgt:

@Bean 
public IntegrationFlow errorHandlingFlow() { 
    return IntegrationFlows.from(IntegrationContextUtils.ERROR_CHANNEL_BEAN_NAME) 
      .handle(this::errorMessageHandler) 
      .get(); 
} 

public void errorMessageHandler(Message<?> message) { 
    log.warn("handling error message"); 
    log.warn("headers: " + message.getHeaders().toString()); 
    log.warn("payload: " + message.getPayload().toString()); 
    MessagingException exception = (MessagingException) message.getPayload(); 
    log.warn("original payload: " + exception.getFailedMessage().getPayload()); 
    throw exception; // make JMS broker redeliver 
} 

Answer 1

Wenn Sie rallback und Nachlieferung haben mögen, Ihr Fehlerstrom muss eine Ausnahme erneut auslösen und nicht schlucken wie es mit ist Standard errorChannel. Sie können ähnliche Fragen und Antworten für sie hier finden.

UPDATE

Nun, nicht sicher, wo ist dein Problem, das ich habe einen Test-Fall ähnlich wie bei Ihnen:

@Autowired 
    private MessageChannel errorChannel; 

    @Bean 
    public IntegrationFlow jmsMessageDrivenFlow() { 
     return IntegrationFlows 
       .from(Jms.messageDrivenChannelAdapter(this.jmsConnectionFactory) 
         .configureListenerContainer(c -> c.sessionTransacted(true)) 
         .errorChannel(this.errorChannel) 
         .destination("jmsMessageDriver")) 
       .<String, String>transform(p -> { 
        throw new RuntimeException("intentional"); 
       }) 
       .get(); 
    } 

    @Bean 
    public IntegrationFlow errorHandlingFlow() { 
     return IntegrationFlows.from(IntegrationContextUtils.ERROR_CHANNEL_BEAN_NAME) 
       .handle(m -> { 
        MessagingException exception = (MessagingException) m.getPayload(); 
        Message<?> failedMessage = exception.getFailedMessage(); 
        throw exception; 
       }) 
       .get(); 
    } 

und auf der Nachlieferung sehe ich diese Header in den failedMessage:

"jms_redelivered" -> "true" 
"JMSXDeliveryCount" -> "2" 

Und ja, wir verwenden Embedded ActiveMQ definitiv in unseren Tests. Das JMS ConnectionFactory wird übrigens für Spring Boot ActiveMQAutoConfiguration geliefert.