Warum Inaktivität Monitor in activemq weiter läuft und Anzeige unter Nachricht in den Protokollen

Question

Ich bin neu in ActiveMQ. Ich habe in meiner Anwendung activemq Message Broker implementiert, aber immer wenn ich in meinen Konsolenprotokollen mit activemq Server verbunden bin, sehe ich immer die folgende Nachricht. Sieht so aus, als würde es die Hörerwarteschlange abfragen. Ich möchte, dass mein Listener aktiv ist, damit die Anwendung die Nachricht verarbeiten kann, wenn die Nachricht in die Warteschlange kommt. Zur gleichen Zeit möchte ich nicht, dass diese Nachricht meine Protokolldatei anhäuft.

10:28:05.282 [ActiveMQ InactivityMonitor WriteCheckTimer] DEBUG o.a.a.t.AbstractInactivityMonitor - WriteChecker: 10000ms elapsed since last write check. 
10:28:05.282 [ActiveMQ InactivityMonitor Worker] DEBUG o.a.a.t.AbstractInactivityMonitor - Running WriteCheck[tcp://10.211.127.203:61616] 

Meine Nachricht Konfiguration:

@Configuration 
@EnableJms 
@ImportResource("classpath*:beans.xml") 
public class MessagingConfiguration { 

    @Autowired 
    MongoCredentialEncryptor encryptor; 

    @Value("${activemq.broker.url}") 
    private String BROKER_URL = "tcp://localhost:61616"; 

    @Value("${activemq.request.queue}") 
    private String REQUEST_QUEUE = "test.request"; 

    @Value("${activemq.response.queue}") 
    private String RESPONSE_QUEUE = "test.response"; 

    @Value("${activemq.borker.username}") 
    private String BROKER_USERNAME = "admin"; 

    @Value("${activemq.borker.password}") 
    private String BROKER_PASSWORD = "admin"; 

    @Autowired 
    ListenerClass messageListener; 

    @Autowired 
    JmsExceptionListener jmsExceptionListener; 

    @Bean 
    public ActiveMQConnectionFactory connectionFactory() { 
     ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(); 
     connectionFactory.setBrokerURL(BROKER_URL); 
     connectionFactory.setUserName(BROKER_USERNAME); 
     //connectionFactory.setPassword(BROKER_PASSWORD); 
     connectionFactory.setPassword(encryptor.decrypt(BROKER_PASSWORD)); 
     connectionFactory.setTrustAllPackages(true); 
     connectionFactory.setRedeliveryPolicy(redeliveryPolicy()); 
     return connectionFactory; 
    } 

    @Bean 
    public RedeliveryPolicy redeliveryPolicy() { 
     RedeliveryPolicy redeliveryPolicy = new RedeliveryPolicy(); 
     redeliveryPolicy.setBackOffMultiplier(3); // Wait 5 seconds first re-delivery, then 15, 45 seconds 
     redeliveryPolicy.setInitialRedeliveryDelay(5000); 
     redeliveryPolicy.setMaximumRedeliveries(3); 
     redeliveryPolicy.setUseExponentialBackOff(true); 
     return redeliveryPolicy; 
    } 

    @Bean 
    public ConnectionFactory cachingConnectionFactory() { 
     CachingConnectionFactory connectionFactory = new CachingConnectionFactory(); 
     connectionFactory.setTargetConnectionFactory(connectionFactory()); 
     connectionFactory.setExceptionListener(jmsExceptionListener); 
     connectionFactory.setSessionCacheSize(100); 
     connectionFactory.setCacheConsumers(false); 
     connectionFactory.setCacheProducers(false); 
     return connectionFactory; 
    } 

    @Bean 
    public JmsTemplate jmsTemplate() { 
     JmsTemplate template = new JmsTemplate(); 
     template.setConnectionFactory(connectionFactory()); 
     template.setDefaultDestinationName(REQUEST_QUEUE); 
     template.setSessionAcknowledgeModeName("CLIENT_ACKNOWLEDGE"); 
     template.setMessageConverter(converter()); 
     return template; 
    } 

    @Bean 
    public DefaultMessageListenerContainer jmsListenerContainer() { 
     DefaultMessageListenerContainer factory = new DefaultMessageListenerContainer(); 
     factory.setConnectionFactory(connectionFactory()); 
     factory.setConcurrency("1-1"); 
     factory.setDestinationName(RESPONSE_QUEUE); 
     factory.setMessageListener(messageListener); 
     factory.setExceptionListener(jmsExceptionListener); 
     return factory; 
    } 

    @Bean 
    MessageConverter converter() { 
     MappingJackson2MessageConverter converter = new MappingJackson2MessageConverter(); 
     converter.setTargetType(MessageType.TEXT); 
     converter.setTypeIdPropertyName("_type"); 
     return converter; 
    } 

} 

Lösung: ich eine Lösung für mein Problem gefunden, indem die InactivityMonitor deaktivieren, indem Sie diesen Link ActiveMQ InactivityMonitor. Ich habe es getestet, die Verbindung ist immer noch am Leben und es ist nicht weiter auf die Warteschlange warten. Aber ich würde gerne wissen, gibt es einen Sturz durch Deaktivieren InactivityMonitor? Gibt es eine bessere Lösung für dieses Problem?

activemq.broker.url=failover:tcp://localhost:61616?wireFormat.maxInactivityDuration=0 

Answer 1

Die Lösung ist einfach, Ihre Logging-Einstellungen ändern sich nicht auf Debug-Level zu schreiben oder filtern, dass ein Logger nicht auf Debug-Ebene zu sein. Die Protokolle halten Sie auf dem Laufenden, dass der Client erfolgreich den Remote-Broker anpingt, um sicherzustellen, dass die Verbindung aufrechterhalten wird. Wenn Sie die Überwachung deaktivieren, dann können Sie verpassen Drop-Ereignisse sind Dinge wie halbgeschlossene Sockets etc.

In der Produktion möchten Sie wirklich keine Verbindung überprüfen Funktionen deaktivieren, die Ihren Code verpassen die Tatsache, dass es ist nicht in der Lage, etwas zu empfangen

Answer 2

Vielen Dank Tim für Ihre Empfehlung. Ich habe diese Protokollierung auf WARN-Ebene verschoben.

<logger name="org.apache.activemq.transport" level="WARN"/>