[jira] [Resolved] (PROTON-76) Suspiciously insufficient looking buffer allocation in messenger.c
[ https://issues.apache.org/jira/browse/PROTON-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-76. --- Resolution: Fixed > Suspiciously insufficient looking buffer allocation in messenger.c > -- > > Key: PROTON-76 > URL: https://issues.apache.org/jira/browse/PROTON-76 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Rob Godfrey >Assignee: Rafael H. Schloming >Priority: Blocker > > Lines 541-549: > if (len > 1 && address[0] == '~' && address[1] == '/') { > char buf[len + strlen(mng->name) + 4]; > sprintf(buf, "amqp://%s/%s", mng->name, address); > pn_message_set_reply_to(msg, buf); > } else if (len == 0) { > char buf[strlen(mng->name) + 4]; > sprintf(buf, "amqp://%s", mng->name); > pn_message_set_reply_to(msg, buf); > } > should the first "4" not be an "8" and the second a "7"? -- 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-33) Provide API for user managed pn_message_t payload/memory
[ https://issues.apache.org/jira/browse/PROTON-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-33: -- Fix Version/s: 0.2 > Provide API for user managed pn_message_t payload/memory > > > Key: PROTON-33 > URL: https://issues.apache.org/jira/browse/PROTON-33 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: William Henry >Priority: Blocker > Labels: api > Fix For: 0.2 > > > Some users will have their own frameworks and methods of managing the data > received. > Currently in the pn_message_t the only way to get at the payload/data is to > call pn_message_save with a pre-allocated buffer of data. pn_message_save > copies to that data buffer and returns the actual size. (so for example if I > passed an allocated buffer of 1028 I might be returned 8 bytes). > In many situations this alloc is expensive - especially when integrating with > established frameworks that already do the copy - now there are two allocs. > I suggest an API call that returns the message payload as a pointer. There > is a risk that this might get deleted and a pn_message_t should check that > it's buffer is still valid (I assume it would.) In the case I'm looking at > the "other" framework is merely making it's own copy but doesn't free the > memory (but, as I said, there is a risk it could). > I'm willing to debate pn_message_t having an API that returns a copy but I > imagine many users will any up complaining about the alloc in the that API > call. -- 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-85) Unable to set Message id and correlation id
[ https://issues.apache.org/jira/browse/PROTON-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-85. --- Resolution: Fixed > Unable to set Message id and correlation id > --- > > Key: PROTON-85 > URL: https://issues.apache.org/jira/browse/PROTON-85 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: William Henry >Assignee: Rafael H. Schloming >Priority: Blocker > > For example in python unable to: > my_msg.id = > Some value must be a pn_atom_t. How can I take a uuid and convert to a > pn_atom_t so I can set id or correlation_id? -- 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-46) No way to get at a message's subscription using pn_messenger_t and pn_message_t APIs
[ https://issues.apache.org/jira/browse/PROTON-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated PROTON-46: --- Fix Version/s: 0.2 > No way to get at a message's subscription using pn_messenger_t and > pn_message_t APIs > - > > Key: PROTON-46 > URL: https://issues.apache.org/jira/browse/PROTON-46 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: William Henry >Priority: Blocker > Labels: api > Fix For: 0.2 > > > Motivation: > Integrate with another messaging API. That other API may handle incoming > messages differently based on their notion of a subscription. There is no > way to know which subscription a message came in on when using the messenger > API. > It would be handier if I could just get something back form the API to help > me track/lookup. > What would be nice is two API additions. > int pn_messenger_context_subscribe(pn_messenger_t *messenger, const char > *source, void* context); > int pn_messenger_context_get(pn_messenger_t *messenger, pn_message_t *msg, > void* context); > The get would return the context for that message based on the subscription. > Alternatively what would be better is: > int pn_messenger_subscribe(pn_messenger_t *messenger, const char *source, > void* context); > void *pn_message_subscribe_context(pn_message_t *msg); > For C we can just leave it as NULL if we don't care about it and in the > idiomatic APIs we can turn it into an optional argument. > An incoming message would have it's subscription context stored with it when > it arrives. No extra lookup required on the: void > *pn_message_subscribe_context(pn_message_t *msg); -- 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-46) No way to get at a message's subscription using pn_messenger_t and pn_message_t APIs
[ https://issues.apache.org/jira/browse/PROTON-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13480339#comment-13480339 ] William Henry commented on PROTON-46: - API changes in Messenger to allow subscription tracking: (Pseudo code) Messenger subscription* subscribe(addr); void unsubscribe(subscription*); void set_context(subscription*, void*); void* get_context(subscription*); Message subscription* get_subscription(message*); > No way to get at a message's subscription using pn_messenger_t and > pn_message_t APIs > - > > Key: PROTON-46 > URL: https://issues.apache.org/jira/browse/PROTON-46 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: William Henry >Priority: Blocker > Labels: api > > Motivation: > Integrate with another messaging API. That other API may handle incoming > messages differently based on their notion of a subscription. There is no > way to know which subscription a message came in on when using the messenger > API. > It would be handier if I could just get something back form the API to help > me track/lookup. > What would be nice is two API additions. > int pn_messenger_context_subscribe(pn_messenger_t *messenger, const char > *source, void* context); > int pn_messenger_context_get(pn_messenger_t *messenger, pn_message_t *msg, > void* context); > The get would return the context for that message based on the subscription. > Alternatively what would be better is: > int pn_messenger_subscribe(pn_messenger_t *messenger, const char *source, > void* context); > void *pn_message_subscribe_context(pn_message_t *msg); > For C we can just leave it as NULL if we don't care about it and in the > idiomatic APIs we can turn it into an optional argument. > An incoming message would have it's subscription context stored with it when > it arrives. No extra lookup required on the: void > *pn_message_subscribe_context(pn_message_t *msg); -- 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-74) Fix the mailbox example.
[ https://issues.apache.org/jira/browse/PROTON-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13480316#comment-13480316 ] Ted Ross commented on PROTON-74: This example has been removed from the generated tarballs (release.sh). I have deferred this issue to be fixed in a later release. > Fix the mailbox example. > > > Key: PROTON-74 > URL: https://issues.apache.org/jira/browse/PROTON-74 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.1 >Reporter: Ken Giusti >Assignee: Ken Giusti > Fix For: 0.2 > > > Doesn't work - needs to be brought up to date with current engine 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-74) Fix the mailbox example.
[ https://issues.apache.org/jira/browse/PROTON-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated PROTON-74: --- Priority: Major (was: Blocker) > Fix the mailbox example. > > > Key: PROTON-74 > URL: https://issues.apache.org/jira/browse/PROTON-74 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.1 >Reporter: Ken Giusti >Assignee: Ken Giusti > Fix For: 0.2 > > > Doesn't work - needs to be brought up to date with current engine 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-74) Fix the mailbox example.
[ https://issues.apache.org/jira/browse/PROTON-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated PROTON-74: --- Affects Version/s: 0.1 > Fix the mailbox example. > > > Key: PROTON-74 > URL: https://issues.apache.org/jira/browse/PROTON-74 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.1 >Reporter: Ken Giusti >Assignee: Ken Giusti > Fix For: 0.2 > > > Doesn't work - needs to be brought up to date with current engine 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-74) Fix the mailbox example.
[ https://issues.apache.org/jira/browse/PROTON-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated PROTON-74: --- Fix Version/s: 0.2 > Fix the mailbox example. > > > Key: PROTON-74 > URL: https://issues.apache.org/jira/browse/PROTON-74 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.1 >Reporter: Ken Giusti >Assignee: Ken Giusti > Fix For: 0.2 > > > Doesn't work - needs to be brought up to date with current engine 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] [Resolved] (PROTON-47) Script to generate release tarballs
[ https://issues.apache.org/jira/browse/PROTON-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved PROTON-47. Resolution: Fixed Fix Version/s: 0.1 > Script to generate release tarballs > --- > > Key: PROTON-47 > URL: https://issues.apache.org/jira/browse/PROTON-47 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c, proton-j >Reporter: Darryl L. Pierce >Assignee: Rafael H. Schloming >Priority: Blocker > Fix For: 0.1 > > Attachments: > 0001-Provides-a-script-for-generated-source-tarballs.patch > > > The script takes as input a version, and option subversion repository and > branch. It then generates a tarball for use in packaging and distribution. -- 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-85) Unable to set Message id and correlation id
[ https://issues.apache.org/jira/browse/PROTON-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13480304#comment-13480304 ] William Henry commented on PROTON-85: - Might want to fix PROTON-86 while you're in there. If it's not too difficult. > Unable to set Message id and correlation id > --- > > Key: PROTON-85 > URL: https://issues.apache.org/jira/browse/PROTON-85 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: William Henry >Assignee: Rafael H. Schloming >Priority: Blocker > > For example in python unable to: > my_msg.id = > Some value must be a pn_atom_t. How can I take a uuid and convert to a > pn_atom_t so I can set id or correlation_id? -- 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-85) Unable to set Message id and correlation id
[ https://issues.apache.org/jira/browse/PROTON-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated PROTON-85: --- Assignee: Rafael H. Schloming > Unable to set Message id and correlation id > --- > > Key: PROTON-85 > URL: https://issues.apache.org/jira/browse/PROTON-85 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: William Henry >Assignee: Rafael H. Schloming >Priority: Blocker > > For example in python unable to: > my_msg.id = > Some value must be a pn_atom_t. How can I take a uuid and convert to a > pn_atom_t so I can set id or correlation_id? -- 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-44) pn_message_t group_sequence doesn't set
[ https://issues.apache.org/jira/browse/PROTON-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved PROTON-44. Resolution: Cannot Reproduce Fix Version/s: 0.1 Assignee: Ted Ross (was: Rafael H. Schloming) I tested this feature against the latest proton trunk (revision 1400130) and could not reproduce the reported symptom. > pn_message_t group_sequence doesn't set > --- > > Key: PROTON-44 > URL: https://issues.apache.org/jira/browse/PROTON-44 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: William Henry >Assignee: Ted Ross >Priority: Blocker > Fix For: 0.1 > > > I've tried setting group_sequence in a python example and it always returns 0. -- 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-25) Connection doesn't transistion to PN_REMOTE_CLOSED when socket is closed.
[ https://issues.apache.org/jira/browse/PROTON-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved PROTON-25. Resolution: Not A Problem Fix Version/s: 0.1 This is not a bug, only a user error. When the socket is closed without AMQP-level close, the connector is closed but the connection remains open. This is a case that needs to be handled by the application. Please note that the application may need to do some special recovery if a connector is closed and there are unsettled deliveries. > Connection doesn't transistion to PN_REMOTE_CLOSED when socket is closed. > - > > Key: PROTON-25 > URL: https://issues.apache.org/jira/browse/PROTON-25 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Ted Ross >Assignee: Ken Giusti >Priority: Blocker > Fix For: 0.1 > > > After a connection has been established and opened both remotely and locally, > if that connection is closed uncleanly (i.e. the socket is closed without any > handshake), the connection object will not transition to PN_REMOTE_CLOSED. > The closed connection is awakened and processed by the driver, but its state > is not changed. Any state the application has associated with the > connection, its sessions, and its links will not be cleaned up. -- 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