Update the message size when a pattern is provided via -m

[ankon]

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?

[mhowlett]

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.

[ankon]

One idea could be to have a different option for "size-of-message-with-repeating". The other idea would be exactly the opposite: Keep -m to mean pattern (and therefore -s to mean repeated-size), and add -M or such to mean "complete message". The more I think about it, the more I like the latter -- it wouldn't break any existing code, and just make the life easier for new users.

[mhowlett]

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).

[ankon]

The tool is seriously running out of option characters ... :)

I randomly picked -e now, as that was the first free one, but cannot yet come up with a good name for that.

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 -e is given we set the message pattern to the value, and adjust the size."

What is a bit interesting is conflict handling: "If a -s or -m is given before that -e, the -e wins. If -s or -m is given after -e, then these win." My argument here would be that someone providing both -e and -s/-m should know what they are doing, since that -e is a new option.
An alternative approach could be to abort with an error if -s/-m is given together with -e.

[edenhill]

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.
When -s is < -m, truncate -m.

[ankon]

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.

Works for me! :)

[edenhill]

Great stuff!