Re: ProtonJ2 client > senderId used for sender source name
On 2/26/24 12:00, Arnaud Cogoluègnes wrote: Thanks for the reply. My understanding is that it does not matter much, right? Would it be OK to change this line [1] and pass in the address variable instead of the senderId? I tried locally: it does not break the test suite and fixes the link pairing issue. This is trivial, I can submit a PR. I have resolved this in the following issue as it makes sense they sender and receiver should at least be consistent https://issues.apache.org/jira/browse/PROTON-2796 Thanks. [1] https://github.com/apache/qpid-protonj2/blob/b5ac05d77ce697d0290643709bb2f5d718a1a673/protonj2-client/src/main/java/org/apache/qpid/protonj2/client/impl/ClientSenderBuilder.java#L120 On Mon, Feb 26, 2024 at 5:52 PM Robbie Gemmell wrote: I would guess just because it was inspired by earlier code that did much the same long before the link-pair extension ever existed, and it just hasnt been used by anyone wanting to do link pairing (which isnt that widely used; referenced by some other extension specs that..). The protocol spec won't cover this as it is essentially an arbitrary choice in its eyes and indeed for most use cases (unless, say, you try to do link-pairs). What it definitely does say is that you dont need to populate the field at all for the typical 'simple client end' terminus of a link (from memory there is also a c error in there when it covers this, in terms of its references to source/target). I expect the existing options don't let you set the 'local' source/target address since the other side is usually the important one and set implicitly most of the time, and also more so just as the options classes are used in common for sender/receiver creation and so allowing that would mean one of them can easily clash with other configuration and perhaps need additional validation added, e.g clashing with whats set implicitly, or e.g with a request for dynamic that forbids setting it. On Mon, 26 Feb 2024 at 14:58, Arnaud Cogoluègnes wrote: Hi. Any reason for using the senderId instead of the address for the source address of a sender (e.g. [1])? This does not align with what's done for receivers where the address is used for both the source and target address and I don't see anything specific in the spec that justifies this choice. The source address then ends up being something like ID:bbd3c071-efd4-4ee4-be3d-870ee90b7d7e:2:1:1:1. This makes it impossible to implement Link Pairing [2], as the 2 following conditions cannot be met: * The source address for L1 is identical to the target address for L2 * The source address for L2 is identical to the target address for L1 Would it be possible to set the target/source addresses from the client API? Thanks. [1] https://github.com/apache/qpid-protonj2/blob/b5ac05d77ce697d0290643709bb2f5d718a1a673/protonj2-client/src/main/java/org/apache/qpid/protonj2/client/impl/ClientSenderBuilder.java#L120 [2] https://docs.oasis-open.org/amqp/linkpair/v1.0/linkpair-v1.0.html - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org -- Tim Bish - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: ProtonJ2 client > senderId used for sender source name
Thanks for the reply. My understanding is that it does not matter much, right? Would it be OK to change this line [1] and pass in the address variable instead of the senderId? I tried locally: it does not break the test suite and fixes the link pairing issue. This is trivial, I can submit a PR. Thanks. [1] https://github.com/apache/qpid-protonj2/blob/b5ac05d77ce697d0290643709bb2f5d718a1a673/protonj2-client/src/main/java/org/apache/qpid/protonj2/client/impl/ClientSenderBuilder.java#L120 On Mon, Feb 26, 2024 at 5:52 PM Robbie Gemmell wrote: > I would guess just because it was inspired by earlier code that did > much the same long before the link-pair extension ever existed, and it > just hasnt been used by anyone wanting to do link pairing (which isnt > that widely used; referenced by some other extension specs that..). > > The protocol spec won't cover this as it is essentially an arbitrary > choice in its eyes and indeed for most use cases (unless, say, you try > to do link-pairs). What it definitely does say is that you dont need > to populate the field at all for the typical 'simple client end' > terminus of a link (from memory there is also a c error in there > when it covers this, in terms of its references to source/target). > > I expect the existing options don't let you set the 'local' > source/target address since the other side is usually the important > one and set implicitly most of the time, and also more so just as the > options classes are used in common for sender/receiver creation and so > allowing that would mean one of them can easily clash with other > configuration and perhaps need additional validation added, e.g > clashing with whats set implicitly, or e.g with a request for dynamic > that forbids setting it. > > On Mon, 26 Feb 2024 at 14:58, Arnaud Cogoluègnes > wrote: > > > > Hi. > > > > Any reason for using the senderId instead of the address for the source > > address of a sender (e.g. [1])? > > > > This does not align with what's done for receivers where the address is > > used for both the source and target address and I don't see anything > > specific in the spec that justifies this choice. > > > > The source address then ends up being something > > like ID:bbd3c071-efd4-4ee4-be3d-870ee90b7d7e:2:1:1:1. > > > > This makes it impossible to implement Link Pairing [2], as the 2 > following > > conditions cannot be met: > > * The source address for L1 is identical to the target address for L2 > > * The source address for L2 is identical to the target address for L1 > > > > Would it be possible to set the target/source addresses from the client > API? > > > > Thanks. > > > > [1] > > > https://github.com/apache/qpid-protonj2/blob/b5ac05d77ce697d0290643709bb2f5d718a1a673/protonj2-client/src/main/java/org/apache/qpid/protonj2/client/impl/ClientSenderBuilder.java#L120 > > [2] https://docs.oasis-open.org/amqp/linkpair/v1.0/linkpair-v1.0.html > > - > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
Re: ProtonJ2 client > senderId used for sender source name
I would guess just because it was inspired by earlier code that did much the same long before the link-pair extension ever existed, and it just hasnt been used by anyone wanting to do link pairing (which isnt that widely used; referenced by some other extension specs that..). The protocol spec won't cover this as it is essentially an arbitrary choice in its eyes and indeed for most use cases (unless, say, you try to do link-pairs). What it definitely does say is that you dont need to populate the field at all for the typical 'simple client end' terminus of a link (from memory there is also a c error in there when it covers this, in terms of its references to source/target). I expect the existing options don't let you set the 'local' source/target address since the other side is usually the important one and set implicitly most of the time, and also more so just as the options classes are used in common for sender/receiver creation and so allowing that would mean one of them can easily clash with other configuration and perhaps need additional validation added, e.g clashing with whats set implicitly, or e.g with a request for dynamic that forbids setting it. On Mon, 26 Feb 2024 at 14:58, Arnaud Cogoluègnes wrote: > > Hi. > > Any reason for using the senderId instead of the address for the source > address of a sender (e.g. [1])? > > This does not align with what's done for receivers where the address is > used for both the source and target address and I don't see anything > specific in the spec that justifies this choice. > > The source address then ends up being something > like ID:bbd3c071-efd4-4ee4-be3d-870ee90b7d7e:2:1:1:1. > > This makes it impossible to implement Link Pairing [2], as the 2 following > conditions cannot be met: > * The source address for L1 is identical to the target address for L2 > * The source address for L2 is identical to the target address for L1 > > Would it be possible to set the target/source addresses from the client API? > > Thanks. > > [1] > https://github.com/apache/qpid-protonj2/blob/b5ac05d77ce697d0290643709bb2f5d718a1a673/protonj2-client/src/main/java/org/apache/qpid/protonj2/client/impl/ClientSenderBuilder.java#L120 > [2] https://docs.oasis-open.org/amqp/linkpair/v1.0/linkpair-v1.0.html - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
ProtonJ2 client > senderId used for sender source name
Hi. Any reason for using the senderId instead of the address for the source address of a sender (e.g. [1])? This does not align with what's done for receivers where the address is used for both the source and target address and I don't see anything specific in the spec that justifies this choice. The source address then ends up being something like ID:bbd3c071-efd4-4ee4-be3d-870ee90b7d7e:2:1:1:1. This makes it impossible to implement Link Pairing [2], as the 2 following conditions cannot be met: * The source address for L1 is identical to the target address for L2 * The source address for L2 is identical to the target address for L1 Would it be possible to set the target/source addresses from the client API? Thanks. [1] https://github.com/apache/qpid-protonj2/blob/b5ac05d77ce697d0290643709bb2f5d718a1a673/protonj2-client/src/main/java/org/apache/qpid/protonj2/client/impl/ClientSenderBuilder.java#L120 [2] https://docs.oasis-open.org/amqp/linkpair/v1.0/linkpair-v1.0.html
