[jira] [Commented] (PROTON-137) pn_messenger_incoming_subscription returning null
[ https://issues.apache.org/jira/browse/PROTON-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13498922#comment-13498922 ] William Henry commented on PROTON-137: -- Looks like this is working now after latest messenger.c fix. I'm doing some more testing. pn_messenger_incoming_subscription returning null - Key: PROTON-137 URL: https://issues.apache.org/jira/browse/PROTON-137 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.2 Reporter: William Henry Priority: Blocker Calling pn_messenger_incoming_subscription after successfully calling pn_messenger_get is unexpectedly returning 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-101) How do I get the examples to work
William Henry created PROTON-101: Summary: How do I get the examples to work Key: PROTON-101 URL: https://issues.apache.org/jira/browse/PROTON-101 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.1 Reporter: William Henry Priority: Blocker There is no instructions or config.sh file that helps to get the python examples to run. Related to PROTON-100. -- 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-tabpanelfocusedCommentId=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] [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 ] William Henry updated PROTON-46: Priority: Blocker (was: Major) 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] [Created] (PROTON-85) Unable to set Message id and correlation id
William Henry created PROTON-85: --- Summary: 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 Priority: Blocker For example in python unable to: my_msg.id = somevalue 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] [Created] (PROTON-86) Automatically generate a message id on creation or clear
William Henry created PROTON-86: --- Summary: Automatically generate a message id on creation or clear Key: PROTON-86 URL: https://issues.apache.org/jira/browse/PROTON-86 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: William Henry Useful to have an automatically generated unique id for a message. That way users have one by default but can always set it explicitly using set_id if needed. -- 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-46) No way to get at a message's subscription using pn_messenger_t and pn_message_t APIs
William Henry created PROTON-46: --- Summary: 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 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] [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 ] William Henry updated PROTON-33: Description: 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. was: 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. 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 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] [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 ] William Henry updated PROTON-33: Description: 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. was: 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. 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 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] [Commented] (PROTON-31) Message Corruption in point-to-point transfer via messenger
[
https://issues.apache.org/jira/browse/PROTON-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13460036#comment-13460036
]
William Henry commented on PROTON-31:
-
It doesn't go away for me in my modified version.
$ ./recv_image.py //~0.0.0.0
Error mng.get: [-4]: error decoding message: (null)
Error mng.get: [-4]: error decoding message: (null)
Error mng.get: [-4]: error decoding message: (null)
My send:
$ ./send_image.py -a //localhost
Block [ 1 ] put
Block [ 2 ] put
Block [ 3 ] put
Block [ 4 ] put
Block [ 5 ] put
Block [ 6 ] put
Block [ 7 ] put
Block [ 8 ] put
Block [ 9 ] put
ERROR amqp:connection:framing-error connection aborted
[0x1e34b30:0] ERROR[-2] connection aborted
Block [ 10 ] put
Traceback (most recent call last):
File ./send_image.py, line 52, in module
if mng.put(msg):
File /home/whenry/os/qpid-proton/trunk/proton-c/bindings/python/proton.py,
line 58, in put
self._check(pn_messenger_put(self._mng, msg._msg))
File /home/whenry/os/qpid-proton/trunk/proton-c/bindings/python/proton.py,
line 32, in _check
raise exc([%s]: %s % (err, pn_messenger_error(self._mng)))
proton.MessengerException: [-2]: unable to send to address: //localhost
(connect: Connection refused)
Message Corruption in point-to-point transfer via messenger
---
Key: PROTON-31
URL: https://issues.apache.org/jira/browse/PROTON-31
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Reporter: Ted Ross
Attachments: send1.py
Using a modified version of the send.py messenger example (attached) and
sending messages point-to-point from sender to receiver, messages become
corrupted.
Output from the receiver:
{{
$ ./recv.py //~0.0.0.0/queue1
//0.0.0.0/queue1 (no subject) Message:0
//0.0.0.0/queue1 (no subject) Message:1
//0.0.0.0/queue1 (no subject) Message:2
//0.0.0.0/queue1 (no subject) Message:3
//0.0.0.0/queue1 (no subject) H(�]
//0.0.0.0/queue1 (no subject) Message:5
//0.0.0.0/queue1 (no subject) Message:6
//0.0.0.0/queue1 (no subject) Message:7
//0.0.0.0/queue1 (no subject) Message:8
//0.0.0.0/queue1 (no subject) Message:9
//0.0.0.0/queue1 (no subject) Message:10
//0.0.0.0/queue1 (no subject) Message:11
//0.0.0.0/queue1 (no subject) Message:12
//0.0.0.0/queue1 (no subject) Message:13
//0.0.0.0/queue1 (no subject) Message:14
//0.0.0.0/queue1 (no subject) Message:15
//0.0.0.0/queue1 (no subject) Message:16
//0.0.0.0/queue1 (no subject) Message:17
//0.0.0.0/queue1 (no subject) Message:18
//0.0.0.0/queue1 (no subject) Message:19
//0.0.0.0/queue1 (no subject) Message:20
//0.0.0.0/queue1 (no subject) Message:21
//0.0.0.0/queue1 (no subject) Message:22
//0.0.0.0/queue1 (no subject) Message:23
//0.0.0.0/queue1 (no subject) Message:24
//0.0.0.0/queue1 (no subject) Message:25
//0.0.0.0/queue1 (no subject) Message:26
//0.0.0.0/queue1 (no subject) Message:27
//0.0.0.0/queue1 (no subject) Message:28
//0.0.0.0/queue1 (no subject) Message:29
//0.0.0.0/queue1 (no subject) Message:30
//0.0.0.0/queue1 (no subject) Message:31
//0.0.0.0/queue1 (no subject) Message:32
//0.0.0.0/queue1 (no subject) Message:33
//0.0.0.0/queue1 (no subject) Message:34
[-4]: error decoding message: (null)
[-4]: error decoding message: (null)
[-4]: error decoding message: (null)
[-4]: error decoding message: (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
