pn_sender / pn_receiver behaviour between proton-c and proton-j

[Dominic Evans <do...@uk.ibm.com>]

In proton-c pn_sender / pn_receiver in the engine will always return a brand
new link.

But their equivalents in SessionImpl in proton-j, keep a cached list of the
existing session links, and return you one of those if you already have a
link with the name you asked for - which is pretty much what pn_find_link
[3] in transport.c does in proton-c.

Assume both should match in order to satisfy the python+jython unittesting.
Which behaviour is correct?

i.e., should proton-c be updated so that the pn_sender / pn_receiver calls
do a search for an existing link on the session first or should proton-j
(jython) be updated so that pn_sender / pn_receiver always return a brand
new link, and the search for existing links is only done in the transport
code?

---

[1] session.c - http://git.io/NBod
[2] SessionImpl.java http://git.io/NBKG
[3] transport.c http://git.io/NBog




--
View this message in context: http://qpid.2158936.n2.nabble.com/pn-sender-pn-receiver-behaviour-between-proton-c-and-proton-j-tp7620199.html
Sent from the Apache Qpid Proton mailing list archive at Nabble.com.

Re: pn_sender / pn_receiver behaviour between proton-c and proton-j

[Rafael Schloming <rh...@alum.mit.edu>]

On Thu, Feb 12, 2015 at 5:54 PM, Dominic Evans <do...@uk.ibm.com>
wrote:

> In proton-c pn_sender / pn_receiver in the engine will always return a
> brand
> new link.
>
> But their equivalents in SessionImpl in proton-j, keep a cached list of the
> existing session links, and return you one of those if you already have a
> link with the name you asked for - which is pretty much what pn_find_link
> [3] in transport.c does in proton-c.
>
> Assume both should match in order to satisfy the python+jython unittesting.
> Which behaviour is correct?
>
> i.e., should proton-c be updated so that the pn_sender / pn_receiver calls
> do a search for an existing link on the session first or should proton-j
> (jython) be updated so that pn_sender / pn_receiver always return a brand
> new link, and the search for existing links is only done in the transport
> code?
>

Ah, is this the reason that proton-c doesn't seem to be impacted by
PROTON-154 even though it was never fixed for proton-c?

There is a third option also. We could have pn_sender/pn_receiver and their
equivalents in proton-j throw an error when a duplicate name is supplied,
and then provide a separate API for finding an existing link with a given
name.

This would be better on the proton-c side because all the ref counting
mechanics are currently set up to assume that pn_sender and pn_receiver
function as constructors, i.e. return a new object with a refcount of 1.
Returning an existing object would introduce an ambiguity/inconsistency
since for querying operations we generally don't increment the refcount of
the result for the caller, we expect the caller to incref if they find it
necessary.

I'd probably also suggest having a convenience option to automatically
generate a unique link name since it is kind of onerous to have to make up
a new one all the time.

--Rafael