GH-3989 Consider the custom name of the reply topic name in sendAndRec…

[mipo256]

Closes #3989

WIP, writing tests

[sobychacko]

@mipo256 PR build is failing, just letting you know.

[mipo256]

Hey @sobychacko ! I know, thanks! I'll fix the checkstyle violations shortly and then ping you :)

[mipo256]

Hey guys @sobychacko, @artembilan.

I've added some test cases for this scenario and introduced minor polishing, the PR is ready for review

[sobychacko]

Could you elaborate what you mean by migrate to JEP 502 here?

[mipo256]

I mean that in JEP 502 we would have stable values in Java, which are lazily initilized final fields. The lazily computed hashcode and hex representation of correlation id is exactly that use case.

[mipo256]

Hey @sobychacko, can you please re-review? I've answered you questions and fixed the comments that I think we both agree upon.

Thank you!

[artembilan]

Can we have the title of PR and commit message fixed for the typo?
That Consder word is wrong.
Thanks

[mipo256]

Hey @artembilan, sure, it's done

[artembilan]

I don't know issue in details to be sure why we didn't have this feature for years, but it still worth to look into sending-messages.adoc to determine the reason.
And mention this new feature over there if that is what we would want.

Thanks

[artembilan]

OK. I see @sobychacko said in the issue:

not using this.replyTopicHeaderName and directly checking against KafkaHeaders.REPLY_TOPIC in that conditional seems like a bug.

So, feels like this fix is supposed to be a back-port candidate.
Therefore, indeed, all the not relevant changes have to go.

[mipo256]

With all due respect Artem @artembilan, I do not think you're fully in the context of the problem.

I’m not sure how that relates to the issue. The length are supposed to be the same.

No, it is not. And it is the core of the issue. The custom reply header is considered already, and it works fine. The problem arises when the the custom reply header is overridden by the user via public API, and in this case the custom reply header is sent in the kafka message two times. It's get duplicated, see from the original issue:

This leads to duplicate headers (reply topic and reply partition) being set. In my case, this is particularly problematic because I have to provide the reply partition header in a different form - but the ReplyingKafkaTemplate overwrites it with its own header.

I'm reading your code review and I think we have a misunderstanding here. I'll fix all your comments regarding the code style etc, no problem, I'm just making sure we're on the same page.

[mipo256]

As I said: we are aiming to back -port the fix.

My 2 cents. I'm not sure it is a good backport candidate.

This is the bug, and when it get's fixed, then hypothetically, when previously producer produced 4 headers in the message (two for custom reply header, and two for custom reply partition), now it will produce 4.

For me at least, it is highly questionable if this change is backward compatible, since the consumers now will receive de-facto different messages (4 vs 2 headers).

CC : @sobychacko @artembilan

[sobychacko]

Merged via 97f482a.