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

minor refactor for pubsub #75

Merged
merged 5 commits into from
Oct 19, 2023
Merged

minor refactor for pubsub #75

merged 5 commits into from
Oct 19, 2023

Conversation

brayniac
Copy link
Contributor

Minor refactor for pubsub regarding the message validator and trying to make the code more idiomatic.

Minor refactor for pubsub regarding the message validator and
trying to make the code more idiomatic.
@brayniac brayniac requested a review from yangxi October 19, 2023 15:26
@brayniac brayniac requested a review from mihirn October 19, 2023 15:42
error!("pubsub: invalid message received");
RESPONSE_EX.increment();
PUBSUB_RECEIVE_INVALID.increment();
continue;
}
MessageValidationResult::Corrupted => {
Err(ValidationError::Corrupted) => {
Copy link
Contributor

Choose a reason for hiding this comment

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

Curious why one of these cases increments RESPONSE_EX and the other PUBSUB_RECEIVE, but both have a message suggesting they are pubsub messages.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This might be up for debate. Initially my thought was that invalid messages (perhaps produced by some non-rpc-perf process) should be ignored with just an invalid counter incremented.

Some(Ok(message)) => match validator.validate(&mut message.to_owned()) {
Err(ValidationError::Unexpected) => {
error!("pubsub: invalid message received");
RESPONSE_EX.increment();
Copy link
Contributor

Choose a reason for hiding this comment

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

Is it worth moving the counter stuff into the validation function and having a much simpler match case for both consumers?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Great idea. Moved into the validator.

@brayniac brayniac merged commit f025dae into iopsystems:main Oct 19, 2023
12 checks passed
@brayniac brayniac deleted the kafka branch October 19, 2023 16:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants