ActiveMQ: Ausnahmen für "Kanal zu lange inaktiv" beenden das Broker-Messaging

Mein System besteht aus folgenden Teilen:

ActiveMQ-Broker auf TCP, Port 61616 verfügbar gemacht3 Grails / Spring Wars, die auf ihren eigenen Tomcat-Servern installiert sind, veröffentlichen und verarbeiten Nachrichten an den JMS-Brokern-mal Remote-Client-System mit einer JMS-Listener-Komponente zum Empfangen clientspezifischer Nachrichten. Stellen Sie über VPN eine Verbindung zum JMS-Broker her, und verwenden Sie einen Hostnamen und Port 61616

Bisher funktioniert alles in allen Entwicklungs-, Test- und Produktionsumgebungen.

Wir haben gerade ein neues Client-System in der Produktion verbunden und festgestellt, dass in den Protokollen Ausnahmen gemeldet werden, dass der Kanal zu lange inaktiv war, und die Verbindung getrennt wird. Der Gesamteffekt dieses einen Clients ist besorgniserregend, dass der gesamte Nachrichtenverbrauch auf dem Broker gestoppt wird, sodass das gesamte System zum Stillstand kommt.

Dieser Client-Listener (der die Spring-Caching-Verbindungsfactory verwendet) scheint eine Verbindung zum JMS-Broker herzustellen, verarbeitet einige Nachrichten und meldet die Ausnahme nach 3 Minuten. Aktivierte DEBUG in ActiveMQ und bekam jede Menge Ausgaben, nichts deutet jedoch gleichzeitig auf eine Warnung oder einen Fehler auf dem Broker hin.

Glauben Sie, dass ActiveMQ über einige interne Keep-Alive-Funktionen verfügt, die die Verbindung auch dann aufrechterhalten sollten, wenn sie länger als die Standard-30-Sekunden inaktiv sind.

Die Mitarbeiter der Infrastruktur haben das VPN dieses Clients überwacht und bestätigt, dass es die ganze Zeit über aktiv und verbunden ist.

Glauben Sie nicht, dass es sich um Code oder Spring-Konfiguration handelt, da wir zahlreiche andere Instanzen des Listeners in verschiedenen Clients haben und sie sich alle gut verhalten.

Angenommen, ich habe wirklich zwei Fragen:

Was verursacht "Kanal inaktiv" -Ausnahmen?Warum verhindert diese Ausnahme in einem einzelnen Client, dass ActiveMQ funktioniert?

EDIT - Exception Stacktrace hinzufügen:

2013-04-24 14:02:06,359 WARN  - Encountered a JMSException - resetting the underlying JMS Connection (org.springframework.jms.connection.CachingConnectionFactory)
javax.jms.JMSException: Channel was inactive for too (>30000) long: jmsserver/xxx.xx.xx.xxx:61616
    at org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:49)
    at org.apache.activemq.ActiveMQConnection.onAsyncException(ActiveMQConnection.java:1833)
    at org.apache.activemq.ActiveMQConnection.onException(ActiveMQConnection.java:1850)
    at org.apache.activemq.transport.TransportFilter.onException(TransportFilter.java:101)
    at org.apache.activemq.transport.ResponseCorrelator.onException(ResponseCorrelator.java:126)
    at org.apache.activemq.transport.TransportFilter.onException(TransportFilter.java:101)
    at org.apache.activemq.transport.TransportFilter.onException(TransportFilter.java:101)
    at org.apache.activemq.transport.WireFormatNegotiator.onException(WireFormatNegotiator.java:160)
    at org.apache.activemq.transport.InactivityMonitor.onException(InactivityMonitor.java:266)
    at org.apache.activemq.transport.InactivityMonitor$4.run(InactivityMonitor.java:186)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:693)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:719)
    at java.lang.Thread.run(Thread.java:813)
Caused by: org.apache.activemq.transport.InactivityIOException: Channel was inactive for too (>30000) long: jmsserver/xxx.xx.xx.xxx:61616
    ... 4 more

Antworten auf die Frage(2)

Ihre Antwort auf die Frage