-
Notifications
You must be signed in to change notification settings - Fork 3.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
Update the message size when a pattern is provided via -m #1899
Update the message size when a pattern is provided via -m #1899
Conversation
thanks @ankon - i do like the idea of size automatically being set to the message pattern length in the case it's not specified (implementation as you suggest). i don't think it's a good idea for behavior to depend on order in which flags are specified though - it's arguably manageable for just one option, but allowing this sort of thing would quickly get out of hand. |
One idea could be to have a different option for "size-of-message-with-repeating". The other idea would be exactly the opposite: Keep |
I think I agree with you. I think the interface is better with just two arguments, but your 3 argument suggestion seems very reasonable and as you point out avoids breaking anything (which would seem an important consideration here). Would suggest revising the PR (and @edenhill will review when he's available). |
The tool is seriously running out of option characters ... :) I randomly picked I'm also looking a bit into the defaulting logic: Ideally the existing uses all stay what they mean, so the logic would be: "if What is a bit interesting is conflict handling: "If a |
I think the most intuitive approach is to let the message size be strlen(-m), unless it was explicitly set with -s. And yes, it should be possible to set -s before -m. When -s is > -m, repeat -m pattern. |
0cf47a8
to
c4c6fac
Compare
Works for me! :) |
Great stuff! |
I wanted to use the performance tool to stress our application, which requires messages with specific content (JSON, authorization parts, types, ...). Using
-m
to specify the JSON was easy, but I found it very counter-intuitive that it would repeat the pattern/cut it off unless I explicitly also specified the length.This PR changes this behavior so that the length gets adjusted by default when
-m
is used. A user that wants cut-off/repeat can specify the length as before by setting it after the-m
switch.For my purposes this is enough, but it would break uses where the caller runs
rdkafka_performance -s SIZE -m PATTERN
. One approach for avoiding this breakage would be track whether the user set the size explicitly, and only update in-m
when that is not the case. Thoughts?