Configuring Message Listener Container

Question

I have the below configuration which sets up a "MessageReader" pojo class to process incoming messages. This is working fine as it is configured, but since I do not have a lot of experience with Spring Integration, I have some basic questions on what is happening underneath and if it can be monitored.

1. I am not able to find documentation on how often the underlying Message Listener Container will poll the queue for messages. Am I missing something? If I understand the below configuration correctly, it will by default use the "DefaultMessageListenerContainer". I see that class extends AbstractPollingMessageListenerConainer. I see a receiveTimeout, but don't see anything specifying a polling interval. Is there such a setting? It seems pretty instantaneous when I test with it configured as you see below. Our needs are not that aggresive; we would be fine with the queue being polled every 30 seconds or so.
2. Is there a way (perhaps simply a log4j setting) that I can log when the container wakes up and looks for messages on the queue (even if none are found)? Our sustainment team wants to be able to verify that the process is "running" even when no messages are being sent. In other words, they want a way of troubleshooting if the container may have become hung. This would be simply a tool of ruling out a hung thread in the case that messages are believed to have been sent, but not having seen them received.

I realize that I may have to configure a container instead of accepting the defaults like I have below, but I'm fine with that if I can accomplish the above things??

<int:channel id="inboundChannel" />

<jms:message-driven-channel-adapter 
  connection-factory="myConnectionFactory" 
  destination="queue" channel="inboundChannel" />

<int:service-activator input-channel="inboundChannel">
  <bean class="com.myapp.MessageReader" />
</int:service-activator>   

Answer 1

The container is message-driven - it always has a thread (or threads) blocked in the provider's client library waiting for a new message to arrive - it's not polling the queue, it's polling the client. The receive timeout (default 5 seconds) is simply so the container can react to a stop() (otherwise the thread will be blocked in the client with no way to interrupt it - depending on the client's implementation).

If you turn on TRACE debugging, you'll see this activity - but please remember this does not mean there is a round trip to the broker each time, it's simply asking the client if a new message has arrived from the broker.

When the container creates the consumer, the broker knows about it and will send messages directly - there's no polling of the queue per se.

Answer 2

If you are using a message listener, you just define the receive callback function, and you delegate the receive task to the library. From a logical or design perspective, you are not polling: Your function gets called "immediately" (it's not real-time, but it should be really smaller than 30s).

As for monitoring: I would not rely on log messages only. To check the communication channels as well I suggest sending a "ping" request to your message listener. It could respond by sending a "pong" message on another queue (exclusively for monitoring). Together with the current number of waiting messages in the queue, and the ping/pong roundtrip time, the monitoring system can decide whether operating should have a look at it.