NULL messages in ChannelInterceptor.postReceive

[iiinc]

I have a simple setup with a single channel, a class that sends 100 messages with a string payload, a simple handler that does nothing but print a log message, and a class implementing ChannelInterceptor.

Everything works as expected until the 100 messages have been sent, after which the interceptor's postReceive method is called once per second with a null "message" parameter, seemingly indefinitely.

When I disable the message sender class, I still get a call to postReceive with a null message once per second, even though nothing in my code is sending messages.

What's going on? All I'm doing is listening... I've written no code except logging statements. I have no loops or anything that could be the source of this.

[Mark Fisher]

The ChannelInterceptor's postReceive() method is invoked every time the channel.receive() method is called. The receive() method is being called by a scheduled dispatcher which is activated to enable the handler to receive messages. The dispatcher is running in a background thread. When messages exist on the channel, you see the Message that is being returned. When no messages are on the channel, you see "null".

-Mark

[iiinc]

Thanks for the help; it all makes sense now.

[Mark Fisher]

In hindsight, the fact that postReceive() is called even when the Message is null seems a bit excessive. I'd be interested if anyone has a good use case for that. Off the top of my head, the only idea would be monitoring, but there are better ways to accomplish that.

-Mark

[william_ferguson_au@yahoo]

Mark, it seems very strange to me that there needs to be polling at all. If a Thread is being used to consume messages from a channel then why wouldn't the Thread only wake up after it was notified that a message was available.

Constant polling seems like unnecessary noise ..
But I guess I'm missing something.

Just curious why that kind of implementation was chosen over notification.

[Mark Fisher]

The consuming thread is the polling thread with a configurable receiveTimeout and polling period. The receive timeout can be any value including < 0 to indicate blocking (i.e. sleep until a message is available).

There is also a channel option that allows the sender thread to dispatch to subscribed handlers directly. This is useful when invocation of those handlers should happen in the sender's thread to participate in the same transaction scope.

[william_ferguson_au@yahoo]

So what benefit is gained by setting a timeout other than < 0 (ie blocking)?

It can't respond to the messages any faster than if it was notified, and it will consume resources when polling for messages that aren't there.

[oleg.zhurakousky]

True. . .
But look at the flips side where you are risking your entire thread pool of consuming threads being locked indefinite while waiting for a message(s) that might not arrive in time or not at all.
IMHO "polling or blocking" strategy should be dictated by the application itself.

[william_ferguson_au@yahoo]

Hmm OK .. I guess I'm looking at this quite differently.

I don't see a problem with having those Threads that I have dedicated to consuming messages sitting idle when there are no messages to consume. I don't consider that as being risky behaviour. It just means they are currently under utilized but are also not putting any stress on the system.

Consider the reverse picture where consuming Threads don't block indefinitely. Those Threads are still not performing any work, but are consuming CPU resource by polling.

Not trying to turn this into a rant, just trying to understand the motivation.

We saw and where similarly confused by the same behaviour with the Spring JMS message driven POJO. No doubt it uses the same mechanism.

[oleg.zhurakousky]

Polling and Blocking are capabilities provided by LinkedBlockingQueue and these capabilities as well as many other from java.util.concurrent are propagated throughout SI. How you use them and when is entirely up to you.
If you think blocking will work for your case then you should use it, but it seem like you are trying to overgeneralize the issue and I don't think it could be addressed is such way.