[
https://issues.apache.org/jira/browse/PROTON-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Campbell updated PROTON-1661:
------------------------------------
Description:
Tested in both proton-c version 0.11.1 and 0.17.0 with qpid broker 1.36.0
Problem:
Function "pn_find_link()" incorrectly returns a link when argument "name"
matches first N characters of existing link.
i.e.:
1) QPID client creates receiver with address "amq.topic/fooBar":
Broker will call function pn_find_link( ssn, name = "fooBar", true) which
returns NULL as expected. Link is initialized and receiver works as expected.
2) Some time later the same QPID client creates second receiver with address
"amq.topic/foo":
Broker will call function pn_find_link( ssn, name="foo", true) which
incorrectly returns pointer to existing link. Expected behavior is to return
NULL so that link will (later) be initialized.
This is because if() starting on line 1268 of proton-c/src/core/transport.c
only uses strncmp().
eg: "strncmp( "foo", "fooBar", 3) == 0"
That if() also needs to check +sizes of the names+ and only do "strncmp()" if:
"(name.size == strlen(pn_string_get(link->name)))"
Symptoms:
Qpid client blocks indefinitely on second ConnectionContext::createReceiver()
waiting for link to be established. Broker never does PN_LINK_INIT because it
incorrectly believes link already exists, client is hung waiting for message
back from broker.
was:
Tested in both proton-c version 0.11.1 and 0.17.0 with qpid broker 1.36.0
Problem:
Function "pn_find_link()" incorrectly returns a link when argument "name"
matches first N characters of existing link.
i.e.:
1) QPID client creates receiver with address "amq.topic/fooBar":
Broker will call function pn_find_link( ssn, name = "fooBar", true) which
returns NULL as expected. Link is initialized and receiver works as expected.
2) Some time later QPID client creates second receiver with address
"amq.topic/foo":
Broker will call function pn_find_link( ssn, name="foo", true) which
incorrectly returns pointer to existing link. Expected behavior is to return
NULL so that link will (later) be initialized.
This is because if() starting on line 1268 of proton-c/src/core/transport.c
only uses strncmp().
eg: "strncmp( "foo", "fooBar", 3) == 0"
That if() also needs to check +sizes of the names+ and only do "strncmp()" if:
"(name.size == strlen(pn_string_get(link->name)))"
Symptoms:
Qpid client blocks indefinitely on second ConnectionContext::createReceiver()
waiting for link to be established. Broker never does PN_LINK_INIT because it
incorrectly believes link already exists, client is hung waiting for message
back from broker.
> Incomplete name comparision in transport.c pn_find_link()
> ---------------------------------------------------------
>
> Key: PROTON-1661
> URL: https://issues.apache.org/jira/browse/PROTON-1661
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
> Affects Versions: 0.11.1, proton-c-0.17.0
> Environment: RedHat EL 5 & 7
> Reporter: Nathan Campbell
>
> Tested in both proton-c version 0.11.1 and 0.17.0 with qpid broker 1.36.0
> Problem:
> Function "pn_find_link()" incorrectly returns a link when argument "name"
> matches first N characters of existing link.
> i.e.:
> 1) QPID client creates receiver with address "amq.topic/fooBar":
> Broker will call function pn_find_link( ssn, name = "fooBar", true) which
> returns NULL as expected. Link is initialized and receiver works as expected.
> 2) Some time later the same QPID client creates second receiver with address
> "amq.topic/foo":
> Broker will call function pn_find_link( ssn, name="foo", true) which
> incorrectly returns pointer to existing link. Expected behavior is to return
> NULL so that link will (later) be initialized.
> This is because if() starting on line 1268 of proton-c/src/core/transport.c
> only uses strncmp().
> eg: "strncmp( "foo", "fooBar", 3) == 0"
> That if() also needs to check +sizes of the names+ and only do "strncmp()" if:
> "(name.size == strlen(pn_string_get(link->name)))"
> Symptoms:
> Qpid client blocks indefinitely on second ConnectionContext::createReceiver()
> waiting for link to be established. Broker never does PN_LINK_INIT because
> it incorrectly believes link already exists, client is hung waiting for
> message back from broker.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
