[jira] [Updated] (PROTON-120) Link.delivery() signature takes offset and size which are not used
[ https://issues.apache.org/jira/browse/PROTON-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-120: -- Attachment: delivery_signature.patch This patch changes the signature, removing the offset and size. The other option is to use the offset and size. If that route is intended, I can add a patch for that instead. Link.delivery() signature takes offset and size which are not used -- Key: PROTON-120 URL: https://issues.apache.org/jira/browse/PROTON-120 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.1, 0.2 Reporter: Gordon Sim Priority: Minor Fix For: 0.3 Attachments: delivery_signature.patch One option is that these should be used. Another is that they can be removed from the API. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-119) Engine can switch from SASL to plain AMQP transport too soon
[ https://issues.apache.org/jira/browse/PROTON-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-119: -- Attachment: sasl_engine.patch One possible fix... this simply adds a flag to track whether the init has been sent and uses that in deciding when to switch output. Engine can switch from SASL to plain AMQP transport too soon Key: PROTON-119 URL: https://issues.apache.org/jira/browse/PROTON-119 Project: Qpid Proton Issue Type: New Feature Components: proton-j Affects Versions: 0.1, 0.2 Reporter: Gordon Sim Fix For: 0.3 Attachments: sasl_engine.patch The engine gets output from the AMQP engine rather than SASL wrapper as soon as the SASl negotiation is marked as done. In the case where the 'server' only supports ANONYMOUS and immediately sends an outcome without actually waiting for the initial frame from the client, this happens too soon, before the init is sent (and even the SASL header). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (PROTON-119) Engine can switch from SASL to plain AMQP transport too soon
[ https://issues.apache.org/jira/browse/PROTON-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reassigned PROTON-119: - Assignee: Gordon Sim Engine can switch from SASL to plain AMQP transport too soon Key: PROTON-119 URL: https://issues.apache.org/jira/browse/PROTON-119 Project: Qpid Proton Issue Type: New Feature Components: proton-j Affects Versions: 0.1, 0.2 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.3 Attachments: sasl_engine.patch The engine gets output from the AMQP engine rather than SASL wrapper as soon as the SASl negotiation is marked as done. In the case where the 'server' only supports ANONYMOUS and immediately sends an outcome without actually waiting for the initial frame from the client, this happens too soon, before the init is sent (and even the SASL header). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-118) Add support for Messenger API
[ https://issues.apache.org/jira/browse/PROTON-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490881#comment-13490881 ] Gordon Sim commented on PROTON-118: --- Two deviations from the C to highlight: (i) at present the Sender.unsettled() method isn't implemented so I couldn't rely on that for determining when send() can stop blocking. That is a temporary deviation only, just to make some progress with the rest of it. (ii) in matching a message's address to a connection, I use the context on the connection to hold the host:port combination used to create it and match against that. This is in part because I was confused about the respective meaning of hostname and remote-hostname, and the facet that one has only a setter, the other only a getter. However it also seemed wrong to append the port to a 'hostname' (which seems to be what the C impl does). Thoughts on that particularly welcome. Add support for Messenger API - Key: PROTON-118 URL: https://issues.apache.org/jira/browse/PROTON-118 Project: Qpid Proton Issue Type: New Feature Components: proton-j Affects Versions: 0.1, 0.2 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.3 Attachments: driver.patch, engine.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-118) Add support for Messenger API
[ https://issues.apache.org/jira/browse/PROTON-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-118: -- Attachment: (was: driver.patch) Add support for Messenger API - Key: PROTON-118 URL: https://issues.apache.org/jira/browse/PROTON-118 Project: Qpid Proton Issue Type: New Feature Components: proton-j Affects Versions: 0.1, 0.2 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.3 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-118) Add support for Messenger API
[ https://issues.apache.org/jira/browse/PROTON-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-118: -- Attachment: (was: engine.patch) Add support for Messenger API - Key: PROTON-118 URL: https://issues.apache.org/jira/browse/PROTON-118 Project: Qpid Proton Issue Type: New Feature Components: proton-j Affects Versions: 0.1, 0.2 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.3 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-118) Add support for Messenger API
[ https://issues.apache.org/jira/browse/PROTON-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13492398#comment-13492398 ] Gordon Sim commented on PROTON-118: --- Added slightly updated versions of the patches to review board: https://reviews.apache.org/r/7932/ https://reviews.apache.org/r/7934 Add support for Messenger API - Key: PROTON-118 URL: https://issues.apache.org/jira/browse/PROTON-118 Project: Qpid Proton Issue Type: New Feature Components: proton-j Affects Versions: 0.1, 0.2 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.3 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-120) Link.delivery() signature takes offset and size which are not used
[ https://issues.apache.org/jira/browse/PROTON-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13492488#comment-13492488 ] Gordon Sim commented on PROTON-120: --- Ok, that sounds reasonable. I'll make the change as you suggest. Link.delivery() signature takes offset and size which are not used -- Key: PROTON-120 URL: https://issues.apache.org/jira/browse/PROTON-120 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.1, 0.2 Reporter: Gordon Sim Assignee: Gordon Sim Priority: Minor Fix For: 0.3 Attachments: delivery_signature.patch One option is that these should be used. Another is that they can be removed from the API. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-120) Link.delivery() signature takes offset and size which are not used
[ https://issues.apache.org/jira/browse/PROTON-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-120: -- Attachment: (was: delivery_signature.patch) Link.delivery() signature takes offset and size which are not used -- Key: PROTON-120 URL: https://issues.apache.org/jira/browse/PROTON-120 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.1, 0.2 Reporter: Gordon Sim Assignee: Gordon Sim Priority: Minor Fix For: 0.3 One option is that these should be used. Another is that they can be removed from the API. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-157) invalid delivery-id sent(?)
Gordon Sim created PROTON-157: - Summary: invalid delivery-id sent(?) Key: PROTON-157 URL: https://issues.apache.org/jira/browse/PROTON-157 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.2 Reporter: Gordon Sim E.g. the following trace is from the client side (the peer was qpidd) and appears to show a delivery-id being skipped: [0xb2a800:1] - TRANSFER @20 [1, 1520, b\xf0\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xbd\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd1\xc5\xdf\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1521, b\xf1\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xbe\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd1\xe8c\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1522, b\xf2\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xbf\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd2\x8b\x95\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1523, b\xf3\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xc0\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd2\xa8\xa5\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1525, b\xf4\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xc1\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd2\xc01\x00Su\xa0d [0xb2a800:0] - CLOSE @24 [@29 [:amqp:session:invalid-field]] ERROR amqp:session:invalid-field sequencing error, expected delivery-id 1524, got 1525 It is of course possible that I am doing something wrong in the broker code, but I can't think what would cause something like this (since I can't influence the delivery ids directly). It only seems to happen when there is a prefetch greater than 900. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-157) invalid delivery-id sent(?)
[ https://issues.apache.org/jira/browse/PROTON-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13502920#comment-13502920 ] Gordon Sim commented on PROTON-157: --- The error always occurs when expecting some number ending in 24 (and the actual value is one higher, ending in 25). invalid delivery-id sent(?) --- Key: PROTON-157 URL: https://issues.apache.org/jira/browse/PROTON-157 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.2 Reporter: Gordon Sim E.g. the following trace is from the client side (the peer was qpidd) and appears to show a delivery-id being skipped: [0xb2a800:1] - TRANSFER @20 [1, 1520, b\xf0\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xbd\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd1\xc5\xdf\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1521, b\xf1\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xbe\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd1\xe8c\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1522, b\xf2\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xbf\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd2\x8b\x95\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1523, b\xf3\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xc0\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd2\xa8\xa5\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1525, b\xf4\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xc1\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd2\xc01\x00Su\xa0d [0xb2a800:0] - CLOSE @24 [@29 [:amqp:session:invalid-field]] ERROR amqp:session:invalid-field sequencing error, expected delivery-id 1524, got 1525 It is of course possible that I am doing something wrong in the broker code, but I can't think what would cause something like this (since I can't influence the delivery ids directly). It only seems to happen when there is a prefetch greater than 900. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-158) detach with invalid handle causes segfault
Gordon Sim created PROTON-158: - Summary: detach with invalid handle causes segfault Key: PROTON-158 URL: https://issues.apache.org/jira/browse/PROTON-158 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.2 Reporter: Gordon Sim I.e. a detach where the handle was not previously used in an attach -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-160) Allow open.hostname to be configured independently of network hostname
[ https://issues.apache.org/jira/browse/PROTON-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505408#comment-13505408 ] Gordon Sim commented on PROTON-160: --- I greatly prefer option (3) as outlined at the end of comment #1(https://issues.apache.org/jira/browse/PROTON-160?focusedCommentId=13505199), i.e. having some way to configure a messenger to handle addresses (falling back to DNS based resolution if no rules exist/apply). Per-message addresses should ideally be logical with a flexible mapping to the physical addresses over which they should then be transferred. Option 3 seems the safest and neatest solution. I find option 1 confusing as well as I think being to tied to a particular pattern of use. I thinks URLs are actually a less than ideal choice for the address syntax as they confuse the notions of (hierarchical) domain scoped logical naming with 'connection strings', and adding in various options and parameters is I think the thin end of the wedge that will lead to muddiness. Allow open.hostname to be configured independently of network hostname -- Key: PROTON-160 URL: https://issues.apache.org/jira/browse/PROTON-160 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.1, 0.2 Reporter: David Ingham In a scaled-out, multi-tenant broker environment, the host on which the container is running is often different from the host to which a client is establishing the tcp connection. The 'hostname' field in the connection open performative was added to support this scenario. Currently there's no way to control this from the Messenger API. Options include: (1) (preferred) add a new 'networkhost' field to Message to allow the network address to be specified. If provided, this information would be used when establishing the network connection and the data in the 'address' field would be used in the connection open hostname field. This is somewhat in line with the way that connection redirect (amqp:connection:redirect) is specified. (2) extend the syntax of address with query string to supply hostname, e.g., username:password@tcpaddress:tcpport/entityname?hostname=foo where 'foo' would become the hostname used in the connection open frame. This is the approach used by the current Qpid AMQP 1.0 JMS client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-170) generated pkg config file doesn't actually include paths if a different install location is used
Gordon Sim created PROTON-170: - Summary: generated pkg config file doesn't actually include paths if a different install location is used Key: PROTON-170 URL: https://issues.apache.org/jira/browse/PROTON-170 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.2 Reporter: Gordon Sim E.g. cmake -DCMAKE_INSTALL_PREFIX=/path/to/non-standard/install make install will install a pkg config file that doesn't have the include and lib directories set. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (PROTON-170) generated pkg config file doesn't actually include paths if a different install location is used
[ https://issues.apache.org/jira/browse/PROTON-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reassigned PROTON-170: - Assignee: Andrew Stitcher Andrew, requesting review from someone more expert in cmake and pkgconfig... generated pkg config file doesn't actually include paths if a different install location is used Key: PROTON-170 URL: https://issues.apache.org/jira/browse/PROTON-170 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.2 Reporter: Gordon Sim Assignee: Andrew Stitcher Attachments: PROTON-170.patch E.g. cmake -DCMAKE_INSTALL_PREFIX=/path/to/non-standard/install make install will install a pkg config file that doesn't have the include and lib directories set. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-170) generated pkg config file is broken
[
https://issues.apache.org/jira/browse/PROTON-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim updated PROTON-170:
--
Description:
E.g. cmake -DCMAKE_INSTALL_PREFIX=/path/to/non-standard/install make install
will install a pkg config file that doesn't have the include and lib
directories set.
Also Cflags is set to -I${includedir} which breaks compilation even for a
standard install if the includedir is not set.
was:E.g. cmake -DCMAKE_INSTALL_PREFIX=/path/to/non-standard/install make
install will install a pkg config file that doesn't have the include and lib
directories set.
Summary: generated pkg config file is broken (was: generated pkg
config file doesn't actually include paths if a different install location is
used)
generated pkg config file is broken
---
Key: PROTON-170
URL: https://issues.apache.org/jira/browse/PROTON-170
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.2
Reporter: Gordon Sim
Assignee: Andrew Stitcher
Attachments: PROTON-170.patch
E.g. cmake -DCMAKE_INSTALL_PREFIX=/path/to/non-standard/install make
install will install a pkg config file that doesn't have the include and lib
directories set.
Also Cflags is set to -I${includedir} which breaks compilation even for a
standard install if the includedir is not set.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-170) generated pkg config file is broken
[
https://issues.apache.org/jira/browse/PROTON-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13507609#comment-13507609
]
Gordon Sim commented on PROTON-170:
---
The comment was added after you put the template into protons tree (I think as
part of some automated process in response to RAT), so in qpid it has no
comment (which I actually think is probably not a problem anyway).
generated pkg config file is broken
---
Key: PROTON-170
URL: https://issues.apache.org/jira/browse/PROTON-170
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.2
Reporter: Gordon Sim
Assignee: Andrew Stitcher
Attachments: PROTON-170.patch
E.g. cmake -DCMAKE_INSTALL_PREFIX=/path/to/non-standard/install make
install will install a pkg config file that doesn't have the include and lib
directories set.
Also Cflags is set to -I${includedir} which breaks compilation even for a
standard install if the includedir is not set.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-157) invalid delivery-id sent(?)
[
https://issues.apache.org/jira/browse/PROTON-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13508786#comment-13508786
]
Gordon Sim commented on PROTON-157:
---
I believe I now understand how this comes about. The delivery buffer is filled
up with outgoing transfers. However, as credit is added by the peer, more
deliveries can be queued up in the tpwork queue. Then a disposition comes in
for a portion of the previously sent messages. This results in the broker
settling those transfers which causes those deliveries to be added back onto
the tpwork queue, behind the deliveries yet to be sent. Another delivery may
now be added on to the tp work queue. If the pwork queue is then processed, it
goes through the first batch of unset deliveries, but there is still no space
in the delivery bufer, so these are left as is. It then processes the batch of
settled messages, cleans up the delivery buffer and removes them from tpwork.
Now finally it gets to the next unsent delivery, added after these. Since the
buffer has now been cleaned, this gets assigned the next delivery id. However
there are transfers ahead of it in the queue that have *not* yet had a delivery
state assigned. The next time tp work is processed, these will get delivery
state assigned with the delivery id out of sync.
A suggested fix (that works for my case and passes tests) is to detect when we
have removed deliveries from tp work, and start processing from the head. This
may not be optimal in all cases of course, but it is a simple change:
{noformat}
Index: proton-c/src/engine/engine.c
===
--- proton-c/src/engine/engine.c(revision 1416552)
+++ proton-c/src/engine/engine.c(working copy)
@@ -2219,7 +2219,11 @@
pn_clear_tpwork(delivery);
}
- delivery = delivery-tpwork_next;
+ if (delivery-tpwork) {
+delivery = delivery-tpwork_next;
+ } else {
+delivery = conn-tpwork_head;
+ }
}
}
{noformat}
invalid delivery-id sent(?)
---
Key: PROTON-157
URL: https://issues.apache.org/jira/browse/PROTON-157
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.2
Reporter: Gordon Sim
E.g. the following trace is from the client side (the peer was qpidd) and
appears to show a delivery-id being skipped:
[0xb2a800:1] - TRANSFER @20 [1, 1520, b\xf0\x05\x00\x00\x00\x00\x00\x00,
0, false, false] (177)
\x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xbd\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd1\xc5\xdf\x00Su\xa0d
[0xb2a800:1] - TRANSFER @20 [1, 1521, b\xf1\x05\x00\x00\x00\x00\x00\x00,
0, false, false] (177)
\x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xbe\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd1\xe8c\x00Su\xa0d
[0xb2a800:1] - TRANSFER @20 [1, 1522, b\xf2\x05\x00\x00\x00\x00\x00\x00,
0, false, false] (177)
\x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xbf\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd2\x8b\x95\x00Su\xa0d
[0xb2a800:1] - TRANSFER @20 [1, 1523, b\xf3\x05\x00\x00\x00\x00\x00\x00,
0, false, false] (177)
\x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xc0\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd2\xa8\xa5\x00Su\xa0d
[0xb2a800:1] - TRANSFER @20 [1, 1525, b\xf4\x05\x00\x00\x00\x00\x00\x00,
0, false, false] (177)
\x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xc1\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd2\xc01\x00Su\xa0d
[0xb2a800:0] - CLOSE @24 [@29 [:amqp:session:invalid-field]]
ERROR amqp:session:invalid-field sequencing error, expected delivery-id 1524,
got 1525
It is of course possible that I am doing something wrong in the broker code,
but I can't think what would cause something like this (since I can't
influence the delivery ids directly). It only seems to
[jira] [Comment Edited] (PROTON-157) invalid delivery-id sent(?)
[
https://issues.apache.org/jira/browse/PROTON-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13508786#comment-13508786
]
Gordon Sim edited comment on PROTON-157 at 12/3/12 3:05 PM:
I believe I now understand how this comes about. The delivery buffer is filled
up with outgoing transfers. However, as credit is added by the peer, more
deliveries can be queued up in the tpwork queue. Then a disposition comes in
for a portion of the previously sent messages. This results in the broker
settling those transfers which causes those deliveries to be added back onto
the tpwork queue, behind the deliveries yet to be sent. Another delivery may
now be added on to the tp work queue. If the pwork queue is then processed, it
goes through the first batch of unset deliveries, but there is still no space
in the delivery bufer, so these are left as is. It then processes the batch of
settled messages, cleans up the delivery buffer and removes them from tpwork.
Now finally it gets to the next unsent delivery, added after these. Since the
buffer has now been cleaned, this gets assigned the next delivery id. However
there are transfers ahead of it in the queue that have *not* yet had a delivery
state assigned. The next time tp work is processed, these will get delivery
state assigned with the delivery id out of sync.
A suggested fix (that works for my case and passes tests) is to detect when we
have removed deliveries from tp work, and start processing from the head. This
may not be optimal in all cases of course, but it is a simple change:
{noformat}
Index: proton-c/src/engine/engine.c
===
--- proton-c/src/engine/engine.c(revision 1416552)
+++ proton-c/src/engine/engine.c(working copy)
@@ -2219,7 +2219,11 @@
pn_clear_tpwork(delivery);
}
- delivery = delivery-tpwork_next;
+ if (delivery-tpwork) {
+delivery = delivery-tpwork_next;
+ } else {
+delivery = conn-tpwork_head;
+ }
}
}
{noformat}
was (Author: gsim):
I believe I now understand how this comes about. The delivery buffer is
filled up with outgoing transfers. However, as credit is added by the peer,
more deliveries can be queued up in the tpwork queue. Then a disposition comes
in for a portion of the previously sent messages. This results in the broker
settling those transfers which causes those deliveries to be added back onto
the tpwork queue, behind the deliveries yet to be sent. Another delivery may
now be added on to the tp work queue. If the pwork queue is then processed, it
goes through the first batch of unset deliveries, but there is still no space
in the delivery bufer, so these are left as is. It then processes the batch of
settled messages, cleans up the delivery buffer and removes them from tpwork.
Now finally it gets to the next unsent delivery, added after these. Since the
buffer has now been cleaned, this gets assigned the next delivery id. However
there are transfers ahead of it in the queue that have *not* yet had a delivery
state assigned. The next time tp work is processed, these will get delivery
state assigned with the delivery id out of sync.
A suggested fix (that works for my case and passes tests) is to detect when we
have removed deliveries from tp work, and start processing from the head. This
may not be optimal in all cases of course, but it is a simple change:
{noformat}
Index: proton-c/src/engine/engine.c
===
--- proton-c/src/engine/engine.c(revision 1416552)
+++ proton-c/src/engine/engine.c(working copy)
@@ -2219,7 +2219,11 @@
pn_clear_tpwork(delivery);
}
- delivery = delivery-tpwork_next;
+ if (delivery-tpwork) {
+delivery = delivery-tpwork_next;
+ } else {
+delivery = conn-tpwork_head;
+ }
}
}
{noformat}
invalid delivery-id sent(?)
---
Key: PROTON-157
URL: https://issues.apache.org/jira/browse/PROTON-157
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.2
Reporter: Gordon Sim
E.g. the following trace is from the client side (the peer was qpidd) and
appears to show a delivery-id being skipped:
[0xb2a800:1] - TRANSFER @20 [1, 1520, b\xf0\x05\x00\x00\x00\x00\x00\x00,
0, false, false] (177)
\x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xbd\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd1\xc5\xdf\x00Su\xa0d
[0xb2a800:1] - TRANSFER @20 [1,
[jira] [Updated] (PROTON-157) invalid delivery-id sent(?)
[ https://issues.apache.org/jira/browse/PROTON-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-157: -- Attachment: PROTON-157-improved+test.patch More efficient fix + test to show issue. invalid delivery-id sent(?) --- Key: PROTON-157 URL: https://issues.apache.org/jira/browse/PROTON-157 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.2 Reporter: Gordon Sim Attachments: PROTON-157-improved+test.patch E.g. the following trace is from the client side (the peer was qpidd) and appears to show a delivery-id being skipped: [0xb2a800:1] - TRANSFER @20 [1, 1520, b\xf0\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xbd\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd1\xc5\xdf\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1521, b\xf1\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xbe\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd1\xe8c\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1522, b\xf2\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xbf\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd2\x8b\x95\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1523, b\xf3\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xc0\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd2\xa8\xa5\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1525, b\xf4\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xc1\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd2\xc01\x00Su\xa0d [0xb2a800:0] - CLOSE @24 [@29 [:amqp:session:invalid-field]] ERROR amqp:session:invalid-field sequencing error, expected delivery-id 1524, got 1525 It is of course possible that I am doing something wrong in the broker code, but I can't think what would cause something like this (since I can't influence the delivery ids directly). It only seems to happen when there is a prefetch greater than 900. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-157) invalid delivery-id sent(?)
[ https://issues.apache.org/jira/browse/PROTON-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-157: -- Attachment: PROTON-157-improved+test-2.patch Improved test case that hits the exact symptom reported by this bug (previous test hits the same underlying structural issue but it manifests itself as a delivery ordering issue, with the delivery ids assigned correctly but the content/tag received out of order). invalid delivery-id sent(?) --- Key: PROTON-157 URL: https://issues.apache.org/jira/browse/PROTON-157 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.2 Reporter: Gordon Sim Fix For: 0.3 Attachments: PROTON-157-improved+test-2.patch E.g. the following trace is from the client side (the peer was qpidd) and appears to show a delivery-id being skipped: [0xb2a800:1] - TRANSFER @20 [1, 1520, b\xf0\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xbd\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd1\xc5\xdf\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1521, b\xf1\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xbe\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd1\xe8c\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1522, b\xf2\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xbf\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd2\x8b\x95\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1523, b\xf3\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xc0\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd2\xa8\xa5\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1525, b\xf4\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xc1\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd2\xc01\x00Su\xa0d [0xb2a800:0] - CLOSE @24 [@29 [:amqp:session:invalid-field]] ERROR amqp:session:invalid-field sequencing error, expected delivery-id 1524, got 1525 It is of course possible that I am doing something wrong in the broker code, but I can't think what would cause something like this (since I can't influence the delivery ids directly). It only seems to happen when there is a prefetch greater than 900. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-157) invalid delivery-id sent or out of order delivery
[ https://issues.apache.org/jira/browse/PROTON-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-157: -- Priority: Critical (was: Major) Fix Version/s: 0.3 Assignee: Gordon Sim Summary: invalid delivery-id sent or out of order delivery (was: invalid delivery-id sent(?)) invalid delivery-id sent or out of order delivery - Key: PROTON-157 URL: https://issues.apache.org/jira/browse/PROTON-157 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.2 Reporter: Gordon Sim Assignee: Gordon Sim Priority: Critical Fix For: 0.3 Attachments: PROTON-157-improved+test-2.patch E.g. the following trace is from the client side (the peer was qpidd) and appears to show a delivery-id being skipped: [0xb2a800:1] - TRANSFER @20 [1, 1520, b\xf0\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xbd\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd1\xc5\xdf\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1521, b\xf1\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xbe\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd1\xe8c\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1522, b\xf2\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xbf\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd2\x8b\x95\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1523, b\xf3\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xc0\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd2\xa8\xa5\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1525, b\xf4\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xc1\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd2\xc01\x00Su\xa0d [0xb2a800:0] - CLOSE @24 [@29 [:amqp:session:invalid-field]] ERROR amqp:session:invalid-field sequencing error, expected delivery-id 1524, got 1525 It is of course possible that I am doing something wrong in the broker code, but I can't think what would cause something like this (since I can't influence the delivery ids directly). It only seems to happen when there is a prefetch greater than 900. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-157) invalid delivery-id sent or out of order delivery
[ https://issues.apache.org/jira/browse/PROTON-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-157: -- Attachment: (was: PROTON-157-improved+test.patch) invalid delivery-id sent or out of order delivery - Key: PROTON-157 URL: https://issues.apache.org/jira/browse/PROTON-157 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.2 Reporter: Gordon Sim Assignee: Gordon Sim Priority: Critical Fix For: 0.3 Attachments: PROTON-157-improved+test-2.patch E.g. the following trace is from the client side (the peer was qpidd) and appears to show a delivery-id being skipped: [0xb2a800:1] - TRANSFER @20 [1, 1520, b\xf0\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xbd\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd1\xc5\xdf\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1521, b\xf1\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xbe\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd1\xe8c\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1522, b\xf2\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xbf\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd2\x8b\x95\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1523, b\xf3\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xc0\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd2\xa8\xa5\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1525, b\xf4\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xc1\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd2\xc01\x00Su\xa0d [0xb2a800:0] - CLOSE @24 [@29 [:amqp:session:invalid-field]] ERROR amqp:session:invalid-field sequencing error, expected delivery-id 1524, got 1525 It is of course possible that I am doing something wrong in the broker code, but I can't think what would cause something like this (since I can't influence the delivery ids directly). It only seems to happen when there is a prefetch greater than 900. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-157) invalid delivery-id sent or out of order delivery
[ https://issues.apache.org/jira/browse/PROTON-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-157: -- Attachment: PROTON-157-improved+test-3.patch Cleaned up test changes: no need to disable asserts, simply allow buffer size to be passed in so we can use something large than existing default. invalid delivery-id sent or out of order delivery - Key: PROTON-157 URL: https://issues.apache.org/jira/browse/PROTON-157 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.2 Reporter: Gordon Sim Assignee: Gordon Sim Priority: Critical Fix For: 0.3 Attachments: PROTON-157-improved+test-3.patch E.g. the following trace is from the client side (the peer was qpidd) and appears to show a delivery-id being skipped: [0xb2a800:1] - TRANSFER @20 [1, 1520, b\xf0\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xbd\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd1\xc5\xdf\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1521, b\xf1\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xbe\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd1\xe8c\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1522, b\xf2\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xbf\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd2\x8b\x95\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1523, b\xf3\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xc0\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd2\xa8\xa5\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1525, b\xf4\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xc1\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd2\xc01\x00Su\xa0d [0xb2a800:0] - CLOSE @24 [@29 [:amqp:session:invalid-field]] ERROR amqp:session:invalid-field sequencing error, expected delivery-id 1524, got 1525 It is of course possible that I am doing something wrong in the broker code, but I can't think what would cause something like this (since I can't influence the delivery ids directly). It only seems to happen when there is a prefetch greater than 900. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-157) invalid delivery-id sent or out of order delivery
[ https://issues.apache.org/jira/browse/PROTON-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-157: -- Attachment: (was: PROTON-157-improved+test-2.patch) invalid delivery-id sent or out of order delivery - Key: PROTON-157 URL: https://issues.apache.org/jira/browse/PROTON-157 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.2 Reporter: Gordon Sim Assignee: Gordon Sim Priority: Critical Fix For: 0.3 Attachments: PROTON-157-improved+test-3.patch E.g. the following trace is from the client side (the peer was qpidd) and appears to show a delivery-id being skipped: [0xb2a800:1] - TRANSFER @20 [1, 1520, b\xf0\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xbd\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd1\xc5\xdf\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1521, b\xf1\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xbe\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd1\xe8c\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1522, b\xf2\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xbf\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd2\x8b\x95\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1523, b\xf3\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xc0\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd2\xa8\xa5\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1525, b\xf4\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xc1\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd2\xc01\x00Su\xa0d [0xb2a800:0] - CLOSE @24 [@29 [:amqp:session:invalid-field]] ERROR amqp:session:invalid-field sequencing error, expected delivery-id 1524, got 1525 It is of course possible that I am doing something wrong in the broker code, but I can't think what would cause something like this (since I can't influence the delivery ids directly). It only seems to happen when there is a prefetch greater than 900. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PROTON-157) invalid delivery-id sent or out of order delivery when credit is close to or greater than session window
[ https://issues.apache.org/jira/browse/PROTON-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-157. --- Resolution: Fixed Fixed by r1416944. invalid delivery-id sent or out of order delivery when credit is close to or greater than session window Key: PROTON-157 URL: https://issues.apache.org/jira/browse/PROTON-157 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.2 Reporter: Gordon Sim Assignee: Gordon Sim Priority: Critical Fix For: 0.3 Attachments: PROTON-157-improved+test-3.patch E.g. the following trace is from the client side (the peer was qpidd) and appears to show a delivery-id being skipped: [0xb2a800:1] - TRANSFER @20 [1, 1520, b\xf0\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xbd\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd1\xc5\xdf\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1521, b\xf1\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xbe\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd1\xe8c\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1522, b\xf2\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xbf\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd2\x8b\x95\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1523, b\xf3\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xc0\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd2\xa8\xa5\x00Su\xa0d [0xb2a800:1] - TRANSFER @20 [1, 1525, b\xf4\x05\x00\x00\x00\x00\x00\x00, 0, false, false] (177) \x00Sp\xc0\x08\x05BP\x00@@R\x01\x00Ss\xd0\x00\x00\x00\x11\x00\x00\x00\x0d@\x00St\xd1\x00\x00\x00\x1a\x00\x00\x00\x04\xa1\x02snp\x00\x00\x16\xc1\xa1\x02ts\x80\x12\xc8\xfb\xe4\xdb\xd2\xc01\x00Su\xa0d [0xb2a800:0] - CLOSE @24 [@29 [:amqp:session:invalid-field]] ERROR amqp:session:invalid-field sequencing error, expected delivery-id 1524, got 1525 It is of course possible that I am doing something wrong in the broker code, but I can't think what would cause something like this (since I can't influence the delivery ids directly). It only seems to happen when there is a prefetch greater than 900. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-118) Add support for Messenger API
[ https://issues.apache.org/jira/browse/PROTON-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13528369#comment-13528369 ] Gordon Sim commented on PROTON-118: --- Committed driver changes. Updated Messenger API and Impl to support acknowledgements, new patch available for review at https://reviews.apache.org/r/7934/. Add support for Messenger API - Key: PROTON-118 URL: https://issues.apache.org/jira/browse/PROTON-118 Project: Qpid Proton Issue Type: New Feature Components: proton-j Affects Versions: 0.1, 0.2 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.3 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PROTON-118) Add support for Messenger API
[ https://issues.apache.org/jira/browse/PROTON-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-118. --- Resolution: Fixed Driver changes committed as http://svn.apache.org/viewvc?rev=1419837view=rev, initial implementation of messenger committed as http://svn.apache.org/viewvc?rev=1420140view=rev. Add support for Messenger API - Key: PROTON-118 URL: https://issues.apache.org/jira/browse/PROTON-118 Project: Qpid Proton Issue Type: New Feature Components: proton-j Affects Versions: 0.1, 0.2 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.3 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-183) intermittent hanging in messenger tests
Gordon Sim created PROTON-183: - Summary: intermittent hanging in messenger tests Key: PROTON-183 URL: https://issues.apache.org/jira/browse/PROTON-183 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.3 Reporter: Gordon Sim Assignee: Gordon Sim -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-205) java messenger does not set source and target correctly
Gordon Sim created PROTON-205: - Summary: java messenger does not set source and target correctly Key: PROTON-205 URL: https://issues.apache.org/jira/browse/PROTON-205 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.3 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.4 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-204) Handling of partial messages is broken in java messenger
Gordon Sim created PROTON-204: - Summary: Handling of partial messages is broken in java messenger Key: PROTON-204 URL: https://issues.apache.org/jira/browse/PROTON-204 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.3 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.4 I.e. where a read from the network reads part of a message but doesn't get all the data yet. This exhibits itself as a buffer underflow in MessengerImpl.get(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PROTON-204) Handling of partial messages is broken in java messenger
[ https://issues.apache.org/jira/browse/PROTON-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-204. --- Resolution: Fixed Fixed by http://svn.apache.org/viewvc?rev=1441176view=rev Handling of partial messages is broken in java messenger Key: PROTON-204 URL: https://issues.apache.org/jira/browse/PROTON-204 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.3 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.4 I.e. where a read from the network reads part of a message but doesn't get all the data yet. This exhibits itself as a buffer underflow in MessengerImpl.get(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-214) Test proton_tests.messenger.MessengerTest.testSendBogus failed
[ https://issues.apache.org/jira/browse/PROTON-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13570300#comment-13570300 ] Gordon Sim commented on PROTON-214: --- I actually think there is a race in the test logic, where the server can see the running flag has been turned off and stops before the client actually manages to establish a connection. In the testSendBogus() test the window for this race is somewhat larger than other tests as the test itself does not establish the connection to the server (that is done on teardown in response to sending the trigger message). That said, this does also raise the question of how failure to connect should be signalled. Should send() throw an exception in this case rather than timing out? Test proton_tests.messenger.MessengerTest.testSendBogus failed Key: PROTON-214 URL: https://issues.apache.org/jira/browse/PROTON-214 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.3 Environment: Run mvn test from a clean checkout - this uses proton-j by default. Reporter: Philip Harvey Assignee: Gordon Sim The system test proton_tests.messenger.MessengerTest.testSendBogus is failing on my computer when run against proton-j. I think I've seen this test pass occasionally so I suspect there's something unreliable about the test. Here is the output. proton_tests.messenger.MessengerTest.testSendBogus ..Feb 4, 2013 2:07:19 PM org.apache.qpid.proton.messenger.impl.MessengerImpl processActive SEVERE: Error processing connection java.io.IOException: Connection reset by peer at sun.nio.ch.FileDispatcher.read0(Native Method) at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:21) at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233) at sun.nio.ch.IOUtil.read(IOUtil.java:206) at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:236) at org.apache.qpid.proton.driver.impl.ConnectorImpl.read(ConnectorImpl.java:95) at org.apache.qpid.proton.driver.impl.ConnectorImpl.process(ConnectorImpl.java:80) at org.apache.qpid.proton.messenger.impl.MessengerImpl.processActive(MessengerImpl.java:426) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:525) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:506) at org.apache.qpid.proton.messenger.impl.MessengerImpl.send(MessengerImpl.java:205) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:186) at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:204) at org.python.core.PyObject.__call__(PyObject.java:387) at org.python.core.PyObject.__call__(PyObject.java:391) at org.python.core.PyMethod.__call__(PyMethod.java:109) at proton$py.send$201(__pyclasspath__/proton.py:997) at proton$py.call_function(__pyclasspath__/proton.py) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at org.python.core.PyFunction.__call__(PyFunction.java:317) at org.python.core.PyMethod.__call__(PyMethod.java:109) at proton_tests.messenger$py.teardown$4(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton_tests/messenger.py:52) at proton_tests.messenger$py.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton_tests/messenger.py) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at org.python.core.PyFunction.__call__(PyFunction.java:317) at org.python.core.PyMethod.__call__(PyMethod.java:109) at org.python.pycode._pyx1.run$36(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test:344) at org.python.pycode._pyx1.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:166) at org.python.core.PyFunction.__call__(PyFunction.java:338) at org.python.core.PyMethod.__call__(PyMethod.java:139) at
[jira] [Updated] (PROTON-214) Test proton_tests.messenger.MessengerTest.testSendBogus failed
[ https://issues.apache.org/jira/browse/PROTON-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-214: -- Priority: Minor (was: Major) Test proton_tests.messenger.MessengerTest.testSendBogus failed Key: PROTON-214 URL: https://issues.apache.org/jira/browse/PROTON-214 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.3 Environment: Run mvn test from a clean checkout - this uses proton-j by default. Reporter: Philip Harvey Assignee: Gordon Sim Priority: Minor The system test proton_tests.messenger.MessengerTest.testSendBogus is failing on my computer when run against proton-j. I think I've seen this test pass occasionally so I suspect there's something unreliable about the test. Here is the output. proton_tests.messenger.MessengerTest.testSendBogus ..Feb 4, 2013 2:07:19 PM org.apache.qpid.proton.messenger.impl.MessengerImpl processActive SEVERE: Error processing connection java.io.IOException: Connection reset by peer at sun.nio.ch.FileDispatcher.read0(Native Method) at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:21) at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233) at sun.nio.ch.IOUtil.read(IOUtil.java:206) at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:236) at org.apache.qpid.proton.driver.impl.ConnectorImpl.read(ConnectorImpl.java:95) at org.apache.qpid.proton.driver.impl.ConnectorImpl.process(ConnectorImpl.java:80) at org.apache.qpid.proton.messenger.impl.MessengerImpl.processActive(MessengerImpl.java:426) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:525) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:506) at org.apache.qpid.proton.messenger.impl.MessengerImpl.send(MessengerImpl.java:205) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:186) at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:204) at org.python.core.PyObject.__call__(PyObject.java:387) at org.python.core.PyObject.__call__(PyObject.java:391) at org.python.core.PyMethod.__call__(PyMethod.java:109) at proton$py.send$201(__pyclasspath__/proton.py:997) at proton$py.call_function(__pyclasspath__/proton.py) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at org.python.core.PyFunction.__call__(PyFunction.java:317) at org.python.core.PyMethod.__call__(PyMethod.java:109) at proton_tests.messenger$py.teardown$4(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton_tests/messenger.py:52) at proton_tests.messenger$py.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton_tests/messenger.py) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at org.python.core.PyFunction.__call__(PyFunction.java:317) at org.python.core.PyMethod.__call__(PyMethod.java:109) at org.python.pycode._pyx1.run$36(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test:344) at org.python.pycode._pyx1.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:166) at org.python.core.PyFunction.__call__(PyFunction.java:338) at org.python.core.PyMethod.__call__(PyMethod.java:139) at org.python.pycode._pyx1._run$55(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test:484) at org.python.pycode._pyx1.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at org.python.core.PyFunction.__call__(PyFunction.java:317) at org.python.core.PyMethod.__call__(PyMethod.java:109) at org.python.pycode._pyx1.run_test$41(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test:412) at
[jira] [Commented] (PROTON-214) Test proton_tests.messenger.MessengerTest.testSendBogus failed
[ https://issues.apache.org/jira/browse/PROTON-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13570301#comment-13570301 ] Gordon Sim commented on PROTON-214: --- Downgraded the severity as I think this is primarily an issue with the test rather than exposing underlying unreliability in the messenger implementation itself. Of course failing tests are never a good thing, so it should still be fixed. Test proton_tests.messenger.MessengerTest.testSendBogus failed Key: PROTON-214 URL: https://issues.apache.org/jira/browse/PROTON-214 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.3 Environment: Run mvn test from a clean checkout - this uses proton-j by default. Reporter: Philip Harvey Assignee: Gordon Sim Priority: Minor The system test proton_tests.messenger.MessengerTest.testSendBogus is failing on my computer when run against proton-j. I think I've seen this test pass occasionally so I suspect there's something unreliable about the test. Here is the output. proton_tests.messenger.MessengerTest.testSendBogus ..Feb 4, 2013 2:07:19 PM org.apache.qpid.proton.messenger.impl.MessengerImpl processActive SEVERE: Error processing connection java.io.IOException: Connection reset by peer at sun.nio.ch.FileDispatcher.read0(Native Method) at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:21) at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233) at sun.nio.ch.IOUtil.read(IOUtil.java:206) at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:236) at org.apache.qpid.proton.driver.impl.ConnectorImpl.read(ConnectorImpl.java:95) at org.apache.qpid.proton.driver.impl.ConnectorImpl.process(ConnectorImpl.java:80) at org.apache.qpid.proton.messenger.impl.MessengerImpl.processActive(MessengerImpl.java:426) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:525) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:506) at org.apache.qpid.proton.messenger.impl.MessengerImpl.send(MessengerImpl.java:205) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:186) at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:204) at org.python.core.PyObject.__call__(PyObject.java:387) at org.python.core.PyObject.__call__(PyObject.java:391) at org.python.core.PyMethod.__call__(PyMethod.java:109) at proton$py.send$201(__pyclasspath__/proton.py:997) at proton$py.call_function(__pyclasspath__/proton.py) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at org.python.core.PyFunction.__call__(PyFunction.java:317) at org.python.core.PyMethod.__call__(PyMethod.java:109) at proton_tests.messenger$py.teardown$4(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton_tests/messenger.py:52) at proton_tests.messenger$py.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton_tests/messenger.py) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at org.python.core.PyFunction.__call__(PyFunction.java:317) at org.python.core.PyMethod.__call__(PyMethod.java:109) at org.python.pycode._pyx1.run$36(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test:344) at org.python.pycode._pyx1.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:166) at org.python.core.PyFunction.__call__(PyFunction.java:338) at org.python.core.PyMethod.__call__(PyMethod.java:139) at org.python.pycode._pyx1._run$55(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test:484) at org.python.pycode._pyx1.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at
[jira] [Resolved] (PROTON-66) Driver implementation for proton-j
[ https://issues.apache.org/jira/browse/PROTON-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-66. -- Resolution: Fixed A driver API and implementation now exists (original committed by Rajith, modified since then by myself and others). ANy changes or defects within that can be tracked by new JIRAs. Driver implementation for proton-j -- Key: PROTON-66 URL: https://issues.apache.org/jira/browse/PROTON-66 Project: Qpid Proton Issue Type: New Feature Reporter: Rajith Attapattu Assignee: Gordon Sim Fix For: 0.4 Provide an implementation for the Driver API. This consists of 3 interfaces. Connector, Listener and Driver. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-277) dynamic flag on source/target is not handled correctly
Gordon Sim created PROTON-277: - Summary: dynamic flag on source/target is not handled correctly Key: PROTON-277 URL: https://issues.apache.org/jira/browse/PROTON-277 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4 Reporter: Gordon Sim Priority: Critical When the dynamic flag is set, the address must not be set. However if the address is not set then the engine always returns UNSPECIFIED for the terminus type. This means you can't correctly implement dynamic with the engine. (I currently have to put one char in the address to workaround the problem). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-277) dynamic flag on source/target is not handled correctly
[ https://issues.apache.org/jira/browse/PROTON-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-277: -- Attachment: PROTON-277-test.patch PROTON-277-suggested-fix.patch Attached possible fix and test to demonstrate the issue. dynamic flag on source/target is not handled correctly -- Key: PROTON-277 URL: https://issues.apache.org/jira/browse/PROTON-277 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4 Reporter: Gordon Sim Priority: Critical Attachments: PROTON-277-suggested-fix.patch, PROTON-277-test.patch When the dynamic flag is set, the address must not be set. However if the address is not set then the engine always returns UNSPECIFIED for the terminus type. This means you can't correctly implement dynamic with the engine. (I currently have to put one char in the address to workaround the problem). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-277) dynamic flag on source/target is not handled correctly
[ https://issues.apache.org/jira/browse/PROTON-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-277: -- Fix Version/s: 0.5 dynamic flag on source/target is not handled correctly -- Key: PROTON-277 URL: https://issues.apache.org/jira/browse/PROTON-277 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4 Reporter: Gordon Sim Priority: Critical Fix For: 0.5 Attachments: PROTON-277-suggested-fix.patch, PROTON-277-test.patch When the dynamic flag is set, the address must not be set. However if the address is not set then the engine always returns UNSPECIFIED for the terminus type. This means you can't correctly implement dynamic with the engine. (I currently have to put one char in the address to workaround the problem). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (PROTON-319) there is no way to get or set the settlement mode for receiver or sender
[ https://issues.apache.org/jira/browse/PROTON-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim closed PROTON-319. - Resolution: Fixed there is no way to get or set the settlement mode for receiver or sender Key: PROTON-319 URL: https://issues.apache.org/jira/browse/PROTON-319 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4 Reporter: Gordon Sim Priority: Critical Fix For: 0.5 This affects compliance of brokers using the library and also prevents receivers in clients from expressing their preference for unreliable transfer (i.e. sender pre-settles) or indeed other modes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-81) Expose send/receive settle modes
[ https://issues.apache.org/jira/browse/PROTON-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13667800#comment-13667800 ] Gordon Sim commented on PROTON-81: -- This affects compliance of brokers using the library and prevents exposing control over reliability level through client APIs built on top of this library. Expose send/receive settle modes Key: PROTON-81 URL: https://issues.apache.org/jira/browse/PROTON-81 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Hiram Chirino Priority: Critical Fix For: 0.5 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-319) there is no way to get or set the settlement mode for receiver or sender
Gordon Sim created PROTON-319: - Summary: there is no way to get or set the settlement mode for receiver or sender Key: PROTON-319 URL: https://issues.apache.org/jira/browse/PROTON-319 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4 Reporter: Gordon Sim Priority: Critical Fix For: 0.5 This affects compliance of brokers using the library and also prevents receivers in clients from expressing their preference for unreliable transfer (i.e. sender pre-settles) or indeed other modes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-319) there is no way to get or set the settlement mode for receiver or sender
[ https://issues.apache.org/jira/browse/PROTON-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13667794#comment-13667794 ] Gordon Sim commented on PROTON-319: --- The java engine by contrast _does_ have an obvious means to get and set this information. there is no way to get or set the settlement mode for receiver or sender Key: PROTON-319 URL: https://issues.apache.org/jira/browse/PROTON-319 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4 Reporter: Gordon Sim Priority: Critical Fix For: 0.5 This affects compliance of brokers using the library and also prevents receivers in clients from expressing their preference for unreliable transfer (i.e. sender pre-settles) or indeed other modes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-61) Need a means of specifying and reading connection capabilities properties
[ https://issues.apache.org/jira/browse/PROTON-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-61: - Fix Version/s: (was: 0.4) 0.5 Need a means of specifying and reading connection capabilities properties --- Key: PROTON-61 URL: https://issues.apache.org/jira/browse/PROTON-61 Project: Qpid Proton Issue Type: Bug Components: proton-c, proton-j Reporter: Gordon Sim Assignee: Rafael H. Schloming Labels: api Fix For: 0.5 The properties are very useful for providing details about a client connection for management purposes (pid, process name, client library version etc). The capabilities are needed to turn on optional functionality (e.g. filters). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-335) Need a means of specifying and reading link properties
Gordon Sim created PROTON-335: - Summary: Need a means of specifying and reading link properties Key: PROTON-335 URL: https://issues.apache.org/jira/browse/PROTON-335 Project: Qpid Proton Issue Type: Bug Components: proton-c, proton-j Affects Versions: 0.4 Reporter: Gordon Sim Priority: Minor There are some cases where it may be beneficial to use link properties (since link capabilities do not allow for key-value pairs, they can't easily convey a desired configurable value and the properties on a terminus refer to the dynamically created node not the link or the terminus itself). (I've set this to minor since major feels a little strong, but I do think its important ultimately for the engine to expose all the extension points from the protocol.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PROTON-340) AMQP to JMS transformer fails to properly map AMQP specific property types like UnsignedInteger
[ https://issues.apache.org/jira/browse/PROTON-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-340. --- Resolution: Fixed AMQP to JMS transformer fails to properly map AMQP specific property types like UnsignedInteger --- Key: PROTON-340 URL: https://issues.apache.org/jira/browse/PROTON-340 Project: Qpid Proton Issue Type: Bug Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 0.5 Attachments: PROTON-340.patch Causes errors like: Caused by: javax.jms.MessageFormatException: Only objectified primitive objects, String, Map and List types are allowed but was: 1 type: class org.apache.qpid.proton.amqp.UnsignedInteger at org.apache.activemq.command.ActiveMQMessage.checkValidObject(ActiveMQMessage.java:521) at org.apache.activemq.command.ActiveMQMessage.setObjectProperty(ActiveMQMessage.java:487) at org.apache.activemq.command.ActiveMQMessage.setObjectProperty(ActiveMQMessage.java:475) at org.apache.activemq.command.ActiveMQBytesMessage.setObjectProperty(ActiveMQBytesMessage.java:896) at org.apache.qpid.proton.jms.InboundTransformer.setProperty(InboundTransformer.java:265) at org.apache.qpid.proton.jms.InboundTransformer.populateMessage(InboundTransformer.java:168) at org.apache.qpid.proton.jms.AMQPNativeInboundTransformer.transform(AMQPNativeInboundTransformer.java:37) at org.apache.activemq.transport.amqp.AmqpProtocolConverter$ProducerContext.onMessage(AmqpProtocolConverter.java:508) at org.apache.activemq.transport.amqp.AmqpProtocolConverter$BaseProducerContext.onDelivery(AmqpProtocolConverter.java:489) at org.apache.activemq.transport.amqp.AmqpProtocolConverter.onFrame(AmqpProtocolConverter.java:262) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-342) installing into custom location doesn't work nicely (and is not properly documented)
Gordon Sim created PROTON-342: - Summary: installing into custom location doesn't work nicely (and is not properly documented) Key: PROTON-342 URL: https://issues.apache.org/jira/browse/PROTON-342 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4 Reporter: Gordon Sim Assignee: Darryl L. Pierce Fix For: 0.5 The README suggests setting -DCMAKE_INSTALL_PREFIX when running cmake, it does not mention setting DESTDIR when invoking make install. If you don't set the DESTDIR on make install it will honour the CMAKE_INSTALL_PREFIX for some parts of the installation (e.g. header files, native libraries, pkg-config file etc) but the python bindings (and I assume other bindings) will still install in the standard location which will fail if you are not running as root. However if you set DESTDIR then this alters the location of the headers, libraries and pkg-config , which now install into $DESTDIR/$CMAKE_INSTALL_PREFIX and the pkg-config file no longer has the correct include or library paths in it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-342) installing into custom location doesn't work nicely (and is not properly documented)
[ https://issues.apache.org/jira/browse/PROTON-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13692100#comment-13692100 ] Gordon Sim commented on PROTON-342: --- The problem can be mitigated by specifying -DBUILD_PYTHON=OFF -DBUILD_RUBY=OFF etc when running cmake. This prevents the building and installation of the bindings (and thus avoids having to use DESTDIR at all) installing into custom location doesn't work nicely (and is not properly documented) Key: PROTON-342 URL: https://issues.apache.org/jira/browse/PROTON-342 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4 Reporter: Gordon Sim Assignee: Darryl L. Pierce Fix For: 0.5 The README suggests setting -DCMAKE_INSTALL_PREFIX when running cmake, it does not mention setting DESTDIR when invoking make install. If you don't set the DESTDIR on make install it will honour the CMAKE_INSTALL_PREFIX for some parts of the installation (e.g. header files, native libraries, pkg-config file etc) but the python bindings (and I assume other bindings) will still install in the standard location which will fail if you are not running as root. However if you set DESTDIR then this alters the location of the headers, libraries and pkg-config , which now install into $DESTDIR/$CMAKE_INSTALL_PREFIX and the pkg-config file no longer has the correct include or library paths in it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (PROTON-342) installing into custom location doesn't work nicely (and is not properly documented)
[ https://issues.apache.org/jira/browse/PROTON-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reopened PROTON-342: --- Improving the README is great, but it doesn't resolve the issue (which is that it is not possible to install both c headers/libs and bindings to a non-standard location and still rely on pkg-config for depenency configuration. installing into custom location doesn't work nicely (and is not properly documented) Key: PROTON-342 URL: https://issues.apache.org/jira/browse/PROTON-342 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4 Reporter: Gordon Sim Assignee: Darryl L. Pierce Fix For: 0.5 The README suggests setting -DCMAKE_INSTALL_PREFIX when running cmake, it does not mention setting DESTDIR when invoking make install. If you don't set the DESTDIR on make install it will honour the CMAKE_INSTALL_PREFIX for some parts of the installation (e.g. header files, native libraries, pkg-config file etc) but the python bindings (and I assume other bindings) will still install in the standard location which will fail if you are not running as root. However if you set DESTDIR then this alters the location of the headers, libraries and pkg-config , which now install into $DESTDIR/$CMAKE_INSTALL_PREFIX and the pkg-config file no longer has the correct include or library paths in it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-97) RELEASED disposition not processed by engine
[ https://issues.apache.org/jira/browse/PROTON-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13692813#comment-13692813 ] Gordon Sim commented on PROTON-97: -- The extent is small, as far as I can see only the type being undefined and the various tests on it changing to methods. The consequence is simply that at this stage I can't yet convert trunk for the components I am working on to use the trunk from proton as it is not released (and if I modified it to work with the latest API, it would not compile against the last released API). Once 0.5 comes out I'll switch over of course. I could also add macros to handle both versions in my code, but it doesn't seem worth it at this point. The comment was mainly just to point out the change in case it had been forgotten. RELEASED disposition not processed by engine Key: PROTON-97 URL: https://issues.apache.org/jira/browse/PROTON-97 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.1 Reporter: Ted Ross Assignee: Rafael H. Schloming Fix For: 0.5 When the proton-c engine receives a disposition with a RELEASED state, it prints a non-log message default 38 in the default clause of a switch (see pn_do_disposition) in engine.c. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-158) detach with invalid handle causes segfault
[ https://issues.apache.org/jira/browse/PROTON-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-158: -- Priority: Minor (was: Major) detach with invalid handle causes segfault -- Key: PROTON-158 URL: https://issues.apache.org/jira/browse/PROTON-158 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.2 Reporter: Gordon Sim Assignee: Ken Giusti Priority: Minor Fix For: 0.5 I.e. a detach where the handle was not previously used in an attach -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-116) Proton sends explicit disposition for pre-settled messages
[
https://issues.apache.org/jira/browse/PROTON-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13700234#comment-13700234
]
Gordon Sim commented on PROTON-116:
---
This change appears to cause a delivery to continually be returned from the
work queue until it is settled. I.e. where the messages arrive with the settled
falg false, and the application code then handles the readbale message and
advances (but doesn't yet settle or update the message), then the delivery
keeps getting returned (in updated state).
The following change 'fixes' it for me to behave as before, can't say for sure
if this is right or not:
{noformat}
Index: proton-c/src/engine/engine.c
===
--- proton-c/src/engine/engine.c(revision 1499474)
+++ proton-c/src/engine/engine.c(working copy)
@@ -1813,8 +1813,10 @@
// XXX: need to fill in remote state: delivery-remote.state = ...;
delivery-remote.settled = settled;
-delivery-updated = true;
-pn_work_update(transport-connection, delivery);
+if (settled) {
+ delivery-updated = true;
+ pn_work_update(transport-connection, delivery);
+}
}
pn_buffer_append(delivery-bytes, disp-payload, disp-size);
{noformat}
I can raise a separate JIRA if desired.
Proton sends explicit disposition for pre-settled messages
--
Key: PROTON-116
URL: https://issues.apache.org/jira/browse/PROTON-116
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.2
Reporter: Ted Ross
Assignee: Rafael H. Schloming
Priority: Minor
Fix For: 0.5
When proton sends pre-settled messages (the settled flag is set in the
transfer), it follows up with an explicit disposition frame for the message.
I believe this disposition update is spurious and unneeded, though I haven't
found a definitive statement one way or the other in the protocol
specification.
[0x1efaaa0:1] - FLOW @19 [0, 1024, 0, 1024, 1, 0, 8, null, false]
[0x1efaaa0:1] - TRANSFER @20 [1, 0, b\x00\x00\x00\x00\x00\x00\x00\x00, 0,
true, false] (184)
[0x1efaaa0:1] - TRANSFER @20 [1, 1, b\x01\x00\x00\x00\x00\x00\x00\x00, 0,
true, false] (184)
[0x1efaaa0:1] - TRANSFER @20 [1, 2, b\x02\x00\x00\x00\x00\x00\x00\x00, 0,
true, false] (184)
[0x1efaaa0:1] - DISPOSITION @21 [false, 0, 2, true, null]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-427) settle does not match accept/reject for ruby
Gordon Sim created PROTON-427: - Summary: settle does not match accept/reject for ruby Key: PROTON-427 URL: https://issues.apache.org/jira/browse/PROTON-427 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.5 Reporter: Gordon Sim In 0.4 the ruby versions of accept()/reject() and settle() all took a tracker and flags (and both were required) In 0.5 this was changed for accept/reject. Only one argument could be passed, the tracker, and it was optional. However settle remains the same as before which seems inconsistent. (Of course changing it now would break the API again between 0.5 and the next release). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (PROTON-425) [Messenger] messenger can only browse qpidd's queues
[
https://issues.apache.org/jira/browse/PROTON-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim closed PROTON-425.
-
Resolution: Not A Problem
This is an issue with qpidd, not proton. As the messages are not explicitly
accepted, even though settled, they are never being dequeued.
See https://issues.apache.org/jira/browse/QPID-5170
[Messenger] messenger can only browse qpidd's queues
Key: PROTON-425
URL: https://issues.apache.org/jira/browse/PROTON-425
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.5
Reporter: Ken Giusti
Fix For: 0.6
I have a simple queue on the qpidd broker, which holds one message:
$ qpid-stat -q
Queues
queue dur autoDel excl msg msgIn msgOut
bytes bytesIn bytesOut cons bind
KENQ 1 1
0 65 650 0 1
Attempting to consume from that queue using the messenger recv example:
$ ./examples/messenger/py/recv.py amqp://127.0.0.1:5672/KENQ
None (no subject) {u'spout-id': u'7fe1a726-b1bc-40e6-b91f-51cf34136f33:0'}
None
recv.py gets the message, but it is never removed from qpidd's queue:
$ qpid-stat -q
Queues
queue dur autoDel excl msg msgIn msgOut
bytes bytesIn bytesOut cons bind
KENQ 1 1
0 65 650 0 1
Seems like messenger can only browse qpidd's queues.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-342) installing into custom location doesn't work nicely (and is not properly documented)
[ https://issues.apache.org/jira/browse/PROTON-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13782831#comment-13782831 ] Gordon Sim commented on PROTON-342: --- Also, if 'DESTDIR isn't meant to update the paths' in the pkg conf file, that should probably be noted in the README. installing into custom location doesn't work nicely (and is not properly documented) Key: PROTON-342 URL: https://issues.apache.org/jira/browse/PROTON-342 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4 Reporter: Gordon Sim Assignee: Darryl L. Pierce The README suggests setting -DCMAKE_INSTALL_PREFIX when running cmake, it does not mention setting DESTDIR when invoking make install. If you don't set the DESTDIR on make install it will honour the CMAKE_INSTALL_PREFIX for some parts of the installation (e.g. header files, native libraries, pkg-config file etc) but the python bindings (and I assume other bindings) will still install in the standard location which will fail if you are not running as root. However if you set DESTDIR then this alters the location of the headers, libraries and pkg-config , which now install into $DESTDIR/$CMAKE_INSTALL_PREFIX and the pkg-config file no longer has the correct include or library paths in it. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (PROTON-342) installing into custom location doesn't work nicely (and is not properly documented)
[ https://issues.apache.org/jira/browse/PROTON-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13783031#comment-13783031 ] Gordon Sim commented on PROTON-342: --- The use of DESTDIR does not affect the contents of libqpid-proton.pc. is not as clear as it might be. I think something like The paths in libqpid-proton.pc are not adjusted for DESTDIR, so if that is specified they will not be accurate. installing into custom location doesn't work nicely (and is not properly documented) Key: PROTON-342 URL: https://issues.apache.org/jira/browse/PROTON-342 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4 Reporter: Gordon Sim Assignee: Darryl L. Pierce The README suggests setting -DCMAKE_INSTALL_PREFIX when running cmake, it does not mention setting DESTDIR when invoking make install. If you don't set the DESTDIR on make install it will honour the CMAKE_INSTALL_PREFIX for some parts of the installation (e.g. header files, native libraries, pkg-config file etc) but the python bindings (and I assume other bindings) will still install in the standard location which will fail if you are not running as root. However if you set DESTDIR then this alters the location of the headers, libraries and pkg-config , which now install into $DESTDIR/$CMAKE_INSTALL_PREFIX and the pkg-config file no longer has the correct include or library paths in it. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (PROTON-432) seg fault when handling error
Gordon Sim created PROTON-432:
-
Summary: seg fault when handling error
Key: PROTON-432
URL: https://issues.apache.org/jira/browse/PROTON-432
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.5
Reporter: Gordon Sim
Priority: Blocker
Fix For: 0.6
{noformat}
$ ./proton-c/examples/messenger/c/send -a
amqp://gordon:gordon@localhost/my-queue
Connected to localhost:5672
- SASL
[0x18b8320:0] - @sasl-init(65) [mechanism=:PLAIN,
initial-response=b\x00gordon\x00gordon]
- SASL
[0x18b8320:0] - @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN, :AMQPLAIN]]
[0x18b8320:0] - @sasl-outcome(68) [code=0]
- AMQP
[0x18b08d0:0] - @open(16)
[container-id=8133b412-5ca8-4359-be9f-e236b87d3528, hostname=localhost]
[0x18b08d0:0] - @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=1]
[0x18b08d0:0] - @attach(18) [name=sender-xxx, handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=my-queue,
durable=0, timeout=0, dynamic=false], target=@target(41) [address=my-queue,
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
- AMQP
[0x18b08d0:0] - @open(16) [container-id=rabbit@GRS-T520,
idle-time-out=60, properties={:copyright=Copyright (C) 2007-2013 VMware,
Inc., :information=Licensed under the MPL. See http://www.rabbitmq.com/;,
:platform=Erlang/OTP, :product=RabbitMQ, :version=3.1.3}]
[0x18b08d0:0] - @open(16) [container-id=rabbit@GRS-T520,
idle-time-out=60, properties={:copyright=Copyright (C) 2007-2013 VMware,
Inc., :information=Licensed under the MPL. See http://www.rabbitmq.com/;,
:platform=Erlang/OTP, :product=RabbitMQ, :version=3.1.3}]
Segmentation fault (core dumped)
{noformat}
#0 0x7f799b10c0e0 in pn_data_rewind () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#1 0x7f799b11555f in pn_do_close () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#2 0x7f799b111554 in pn_dispatch_frame () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#3 0x7f799b1116e7 in pn_dispatcher_input () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#4 0x7f799b1169ee in pn_input_read_amqp () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#5 0x7f799b114855 in transport_consume () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#6 0x7f799b1185e2 in pn_transport_process () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#7 0x7f799b1204fb in pn_connector_process () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#8 0x7f799b11e420 in pn_messenger_tsync () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#9 0x004010f3 in main ()
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (PROTON-435) seg fault when handling error
Gordon Sim created PROTON-435:
-
Summary: seg fault when handling error
Key: PROTON-435
URL: https://issues.apache.org/jira/browse/PROTON-435
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.5
Reporter: Gordon Sim
Priority: Blocker
Fix For: 0.6
{noformat}
$ ./proton-c/examples/messenger/c/send -a
amqp://gordon:gordon@localhost/my-queue
Connected to localhost:5672
- SASL
[0x18b8320:0] - @sasl-init(65) [mechanism=:PLAIN,
initial-response=b\x00gordon\x00gordon]
- SASL
[0x18b8320:0] - @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN, :AMQPLAIN]]
[0x18b8320:0] - @sasl-outcome(68) [code=0]
- AMQP
[0x18b08d0:0] - @open(16)
[container-id=8133b412-5ca8-4359-be9f-e236b87d3528, hostname=localhost]
[0x18b08d0:0] - @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=1]
[0x18b08d0:0] - @attach(18) [name=sender-xxx, handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=my-queue,
durable=0, timeout=0, dynamic=false], target=@target(41) [address=my-queue,
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
- AMQP
[0x18b08d0:0] - @open(16) [container-id=rabbit@GRS-T520,
idle-time-out=60, properties={:copyright=Copyright (C) 2007-2013 VMware,
Inc., :information=Licensed under the MPL. See http://www.rabbitmq.com/;,
:platform=Erlang/OTP, :product=RabbitMQ, :version=3.1.3}]
[0x18b08d0:0] - @open(16) [container-id=rabbit@GRS-T520,
idle-time-out=60, properties={:copyright=Copyright (C) 2007-2013 VMware,
Inc., :information=Licensed under the MPL. See http://www.rabbitmq.com/;,
:platform=Erlang/OTP, :product=RabbitMQ, :version=3.1.3}]
Segmentation fault (core dumped)
{noformat}
#0 0x7f799b10c0e0 in pn_data_rewind () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#1 0x7f799b11555f in pn_do_close () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#2 0x7f799b111554 in pn_dispatch_frame () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#3 0x7f799b1116e7 in pn_dispatcher_input () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#4 0x7f799b1169ee in pn_input_read_amqp () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#5 0x7f799b114855 in transport_consume () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#6 0x7f799b1185e2 in pn_transport_process () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#7 0x7f799b1204fb in pn_connector_process () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#8 0x7f799b11e420 in pn_messenger_tsync () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#9 0x004010f3 in main ()
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Closed] (PROTON-433) seg fault when handling error
[
https://issues.apache.org/jira/browse/PROTON-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim closed PROTON-433.
-
Resolution: Fixed
Created extra JIRAs in error.
seg fault when handling error
-
Key: PROTON-433
URL: https://issues.apache.org/jira/browse/PROTON-433
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.5
Reporter: Gordon Sim
Priority: Blocker
Fix For: 0.6
{noformat}
$ ./proton-c/examples/messenger/c/send -a
amqp://gordon:gordon@localhost/my-queue
Connected to localhost:5672
- SASL
[0x18b8320:0] - @sasl-init(65) [mechanism=:PLAIN,
initial-response=b\x00gordon\x00gordon]
- SASL
[0x18b8320:0] - @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN, :AMQPLAIN]]
[0x18b8320:0] - @sasl-outcome(68) [code=0]
- AMQP
[0x18b08d0:0] - @open(16)
[container-id=8133b412-5ca8-4359-be9f-e236b87d3528, hostname=localhost]
[0x18b08d0:0] - @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=1]
[0x18b08d0:0] - @attach(18) [name=sender-xxx, handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=my-queue,
durable=0, timeout=0, dynamic=false], target=@target(41) [address=my-queue,
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
- AMQP
[0x18b08d0:0] - @open(16) [container-id=rabbit@GRS-T520,
idle-time-out=60, properties={:copyright=Copyright (C) 2007-2013 VMware,
Inc., :information=Licensed under the MPL. See http://www.rabbitmq.com/;,
:platform=Erlang/OTP, :product=RabbitMQ, :version=3.1.3}]
[0x18b08d0:0] - @open(16) [container-id=rabbit@GRS-T520,
idle-time-out=60, properties={:copyright=Copyright (C) 2007-2013 VMware,
Inc., :information=Licensed under the MPL. See http://www.rabbitmq.com/;,
:platform=Erlang/OTP, :product=RabbitMQ, :version=3.1.3}]
Segmentation fault (core dumped)
{noformat}
#0 0x7f799b10c0e0 in pn_data_rewind () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#1 0x7f799b11555f in pn_do_close () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#2 0x7f799b111554 in pn_dispatch_frame () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#3 0x7f799b1116e7 in pn_dispatcher_input () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#4 0x7f799b1169ee in pn_input_read_amqp () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#5 0x7f799b114855 in transport_consume () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#6 0x7f799b1185e2 in pn_transport_process () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#7 0x7f799b1204fb in pn_connector_process () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#8 0x7f799b11e420 in pn_messenger_tsync () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#9 0x004010f3 in main ()
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Reopened] (PROTON-433) seg fault when handling error
[
https://issues.apache.org/jira/browse/PROTON-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim reopened PROTON-433:
---
seg fault when handling error
-
Key: PROTON-433
URL: https://issues.apache.org/jira/browse/PROTON-433
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.5
Reporter: Gordon Sim
Priority: Blocker
Fix For: 0.6
{noformat}
$ ./proton-c/examples/messenger/c/send -a
amqp://gordon:gordon@localhost/my-queue
Connected to localhost:5672
- SASL
[0x18b8320:0] - @sasl-init(65) [mechanism=:PLAIN,
initial-response=b\x00gordon\x00gordon]
- SASL
[0x18b8320:0] - @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN, :AMQPLAIN]]
[0x18b8320:0] - @sasl-outcome(68) [code=0]
- AMQP
[0x18b08d0:0] - @open(16)
[container-id=8133b412-5ca8-4359-be9f-e236b87d3528, hostname=localhost]
[0x18b08d0:0] - @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=1]
[0x18b08d0:0] - @attach(18) [name=sender-xxx, handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=my-queue,
durable=0, timeout=0, dynamic=false], target=@target(41) [address=my-queue,
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
- AMQP
[0x18b08d0:0] - @open(16) [container-id=rabbit@GRS-T520,
idle-time-out=60, properties={:copyright=Copyright (C) 2007-2013 VMware,
Inc., :information=Licensed under the MPL. See http://www.rabbitmq.com/;,
:platform=Erlang/OTP, :product=RabbitMQ, :version=3.1.3}]
[0x18b08d0:0] - @open(16) [container-id=rabbit@GRS-T520,
idle-time-out=60, properties={:copyright=Copyright (C) 2007-2013 VMware,
Inc., :information=Licensed under the MPL. See http://www.rabbitmq.com/;,
:platform=Erlang/OTP, :product=RabbitMQ, :version=3.1.3}]
Segmentation fault (core dumped)
{noformat}
#0 0x7f799b10c0e0 in pn_data_rewind () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#1 0x7f799b11555f in pn_do_close () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#2 0x7f799b111554 in pn_dispatch_frame () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#3 0x7f799b1116e7 in pn_dispatcher_input () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#4 0x7f799b1169ee in pn_input_read_amqp () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#5 0x7f799b114855 in transport_consume () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#6 0x7f799b1185e2 in pn_transport_process () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#7 0x7f799b1204fb in pn_connector_process () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#8 0x7f799b11e420 in pn_messenger_tsync () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#9 0x004010f3 in main ()
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Closed] (PROTON-434) seg fault when handling error
[
https://issues.apache.org/jira/browse/PROTON-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim closed PROTON-434.
-
Resolution: Duplicate
Created extra JIRAs in error.
seg fault when handling error
-
Key: PROTON-434
URL: https://issues.apache.org/jira/browse/PROTON-434
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.5
Reporter: Gordon Sim
Priority: Blocker
Fix For: 0.6
{noformat}
$ ./proton-c/examples/messenger/c/send -a
amqp://gordon:gordon@localhost/my-queue
Connected to localhost:5672
- SASL
[0x18b8320:0] - @sasl-init(65) [mechanism=:PLAIN,
initial-response=b\x00gordon\x00gordon]
- SASL
[0x18b8320:0] - @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN, :AMQPLAIN]]
[0x18b8320:0] - @sasl-outcome(68) [code=0]
- AMQP
[0x18b08d0:0] - @open(16)
[container-id=8133b412-5ca8-4359-be9f-e236b87d3528, hostname=localhost]
[0x18b08d0:0] - @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=1]
[0x18b08d0:0] - @attach(18) [name=sender-xxx, handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=my-queue,
durable=0, timeout=0, dynamic=false], target=@target(41) [address=my-queue,
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
- AMQP
[0x18b08d0:0] - @open(16) [container-id=rabbit@GRS-T520,
idle-time-out=60, properties={:copyright=Copyright (C) 2007-2013 VMware,
Inc., :information=Licensed under the MPL. See http://www.rabbitmq.com/;,
:platform=Erlang/OTP, :product=RabbitMQ, :version=3.1.3}]
[0x18b08d0:0] - @open(16) [container-id=rabbit@GRS-T520,
idle-time-out=60, properties={:copyright=Copyright (C) 2007-2013 VMware,
Inc., :information=Licensed under the MPL. See http://www.rabbitmq.com/;,
:platform=Erlang/OTP, :product=RabbitMQ, :version=3.1.3}]
Segmentation fault (core dumped)
{noformat}
#0 0x7f799b10c0e0 in pn_data_rewind () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#1 0x7f799b11555f in pn_do_close () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#2 0x7f799b111554 in pn_dispatch_frame () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#3 0x7f799b1116e7 in pn_dispatcher_input () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#4 0x7f799b1169ee in pn_input_read_amqp () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#5 0x7f799b114855 in transport_consume () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#6 0x7f799b1185e2 in pn_transport_process () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#7 0x7f799b1204fb in pn_connector_process () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#8 0x7f799b11e420 in pn_messenger_tsync () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#9 0x004010f3 in main ()
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Closed] (PROTON-433) seg fault when handling error
[
https://issues.apache.org/jira/browse/PROTON-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim closed PROTON-433.
-
Resolution: Duplicate
Created extra JIRAs in error.
seg fault when handling error
-
Key: PROTON-433
URL: https://issues.apache.org/jira/browse/PROTON-433
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.5
Reporter: Gordon Sim
Priority: Blocker
Fix For: 0.6
{noformat}
$ ./proton-c/examples/messenger/c/send -a
amqp://gordon:gordon@localhost/my-queue
Connected to localhost:5672
- SASL
[0x18b8320:0] - @sasl-init(65) [mechanism=:PLAIN,
initial-response=b\x00gordon\x00gordon]
- SASL
[0x18b8320:0] - @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN, :AMQPLAIN]]
[0x18b8320:0] - @sasl-outcome(68) [code=0]
- AMQP
[0x18b08d0:0] - @open(16)
[container-id=8133b412-5ca8-4359-be9f-e236b87d3528, hostname=localhost]
[0x18b08d0:0] - @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=1]
[0x18b08d0:0] - @attach(18) [name=sender-xxx, handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=my-queue,
durable=0, timeout=0, dynamic=false], target=@target(41) [address=my-queue,
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
- AMQP
[0x18b08d0:0] - @open(16) [container-id=rabbit@GRS-T520,
idle-time-out=60, properties={:copyright=Copyright (C) 2007-2013 VMware,
Inc., :information=Licensed under the MPL. See http://www.rabbitmq.com/;,
:platform=Erlang/OTP, :product=RabbitMQ, :version=3.1.3}]
[0x18b08d0:0] - @open(16) [container-id=rabbit@GRS-T520,
idle-time-out=60, properties={:copyright=Copyright (C) 2007-2013 VMware,
Inc., :information=Licensed under the MPL. See http://www.rabbitmq.com/;,
:platform=Erlang/OTP, :product=RabbitMQ, :version=3.1.3}]
Segmentation fault (core dumped)
{noformat}
#0 0x7f799b10c0e0 in pn_data_rewind () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#1 0x7f799b11555f in pn_do_close () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#2 0x7f799b111554 in pn_dispatch_frame () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#3 0x7f799b1116e7 in pn_dispatcher_input () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#4 0x7f799b1169ee in pn_input_read_amqp () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#5 0x7f799b114855 in transport_consume () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#6 0x7f799b1185e2 in pn_transport_process () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#7 0x7f799b1204fb in pn_connector_process () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#8 0x7f799b11e420 in pn_messenger_tsync () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#9 0x004010f3 in main ()
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Assigned] (PROTON-432) seg fault when handling error
[
https://issues.apache.org/jira/browse/PROTON-432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim reassigned PROTON-432:
-
Assignee: Rafael H. Schloming
The issue appears to be a over long error description, and no bounds checking
when assigning that to the condition's buffer. Possible fix posted here:
https://reviews.apache.org/r/14442/
seg fault when handling error
-
Key: PROTON-432
URL: https://issues.apache.org/jira/browse/PROTON-432
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.5
Reporter: Gordon Sim
Assignee: Rafael H. Schloming
Priority: Blocker
Fix For: 0.6
{noformat}
$ ./proton-c/examples/messenger/c/send -a
amqp://gordon:gordon@localhost/my-queue
Connected to localhost:5672
- SASL
[0x18b8320:0] - @sasl-init(65) [mechanism=:PLAIN,
initial-response=b\x00gordon\x00gordon]
- SASL
[0x18b8320:0] - @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN, :AMQPLAIN]]
[0x18b8320:0] - @sasl-outcome(68) [code=0]
- AMQP
[0x18b08d0:0] - @open(16)
[container-id=8133b412-5ca8-4359-be9f-e236b87d3528, hostname=localhost]
[0x18b08d0:0] - @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=1]
[0x18b08d0:0] - @attach(18) [name=sender-xxx, handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=my-queue,
durable=0, timeout=0, dynamic=false], target=@target(41) [address=my-queue,
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
- AMQP
[0x18b08d0:0] - @open(16) [container-id=rabbit@GRS-T520,
idle-time-out=60, properties={:copyright=Copyright (C) 2007-2013 VMware,
Inc., :information=Licensed under the MPL. See http://www.rabbitmq.com/;,
:platform=Erlang/OTP, :product=RabbitMQ, :version=3.1.3}]
[0x18b08d0:0] - @open(16) [container-id=rabbit@GRS-T520,
idle-time-out=60, properties={:copyright=Copyright (C) 2007-2013 VMware,
Inc., :information=Licensed under the MPL. See http://www.rabbitmq.com/;,
:platform=Erlang/OTP, :product=RabbitMQ, :version=3.1.3}]
Segmentation fault (core dumped)
{noformat}
#0 0x7f799b10c0e0 in pn_data_rewind () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#1 0x7f799b11555f in pn_do_close () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#2 0x7f799b111554 in pn_dispatch_frame () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#3 0x7f799b1116e7 in pn_dispatcher_input () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#4 0x7f799b1169ee in pn_input_read_amqp () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#5 0x7f799b114855 in transport_consume () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#6 0x7f799b1185e2 in pn_transport_process () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#7 0x7f799b1204fb in pn_connector_process () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#8 0x7f799b11e420 in pn_messenger_tsync () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#9 0x004010f3 in main ()
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (PROTON-426) [Messenger] messenger has no ability to dynamically create queues/topics on qpidd
[
https://issues.apache.org/jira/browse/PROTON-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13802184#comment-13802184
]
Gordon Sim commented on PROTON-426:
---
Just for completeness, the 1.0 protocol does define a mechanism by which the
broker can be asked to create a queue (the 'dynamic' flag on source/target),
however in that case the queue is named by the broker and not the application.
This works well for 'temporary queues' e.g. as used in request-response
patterns. However I share the view that the more general solution of on-demand
creation is indeed better handled through broker configuration and have raised
https://issues.apache.org/jira/browse/QPID-5251 to add that to qpidd.
[Messenger] messenger has no ability to dynamically create queues/topics on
qpidd
-
Key: PROTON-426
URL: https://issues.apache.org/jira/browse/PROTON-426
Project: Qpid Proton
Issue Type: New Feature
Components: proton-c
Affects Versions: 0.5
Reporter: Ken Giusti
Fix For: 0.6
The current QPID client addressing syntax provides a way to create and delete
queue/topic resource on the qpidd broker in band. For example:
$ QPID_LOAD_MODULE=amqpc.so ./spout --connection-options {protocol:amqp1.0}
TestQ;{create:always,node:{type:queue}}
$ qpid-stat -q
Queues
queue dur autoDel excl msg msgIn msgOut bytes
bytesIn bytesOut cons bind
...
TestQ1 1
0 65 650 0 1
This capability is not available when using the Messenger API.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (PROTON-483) detach with closed=false (or unspecified) not handled
Gordon Sim created PROTON-483:
-
Summary: detach with closed=false (or unspecified) not handled
Key: PROTON-483
URL: https://issues.apache.org/jira/browse/PROTON-483
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.6
Reporter: Gordon Sim
If an application using proton-c receives a detach frame where the closed field
is not set to true, then the state of the link doesn't change and the
application is essentially unaware that anything has been received (and
consequently can't respond).
From transport.c (line 882):
{noformat}
if (closed)
{
PN_SET_REMOTE(link-endpoint.state, PN_REMOTE_CLOSED);
} else {
// TODO: implement
}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Closed] (PROTON-426) [Messenger] messenger has no ability to dynamically create queues/topics on qpidd
[
https://issues.apache.org/jira/browse/PROTON-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim closed PROTON-426.
-
Resolution: Duplicate
[Messenger] messenger has no ability to dynamically create queues/topics on
qpidd
-
Key: PROTON-426
URL: https://issues.apache.org/jira/browse/PROTON-426
Project: Qpid Proton
Issue Type: New Feature
Components: proton-c
Affects Versions: 0.5
Reporter: Ken Giusti
Fix For: 0.6
The current QPID client addressing syntax provides a way to create and delete
queue/topic resource on the qpidd broker in band. For example:
$ QPID_LOAD_MODULE=amqpc.so ./spout --connection-options {protocol:amqp1.0}
TestQ;{create:always,node:{type:queue}}
$ qpid-stat -q
Queues
queue dur autoDel excl msg msgIn msgOut bytes
bytesIn bytesOut cons bind
...
TestQ1 1
0 65 650 0 1
This capability is not available when using the Messenger API.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (PROTON-506) Queue names with '@' symbol cause incorrect hostname lookup
[
https://issues.apache.org/jira/browse/PROTON-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim updated PROTON-506:
--
Fix Version/s: 0.7
Queue names with '@' symbol cause incorrect hostname lookup
---
Key: PROTON-506
URL: https://issues.apache.org/jira/browse/PROTON-506
Project: Qpid Proton
Issue Type: Bug
Components: python-binding
Affects Versions: 0.6
Reporter: Brian Bouterse
Assignee: Rafael H. Schloming
Fix For: 0.7
I have need to create a queue with the following name (no quotes):
cel...@dhcp129-138.rdu.redhat.com.celery.pidbox
I try to subscribe using the string
'amqp://localhost/cel...@dhcp129-138.rdu.redhat.com.celery.pidbox'
I receive the following error:
Unrecoverable error: MessengerException('[-2]: unable to connect to
amqp://localhost/cel...@dhcp129-138.rdu.redhat.com.celery.pidbox:
getaddrinfo(dhcp129-138.rdu.redhat.com.celery.pidbox, 5672): Name or service
not known',)
I expected the hostname to be 'localhost', but instead the hostname being
used is 'dhcp129-138.rdu.redhat.com.celery.pidbox' which is not an actual
hostname.
Better interpretation of the string would resolve this.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Assigned] (PROTON-506) Queue names with '@' symbol cause incorrect hostname lookup
[
https://issues.apache.org/jira/browse/PROTON-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim reassigned PROTON-506:
-
Assignee: Rafael H. Schloming
Queue names with '@' symbol cause incorrect hostname lookup
---
Key: PROTON-506
URL: https://issues.apache.org/jira/browse/PROTON-506
Project: Qpid Proton
Issue Type: Bug
Components: python-binding
Affects Versions: 0.6
Reporter: Brian Bouterse
Assignee: Rafael H. Schloming
Fix For: 0.7
I have need to create a queue with the following name (no quotes):
cel...@dhcp129-138.rdu.redhat.com.celery.pidbox
I try to subscribe using the string
'amqp://localhost/cel...@dhcp129-138.rdu.redhat.com.celery.pidbox'
I receive the following error:
Unrecoverable error: MessengerException('[-2]: unable to connect to
amqp://localhost/cel...@dhcp129-138.rdu.redhat.com.celery.pidbox:
getaddrinfo(dhcp129-138.rdu.redhat.com.celery.pidbox, 5672): Name or service
not known',)
I expected the hostname to be 'localhost', but instead the hostname being
used is 'dhcp129-138.rdu.redhat.com.celery.pidbox' which is not an actual
hostname.
Better interpretation of the string would resolve this.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (PROTON-608) seg fault if attach is sent before open and begin
Gordon Sim created PROTON-608: - Summary: seg fault if attach is sent before open and begin Key: PROTON-608 URL: https://issues.apache.org/jira/browse/PROTON-608 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Gordon Sim Fix For: 0.8 While working with the proton-j engine, I inadvertently opened a link before opening the corresponding session and connection. This resulted in the attach being sent without the open or begin. Though clearly user error, it did show up an issue with the proton-c engine, where this sequence causes a segfault. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (PROTON-608) seg fault if attach is sent before open and begin
[ https://issues.apache.org/jira/browse/PROTON-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14030641#comment-14030641 ] Gordon Sim commented on PROTON-608: --- 2014-06-11 17:12:11 [Protocol] trace [qpid.127.0.0.1:5672-127.0.0.1:42526]: - AMQP 2014-06-11 17:12:11 [Protocol] trace [qpid.127.0.0.1:5672-127.0.0.1:42526]: 65535 - @attach(18) [name=amq.topic_1, handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0, target=@target(41) [address=amq.topic], incomplete-unsettled=false, initial-delivery-count=0] Segmentation fault (core dumped) Core was generated by `./src/qpidd --auth no --load-module ./src/amqp.so --log-enable info+ --log-enab'. Program terminated with signal 11, Segmentation fault. #0 0x7f4a9be383b4 in pn_find_link () from /home/gordon/qpid-releases/proton/0.7/installation/lib64/libqpid-proton.so.2 Missing separate debuginfos, use: debuginfo-install boost-program-options-1.48.0-14.fc17.x86_64 cyrus-sasl-lib-2.1.23-31.fc17.x86_64 glibc-2.15-59.fc17.x86_64 keyutils-libs-1.5.5-2.fc17.x86_64 krb5-libs-1.10.2-12.fc17.x86_64 libcom_err-1.42.3-3.fc17.x86_64 libselinux-2.1.10-3.fc17.x86_64 libuuid-2.21.2-4.fc17.x86_64 nspr-4.9.6-1.fc17.x86_64 nss-3.14.3-2.fc17.x86_64 nss-softokn-freebl-3.14.3-1.fc17.x86_64 nss-util-3.14.3-1.fc17.x86_64 openssl-1.0.0k-1.fc17.x86_64 zlib-1.2.5-7.fc17.x86_64 (gdb) bt #0 0x7f4a9be383b4 in pn_find_link () from /home/gordon/qpid-releases/proton/0.7/installation/lib64/libqpid-proton.so.2 #1 0x7f4a9be385ce in pn_do_attach () from /home/gordon/qpid-releases/proton/0.7/installation/lib64/libqpid-proton.so.2 #2 0x7f4a9be32c34 in pn_dispatch_frame () from /home/gordon/qpid-releases/proton/0.7/installation/lib64/libqpid-proton.so.2 #3 0x7f4a9be32dc7 in pn_dispatcher_input () from /home/gordon/qpid-releases/proton/0.7/installation/lib64/libqpid-proton.so.2 #4 0x7f4a9be3a5ee in pn_input_read_amqp () from /home/gordon/qpid-releases/proton/0.7/installation/lib64/libqpid-proton.so.2 #5 0x7f4a9be39b65 in transport_consume () from /home/gordon/qpid-releases/proton/0.7/installation/lib64/libqpid-proton.so.2 #6 0x7f4a9be3aaf2 in pn_transport_process () from /home/gordon/qpid-releases/proton/0.7/installation/lib64/libqpid-proton.so.2 #7 0x7f4a9be3ac48 in pn_transport_input () from /home/gordon/qpid-releases/proton/0.7/installation/lib64/libqpid-proton.so.2 #8 0x7f4a9c103516 in qpid::broker::amqp::Connection::decode(char const*, unsigned long) () from seg fault if attach is sent before open and begin - Key: PROTON-608 URL: https://issues.apache.org/jira/browse/PROTON-608 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Gordon Sim Fix For: 0.8 While working with the proton-j engine, I inadvertently opened a link before opening the corresponding session and connection. This resulted in the attach being sent without the open or begin. Though clearly user error, it did show up an issue with the proton-c engine, where this sequence causes a segfault. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (PROTON-641) pn_connection_t leaked when links not closed
Gordon Sim created PROTON-641: - Summary: pn_connection_t leaked when links not closed Key: PROTON-641 URL: https://issues.apache.org/jira/browse/PROTON-641 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Gordon Sim Assignee: Rafael H. Schloming Fix For: 0.8 If the application doesn't call pn_link_close(), but calls on_session_close(), pn_connection_close(), then pn_transport_free() and pn_connection_free(), the pn_connection_t object appear to be leaked. Will attach reproducer. See also QPID-5951. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PROTON-641) pn_connection_t leaked when links not closed
[ https://issues.apache.org/jira/browse/PROTON-641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-641: -- Attachment: proton_leak.cpp Running attached test under valgrind gives: ==17718== ==17718== HEAP SUMMARY: ==17718== in use at exit: 29,660 bytes in 612 blocks ==17718== total heap usage: 819 allocs, 207 frees, 156,612 bytes allocated ==17718== ==17718== 14,830 (256 direct, 14,574 indirect) bytes in 1 blocks are definitely lost in loss record 611 of 612 ==17718==at 0x4A0881C: malloc (vg_replace_malloc.c:270) ==17718==by 0x4C24B5D: pn_new2 (in /home/gordon/projects/proton/installation/lib64/libqpid-proton.so.2.0.0) ==17718==by 0x4C24B37: pn_new (in /home/gordon/projects/proton/installation/lib64/libqpid-proton.so.2.0.0) ==17718==by 0x4C355A6: pn_connection (in /home/gordon/projects/proton/installation/lib64/libqpid-proton.so.2.0.0) ==17718==by 0x40139C: Client::Client() (proton_leak.cpp:35) ==17718==by 0x40128B: main (proton_leak.cpp:152) ==17718== ==17718== 14,830 (256 direct, 14,574 indirect) bytes in 1 blocks are definitely lost in loss record 612 of 612 ==17718==at 0x4A0881C: malloc (vg_replace_malloc.c:270) ==17718==by 0x4C24B5D: pn_new2 (in /home/gordon/projects/proton/installation/lib64/libqpid-proton.so.2.0.0) ==17718==by 0x4C24B37: pn_new (in /home/gordon/projects/proton/installation/lib64/libqpid-proton.so.2.0.0) ==17718==by 0x4C355A6: pn_connection (in /home/gordon/projects/proton/installation/lib64/libqpid-proton.so.2.0.0) ==17718==by 0x401546: Server::Server() (proton_leak.cpp:84) ==17718==by 0x401297: main (proton_leak.cpp:153) ==17718== ==17718== LEAK SUMMARY: ==17718==definitely lost: 512 bytes in 2 blocks ==17718==indirectly lost: 29,148 bytes in 610 blocks ==17718== possibly lost: 0 bytes in 0 blocks ==17718==still reachable: 0 bytes in 0 blocks ==17718== suppressed: 0 bytes in 0 blocks ==17718== ==17718== For counts of detected and suppressed errors, rerun with: -v ==17718== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 2 from 2) pn_connection_t leaked when links not closed Key: PROTON-641 URL: https://issues.apache.org/jira/browse/PROTON-641 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Gordon Sim Assignee: Rafael H. Schloming Fix For: 0.8 Attachments: proton_leak.cpp If the application doesn't call pn_link_close(), but calls on_session_close(), pn_connection_close(), then pn_transport_free() and pn_connection_free(), the pn_connection_t object appear to be leaked. Will attach reproducer. See also QPID-5951. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (PROTON-641) pn_connection_t leaked when links not closed
[ https://issues.apache.org/jira/browse/PROTON-641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14098471#comment-14098471 ] Gordon Sim commented on PROTON-641: --- See also https://issues.apache.org/jira/browse/PROTON-648 which has a patch. pn_connection_t leaked when links not closed Key: PROTON-641 URL: https://issues.apache.org/jira/browse/PROTON-641 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Gordon Sim Assignee: Rafael H. Schloming Fix For: 0.8 Attachments: proton_leak.cpp If the application doesn't call pn_link_close(), but calls on_session_close(), pn_connection_close(), then pn_transport_free() and pn_connection_free(), the pn_connection_t object appear to be leaked. Will attach reproducer. See also QPID-5951. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (PROTON-656) pn_transport_close_{head, tail} no longer return an error code on framing error.
[
https://issues.apache.org/jira/browse/PROTON-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14119939#comment-14119939
]
Gordon Sim commented on PROTON-656:
---
sounds good to me
pn_transport_close_{head, tail} no longer return an error code on framing
error.
Key: PROTON-656
URL: https://issues.apache.org/jira/browse/PROTON-656
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.8
Reporter: Ken Giusti
Priority: Blocker
Fix For: 0.8
In the 0.7 release, the transport interfaces pn_transport_close_head() and
pn_transport_close_tail() used to return an error should the close occur at
an 'unexpected' point on the protocol (framing error, for example).
The behavior no longer occurs on trunk. This results in an API change.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PROTON-659) if protons internal buffer gets large, performance can suffer
Gordon Sim created PROTON-659: - Summary: if protons internal buffer gets large, performance can suffer Key: PROTON-659 URL: https://issues.apache.org/jira/browse/PROTON-659 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.7 Reporter: Gordon Sim Priority: Minor In doing some performance investigations using qpid::messaging over 1.0, in particular as message size got larger, I saw much lower throughput and lots of cpu used. From callgrind it looked like this was from shuffliing up the buffer in pn_dispatcher_output. Because of the threading in qpid::messaging, it was possible for the application to generate too much output using the top-half of the engine API before the IO was done for the bottom half. Fixing that in qpid:messaging improved performance. There may perhaps be something that proton could do to make users more aware of this (e.g. a log message if the buffer exceeds a certain size? or just documentation?) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-688) pn_transport_unbind() doesn't reset all relevant trasnport state
[ https://issues.apache.org/jira/browse/PROTON-688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14139410#comment-14139410 ] Gordon Sim commented on PROTON-688: --- Patch proposed: https://reviews.apache.org/r/25790/ pn_transport_unbind() doesn't reset all relevant trasnport state Key: PROTON-688 URL: https://issues.apache.org/jira/browse/PROTON-688 Project: Qpid Proton Issue Type: Bug Components: proton-c, python-binding Affects Versions: 0.8 Reporter: Gordon Sim Unbinding a transport on connection failure, then trying to rebind a new transport to the original connection option doesn't work as expected as not all relevant state is reset. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-688) pn_transport_unbind() doesn't reset all relevant trasnport state
[ https://issues.apache.org/jira/browse/PROTON-688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-688. --- Resolution: Fixed Fix Version/s: 0.8 pn_transport_unbind() doesn't reset all relevant trasnport state Key: PROTON-688 URL: https://issues.apache.org/jira/browse/PROTON-688 Project: Qpid Proton Issue Type: Bug Components: proton-c, python-binding Affects Versions: 0.8 Reporter: Gordon Sim Fix For: 0.8 Unbinding a transport on connection failure, then trying to rebind a new transport to the original connection option doesn't work as expected as not all relevant state is reset. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-723) Proton-c does not support attaching to the transaction coordinator
Gordon Sim created PROTON-723: - Summary: Proton-c does not support attaching to the transaction coordinator Key: PROTON-723 URL: https://issues.apache.org/jira/browse/PROTON-723 Project: Qpid Proton Issue Type: Bug Components: proton-c, proton-j Reporter: Hiram Chirino Assignee: Rafael H. Schloming Got at: Caused by: java.lang.ClassCastException: org.apache.qpid.proton.type.transaction.Coordinator cannot be cast to org.apache.qpid.proton.type.messaging.Target at org.apache.qpid.proton.engine.impl.TransportImpl.handleAttach(TransportImpl.java:977) at org.apache.qpid.proton.engine.impl.TransportImpl.handleAttach(TransportImpl.java:59) at org.apache.qpid.proton.type.transport.Attach.invoke(Attach.java:389) at org.apache.qpid.proton.engine.impl.TransportImpl.input(TransportImpl.java:1090) at org.apache.qpid.proton.engine.impl.FrameParser.input(FrameParser.java:409) at org.apache.qpid.proton.engine.impl.TransportImpl.input(TransportImpl.java:156) at org.apache.activemq.transport.amqp.AmqpProtocolConverter.onAMQPData(AmqpProtocolConverter.java:120) ... 5 more and I think the frame being processed was the following (hex): 00 00 00 6a 02 00 00 01 00 53 12 c0 5d 0a a1 11 74 78 6e 43 6f 6e 74 72 6f 6c 6c 65 72 4c 69 6e 6b 43 42 50 00 50 00 00 53 28 c0 01 00 00 53 30 c0 35 01 e0 32 02 a3 17 61 6d 71 70 3a 6c 6f 63 61 6c 2d 74 72 61 6e 73 61 63 74 69 6f 6e 73 17 61 6d 71 70 3a 6d 75 6c 74 69 2d 74 78 6e 73 2d 70 65 72 2d 73 73 6e 40 40 43 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-723) Proton-c does not support attaching to the transaction coordinator
[ https://issues.apache.org/jira/browse/PROTON-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-723: -- Component/s: (was: proton-j) Description: Though there is a terminus type PN_COORDINATOR defined, setting that seems to have no effect and indeed the code in pn_process_link_setup always sets the source to the descriptor code for amqp:source:list. was: Got at: Caused by: java.lang.ClassCastException: org.apache.qpid.proton.type.transaction.Coordinator cannot be cast to org.apache.qpid.proton.type.messaging.Target at org.apache.qpid.proton.engine.impl.TransportImpl.handleAttach(TransportImpl.java:977) at org.apache.qpid.proton.engine.impl.TransportImpl.handleAttach(TransportImpl.java:59) at org.apache.qpid.proton.type.transport.Attach.invoke(Attach.java:389) at org.apache.qpid.proton.engine.impl.TransportImpl.input(TransportImpl.java:1090) at org.apache.qpid.proton.engine.impl.FrameParser.input(FrameParser.java:409) at org.apache.qpid.proton.engine.impl.TransportImpl.input(TransportImpl.java:156) at org.apache.activemq.transport.amqp.AmqpProtocolConverter.onAMQPData(AmqpProtocolConverter.java:120) ... 5 more and I think the frame being processed was the following (hex): 00 00 00 6a 02 00 00 01 00 53 12 c0 5d 0a a1 11 74 78 6e 43 6f 6e 74 72 6f 6c 6c 65 72 4c 69 6e 6b 43 42 50 00 50 00 00 53 28 c0 01 00 00 53 30 c0 35 01 e0 32 02 a3 17 61 6d 71 70 3a 6c 6f 63 61 6c 2d 74 72 61 6e 73 61 63 74 69 6f 6e 73 17 61 6d 71 70 3a 6d 75 6c 74 69 2d 74 78 6e 73 2d 70 65 72 2d 73 73 6e 40 40 43 Priority: Critical (was: Major) Affects Version/s: 0.8 Proton-c does not support attaching to the transaction coordinator -- Key: PROTON-723 URL: https://issues.apache.org/jira/browse/PROTON-723 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Hiram Chirino Assignee: Rafael H. Schloming Priority: Critical Labels: api, transactions Though there is a terminus type PN_COORDINATOR defined, setting that seems to have no effect and indeed the code in pn_process_link_setup always sets the source to the descriptor code for amqp:source:list. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-62) Proton(-j) does not support attaching to the transaction coordinator
[ https://issues.apache.org/jira/browse/PROTON-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-62: - Component/s: (was: proton-c) This is still an issue for proton-c, so I have cloned a new JIRA for tracking that: PROTON-723 Proton(-j) does not support attaching to the transaction coordinator Key: PROTON-62 URL: https://issues.apache.org/jira/browse/PROTON-62 Project: Qpid Proton Issue Type: Bug Components: proton-j Reporter: Hiram Chirino Assignee: Rafael H. Schloming Labels: api, transactions Got at: Caused by: java.lang.ClassCastException: org.apache.qpid.proton.type.transaction.Coordinator cannot be cast to org.apache.qpid.proton.type.messaging.Target at org.apache.qpid.proton.engine.impl.TransportImpl.handleAttach(TransportImpl.java:977) at org.apache.qpid.proton.engine.impl.TransportImpl.handleAttach(TransportImpl.java:59) at org.apache.qpid.proton.type.transport.Attach.invoke(Attach.java:389) at org.apache.qpid.proton.engine.impl.TransportImpl.input(TransportImpl.java:1090) at org.apache.qpid.proton.engine.impl.FrameParser.input(FrameParser.java:409) at org.apache.qpid.proton.engine.impl.TransportImpl.input(TransportImpl.java:156) at org.apache.activemq.transport.amqp.AmqpProtocolConverter.onAMQPData(AmqpProtocolConverter.java:120) ... 5 more and I think the frame being processed was the following (hex): 00 00 00 6a 02 00 00 01 00 53 12 c0 5d 0a a1 11 74 78 6e 43 6f 6e 74 72 6f 6c 6c 65 72 4c 69 6e 6b 43 42 50 00 50 00 00 53 28 c0 01 00 00 53 30 c0 35 01 e0 32 02 a3 17 61 6d 71 70 3a 6c 6f 63 61 6c 2d 74 72 61 6e 73 61 63 74 69 6f 6e 73 17 61 6d 71 70 3a 6d 75 6c 74 69 2d 74 78 6e 73 2d 70 65 72 2d 73 73 6e 40 40 43 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-723) Proton-c does not support attaching to the transaction coordinator
[ https://issues.apache.org/jira/browse/PROTON-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-723: -- Attachment: quick_and_dirty.patch Quick and dirty fix to allow the attach made by the controller to the coordinator to be sent out correctly. (Doesn't address the issue of an incoming link to the coordinator on the coordinator processes side). Proton-c does not support attaching to the transaction coordinator -- Key: PROTON-723 URL: https://issues.apache.org/jira/browse/PROTON-723 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Hiram Chirino Assignee: Rafael H. Schloming Priority: Critical Labels: api, transactions Attachments: quick_and_dirty.patch Though there is a terminus type PN_COORDINATOR defined, setting that seems to have no effect and indeed the code in pn_process_link_setup always sets the source to the descriptor code for amqp:source:list. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-667) add support for transactional state and enable outgoing transfer frames to specify a txn-id
[ https://issues.apache.org/jira/browse/PROTON-667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reassigned PROTON-667: - Assignee: Rafael H. Schloming add support for transactional state and enable outgoing transfer frames to specify a txn-id --- Key: PROTON-667 URL: https://issues.apache.org/jira/browse/PROTON-667 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Robbie Gemmell Assignee: Rafael H. Schloming Similar to PROTON-666 for proton-j, proton-c needs to be able to apply transactional state to outgoing transfer frames in order to allow publihsing messages transactionally. Support needs to be added for transactional state generally in order to allow this. Changes should include python binding updates to allow testing these changes and those for PROTON-666. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-667) add support for transactional state and enable outgoing transfer frames to specify a txn-id
[ https://issues.apache.org/jira/browse/PROTON-667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-667: -- Attachment: quick_and_dirty_again.patch Another quick and dirty fix in case it is of use to anyone. add support for transactional state and enable outgoing transfer frames to specify a txn-id --- Key: PROTON-667 URL: https://issues.apache.org/jira/browse/PROTON-667 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Robbie Gemmell Assignee: Rafael H. Schloming Attachments: quick_and_dirty_again.patch Similar to PROTON-666 for proton-j, proton-c needs to be able to apply transactional state to outgoing transfer frames in order to allow publihsing messages transactionally. Support needs to be added for transactional state generally in order to allow this. Changes should include python binding updates to allow testing these changes and those for PROTON-666. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-730) Can't read transactional state set on incoming transfer
Gordon Sim created PROTON-730: - Summary: Can't read transactional state set on incoming transfer Key: PROTON-730 URL: https://issues.apache.org/jira/browse/PROTON-730 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Gordon Sim Assignee: Rafael H. Schloming -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-730) Can't read transactional state set on incoming transfer
[ https://issues.apache.org/jira/browse/PROTON-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14185228#comment-14185228 ] Gordon Sim commented on PROTON-730: --- This is the other side of PROTON-667 really, where that appears to mainly be focused on controlling outgoing transfers, this is about handling incoming transfers with transactional state set on them. Can't read transactional state set on incoming transfer --- Key: PROTON-730 URL: https://issues.apache.org/jira/browse/PROTON-730 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Gordon Sim Assignee: Rafael H. Schloming -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-723) Proton-c does not support attaching to the transaction coordinator
[ https://issues.apache.org/jira/browse/PROTON-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-723: -- Attachment: PROTON-723_part2_quick_and_dirty.patch This patch is for the other side of the wire, allowing the coordinator process itself to detect an incoming link for transaction control requests. Again, just a quick and dirty fix that works for me in my testing so far. Proton-c does not support attaching to the transaction coordinator -- Key: PROTON-723 URL: https://issues.apache.org/jira/browse/PROTON-723 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Hiram Chirino Assignee: Rafael H. Schloming Priority: Critical Labels: api, transactions Attachments: PROTON-723_part2_quick_and_dirty.patch, quick_and_dirty.patch Though there is a terminus type PN_COORDINATOR defined, setting that seems to have no effect and indeed the code in pn_process_link_setup always sets the source to the descriptor code for amqp:source:list. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-730) Can't read transactional state set on incoming transfer
[ https://issues.apache.org/jira/browse/PROTON-730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-730: -- Attachment: PROTON-730_quick_and_dirty.patch Quick and dirty fix. This follows the same approach already in place for dispositions, whereby the descriptor code is available via pn_delivery_remote_state(). However this approach does seem limited to cases (admittedly the most likely) where the descriptor is numeric. Assuming it is valid to send a symbolic descriptor for delivery states, proton-c wouldn't read them. Can't read transactional state set on incoming transfer --- Key: PROTON-730 URL: https://issues.apache.org/jira/browse/PROTON-730 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Gordon Sim Assignee: Rafael H. Schloming Attachments: PROTON-730_quick_and_dirty.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-730) Can't read transactional state set on incoming transfer
[ https://issues.apache.org/jira/browse/PROTON-730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-730: -- Priority: Critical (was: Major) Can't read transactional state set on incoming transfer --- Key: PROTON-730 URL: https://issues.apache.org/jira/browse/PROTON-730 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Gordon Sim Assignee: Rafael H. Schloming Priority: Critical Attachments: PROTON-730_quick_and_dirty.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-734) deliveries are not returned in order
Gordon Sim created PROTON-734: - Summary: deliveries are not returned in order Key: PROTON-734 URL: https://issues.apache.org/jira/browse/PROTON-734 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Gordon Sim Assignee: Rafael H. Schloming Priority: Critical If, on a single session, I send e.g. 3 messages on one link, followed by a message on another link, then on the receiving side I expect those to be returned in the order in which they are sent. Although proton-c on the receiving side receives them in the correct order as verified by turning on tracing, the order in which the respective deliveries are returned by pn_work_head()/pn_work_next() is not correct. I get the first message, followed by the last message (i.e. the fourth), then the second and third. If I modify the test to send a fifth message to a third link, then on the receiving side the 5th message is received 3rd. I.e. it appears that the work queue involves taking the first delivery off each link, rather than having a session level ordering(?) In the case where a transaction discharge message is sent *after* some transactional publications, this results in the discharge being processed before all the publications the transaction is supposed to cover. (The sender can of course wait for all the transactional publications to be accepted before it sends the commit, but on a single session this isn't necessary and as far as I can see not required by the spec.) In any case, preserving order is likely to be important in other cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-754) no way to set or get properties on a flow
Gordon Sim created PROTON-754: - Summary: no way to set or get properties on a flow Key: PROTON-754 URL: https://issues.apache.org/jira/browse/PROTON-754 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Gordon Sim The transaction section of the spec states that this properties map is used to specify a txn-id for transaction acquisition. Even if this is not supported, resources are supposed to detect that being set and detach with not-implemented. So at present it is not possible to be compliant with the spec when using proton-c. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-773) No way to determine that link is detahced (but not closed)
Gordon Sim created PROTON-773: - Summary: No way to determine that link is detahced (but not closed) Key: PROTON-773 URL: https://issues.apache.org/jira/browse/PROTON-773 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Gordon Sim At least I can't see any obvious way. The endpoint state indicates when the link is closed, but the detached flag used internally to record that the link has been detached, is not exposed in anyway. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-812) LinkException needs an attribute that indicates the reason for the exception.
[ https://issues.apache.org/jira/browse/PROTON-812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-812. --- Resolution: Fixed Fix Version/s: 0.9 There is now a LinkDetached subclass of LinkException, which has the 'condition' the peer set on the detach as a property. LinkException needs an attribute that indicates the reason for the exception. - Key: PROTON-812 URL: https://issues.apache.org/jira/browse/PROTON-812 Project: Qpid Proton Issue Type: Improvement Affects Versions: 0.8 Reporter: Jeff Ortel Assignee: Gordon Sim Fix For: 0.9 LinkException needs an attribute that indicates the reason for the exception so that the exception can be appropriately delt with. For example: A link exception caused when a node does not exist would be delt with differently than a link exception caused by an issue in the link chain involving dispatch router. Having constants for the error codes would be desireable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-816) Add access to dynamic-node-properties in termini
[ https://issues.apache.org/jira/browse/PROTON-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reassigned PROTON-816: - Assignee: Gordon Sim Add access to dynamic-node-properties in termini Key: PROTON-816 URL: https://issues.apache.org/jira/browse/PROTON-816 Project: Qpid Proton Issue Type: New Feature Components: python-binding Reporter: Ted Ross Assignee: Gordon Sim Fix For: 0.9 Attachments: PROTON-816.patch The Python reactive API needs to provide access to the dynamic-node-properties map in termini for senders and receivers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-816) Add access to dynamic-node-properties in termini
[ https://issues.apache.org/jira/browse/PROTON-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-816. --- Resolution: Fixed Add access to dynamic-node-properties in termini Key: PROTON-816 URL: https://issues.apache.org/jira/browse/PROTON-816 Project: Qpid Proton Issue Type: New Feature Components: python-binding Reporter: Ted Ross Assignee: Gordon Sim Fix For: 0.9 Attachments: PROTON-816.patch The Python reactive API needs to provide access to the dynamic-node-properties map in termini for senders and receivers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-815) LinkException on BlockingConnection.create_receiver() leaves things in bad state.
[ https://issues.apache.org/jira/browse/PROTON-815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reassigned PROTON-815: - Assignee: Gordon Sim LinkException on BlockingConnection.create_receiver() leaves things in bad state. - Key: PROTON-815 URL: https://issues.apache.org/jira/browse/PROTON-815 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.8 Environment: F20 with proton built from master. qpidd is 0.26. Reporter: Jeff Ortel Assignee: Gordon Sim Attachments: t.py Calling BlockingConnection.create_receiver() with an address that does not exist raises a LinkException. This is expected. However, all subsequent calls to either create_sender() or create_receiver() cause the original LinkException to be re-raised. Attaching a script to re-create. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-815) LinkException on BlockingConnection.create_receiver() leaves things in bad state.
[ https://issues.apache.org/jira/browse/PROTON-815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-815. --- Resolution: Fixed Fix Version/s: 0.9 LinkException on BlockingConnection.create_receiver() leaves things in bad state. - Key: PROTON-815 URL: https://issues.apache.org/jira/browse/PROTON-815 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.9 Environment: F20 with proton built from master. qpidd is 0.26. Reporter: Jeff Ortel Assignee: Gordon Sim Fix For: 0.9 Attachments: t.py Calling BlockingConnection.create_receiver() with an address that does not exist raises a LinkException. This is expected. However, all subsequent calls to either create_sender() or create_receiver() cause the original LinkException to be re-raised. Attaching a script to re-create. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-815) LinkException on BlockingConnection.create_receiver() leaves things in bad state.
[ https://issues.apache.org/jira/browse/PROTON-815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-815: -- Affects Version/s: (was: 0.8) 0.9 LinkException on BlockingConnection.create_receiver() leaves things in bad state. - Key: PROTON-815 URL: https://issues.apache.org/jira/browse/PROTON-815 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.9 Environment: F20 with proton built from master. qpidd is 0.26. Reporter: Jeff Ortel Assignee: Gordon Sim Fix For: 0.9 Attachments: t.py Calling BlockingConnection.create_receiver() with an address that does not exist raises a LinkException. This is expected. However, all subsequent calls to either create_sender() or create_receiver() cause the original LinkException to be re-raised. Attaching a script to re-create. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-817) BlockingConnection doesn't pass options down in create_sender or create_receiver
[ https://issues.apache.org/jira/browse/PROTON-817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-817. --- Resolution: Fixed BlockingConnection doesn't pass options down in create_sender or create_receiver Key: PROTON-817 URL: https://issues.apache.org/jira/browse/PROTON-817 Project: Qpid Proton Issue Type: Bug Components: python-binding Reporter: Ted Ross Assignee: Gordon Sim Fix For: 0.9 Attachments: PROTON-817.patch The options argument is not passed down from BlockingConnection.create_receiver to Container.create_receiver. The same is true for create_sender. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-812) LinkException needs an attribute that indicates the reason for the exception.
[ https://issues.apache.org/jira/browse/PROTON-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301530#comment-14301530 ] Gordon Sim commented on PROTON-812: --- When a peer detaches a link, it can supply a condition that is a string code that provides some context or reason for the detach. The correct behaviour on receiving an attach is always to echo an attach back, but then to follow that immediately with a detach. So, in general, in order to distinguish between two cases of the peer detaching a link there would need to be distinct conditions associated with the two cases. This change allows you to determine the condition. There is one special case, where the node the link is to be attached to doesn't exist and is not going to be created, the appropriate response is to send back an attach with no source or target (depending on direction of link) at all. That is in effect a precursor to an immediate detach with not-found as the condition. I don't know how dispatch router will handle case 2 above. For case 1, against qpidd, you will get a LinkException on create_receiver or create_sender, due to the source.target respectively being null on the attach sent back by the broker. LinkException needs an attribute that indicates the reason for the exception. - Key: PROTON-812 URL: https://issues.apache.org/jira/browse/PROTON-812 Project: Qpid Proton Issue Type: Improvement Affects Versions: 0.8 Reporter: Jeff Ortel Assignee: Gordon Sim Fix For: 0.9 LinkException needs an attribute that indicates the reason for the exception so that the exception can be appropriately delt with. For example: A link exception caused when a node does not exist would be delt with differently than a link exception caused by an issue in the link chain involving dispatch router. Having constants for the error codes would be desireable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-734) deliveries are not returned in order
[ https://issues.apache.org/jira/browse/PROTON-734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim closed PROTON-734. - Resolution: Won't Fix The conclusion here was to use the event api instead of the old work queue api, which avoids the problem. deliveries are not returned in order Key: PROTON-734 URL: https://issues.apache.org/jira/browse/PROTON-734 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Gordon Sim Assignee: Rafael H. Schloming Priority: Critical If, on a single session, I send e.g. 3 messages on one link, followed by a message on another link, then on the receiving side I expect those to be returned in the order in which they are sent. Although proton-c on the receiving side receives them in the correct order as verified by turning on tracing, the order in which the respective deliveries are returned by pn_work_head()/pn_work_next() is not correct. I get the first message, followed by the last message (i.e. the fourth), then the second and third. If I modify the test to send a fifth message to a third link, then on the receiving side the 5th message is received 3rd. I.e. it appears that the work queue involves taking the first delivery off each link, rather than having a session level ordering(?) In the case where a transaction discharge message is sent *after* some transactional publications, this results in the discharge being processed before all the publications the transaction is supposed to cover. (The sender can of course wait for all the transactional publications to be accepted before it sends the commit, but on a single session this isn't necessary and as far as I can see not required by the spec.) In any case, preserving order is likely to be important in other cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
