Java client NatsMessage message ID parity with Go Choria

[fostercraig]

Hi there:
I'm looking at creating a message using the Java client (latest version 2.16.13) and I'm running into an issue where I see that I have headers created in the Go client but there's not parity in the Java client. This is because I'm using the Go Choria client to create a JetStream message when I publish messages in Go. How would I do the same for a JetStream message in Java? Essentially, I want the same headers: an auto-generated Nats-Msg-Id and a Choria-Sender. I am not sure exactly how to find the message ID. I can insert the sender header just fine when I create the message itself.

[ripienaar]

Bit confused about this - I do t think choria clients set any headers? But maybe I forgot sometning. Certainly we shouldn’t be using message headers.

Not sure where Java come in. Will need more info sorry

[fostercraig]

This NatsMessage method is a public method and sets such headers.

I'm trying to find the same thing in Java or at least find a message ID for a message created using the Java client. I don't want to supply my own.

[ripienaar]

Right for submit that makes sense.

These concepts - message ID - are choria concepts so if you need a ID you have to generate them however you went and add them. It’s not sometning Java client does

[fostercraig]

Ok. I think my confusion arises from the naming—iow, if it’s NATs having a message ID I thought I would have consistency on the same bus. I see what you mean though that this is client supplied.

…

On Mon, Jul 24, 2023 at 10:41 PM R.I.Pienaar ***@***.***> wrote: Right for submit that makes sense. These concepts - message ID - are choria concepts so if you need a ID you have to generate them however you went and add them. It’s not sometning Java client does — Reply to this email directly, view it on GitHub <#40 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIGCFD4MI37UXQ2H2BE7WDXR5MBDANCNFSM6AAAAAA2WJ4IY4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[ripienaar]

Yes the idea with nats message id is that the client can decide what constitutes a duplicate - it would maybe be entirely a app specific ID like sales transaction ID and not related to individual messages.

So nats or nats clients can’t really decide.

In this use case I take a message from disk and publish it to jetstream - so the ID is the message on disk no matter how many times over how many invocations I try to publish it.