-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Warn about dropped message in filter #8579
Conversation
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)); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 😄 .
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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!
Co-authored-by: Gary Russell <[email protected]>
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.