Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Warn about dropped message in filter #8579

Merged
merged 3 commits into from
Mar 20, 2023

Conversation

artembilan
Copy link
Member

Buy default the MessageFilter just drops a discarded message silently. If a request-reply gateway is used upstream, then it becomes unclear why the flow sometimes doesn't work.

  • Add a waring log ot emit for default behavior. This still doesn't fix the request-reply problem, but at least it can give a clue what is going on

Buy default the `MessageFilter` just drops a discarded message silently.
If a request-reply gateway is used upstream, then it becomes unclear
why the flow sometimes doesn't work.

* Add a waring log ot emit for default behavior.
This still doesn't fix the request-reply problem, but at least it can
give a clue what is going on
}
if (this.throwExceptionOnRejection) {
throw new MessageRejectedException(message, "message has been rejected in filter: " + this);
}
else if (channelToDiscard == null) {
logger.warn(LogMessage.format("The message [%s] has been rejected in filter: %s", message, this));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WARN seems too strong; this might be the desired behavior; I would suggest DEBUG, perhaps with an option to increase the log level.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. As a middle group I can agree for an INFO, which seems a default one for Spring Boot.

Sure! It can be desired behavior when you know what you do.
But if your expectation is request-reply and you miss the fact that simple filter() in the middle of the flow just drops messages silently, it would be great if framework notifies you some way what is going on instead of silence.
Another way I'd suggest is to configure a nullChannel as a discardChannel if you'd like to ignore everything silently.

I also can go more aggressive path and make a throwExceptionOnRejection as default behavior.
So, when we develop everything in default, there is no any silence.

FYI: the next my change will be to fix gateway for its infinite default reply timeout (After you merge that doc PR).
The recommendation in modern design is to never block forever.
This is going to be another signal in the mentioned request-reply and filter scenario that something is not OK or misconfigured 😄 .

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no objection to requiring nullChannel, if it's only a 6.1 change.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it is. Let me add such a sentence into doc and you are feel free to merge thereafter!

@artembilan artembilan requested a review from garyrussell March 20, 2023 16:44
Co-authored-by: Gary Russell <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants