[jira] [Updated] (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:all-tabpanel
]
William Henry updated PROTON-31:
Attachment: send_image.py
Trying to send a file in chunks to a receiver.
> 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, send_image.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
[jira] [Comment Edited] (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-tabpanel&focusedCommentId=13460036#comment-13460036
]
William Henry edited comment on PROTON-31 at 9/21/12 10:12 AM:
---
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
Image block [ 1 ] put
Image block [ 2 ] put
Image block [ 3 ] put
Image block [ 4 ] put
Image block [ 5 ] put
Image block [ 6 ] put
Image block [ 7 ] put
ERROR amqp:connection:framing-error connection aborted
[0xb86cb0:0] ERROR[-2] connection aborted
Image block [ 8 ] put
Error put [-2]: unable to send to address: //localhost (connect: Connection
refused)
was (Author: whenry):
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
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
[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-tabpanel&focusedCommentId=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
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
Re: What is Messenger API
On Thu, Sep 20, 2012 at 03:37:10PM -0400, Rajith Attapattu wrote: > Given some of the recent discussions, it appears there isn't much > consensus as to what the "Messenger API" is. > For my own sanity, could someone with more knowledge on the $subject > please explain the following? > > 1. What is Messenger API ? > i.e Do we have a doc or a wiki page that documents what the API > is and more importantly what the expected behaviour is. From my perspective, a Messenger is a high-level end-point for sending and receiving messages. It keeps you from having to worry about the underlying components of a session, a context, encoding and decoding messages. Instead, it gives you very simple APIs to start and stop communications, queue up and send messages and receive and then pull out individual messages for processing. > 2. How is it different from the "Messaging API aka Qpid API" > I'm looking for something more than the matrix given by Rafi, all > though it provides a good start to understanding it. Again, from my perspective, it reduces the complexity by, again, keeping you from having to worry about the details of connecting with a remote messaging endpoint. Something else is that it's designed from the ground up with efficiency. One specific one that comes to mind is the pn_messenger_get() API, which can reuse existing instances of pn_message_t to avoid spending time allocating memory. > 3. How are we planning to position these various API's in the future? > I agree that a lot of things are up in the air, but it's also good > to share some early ideas all though they might change in the future. My understanding is that we'll have a layer on top of Proton that will provide the existing Qpid APIs while, underneath, Proton is doing the heavy lifting. I may be wrong on some (or all) points, in which case someone please set me straight. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpgslEEOwyBa.pgp Description: PGP signature
Re: What is Messenger API
- Original Message - > On Thu, Sep 20, 2012 at 4:02 PM, William Henry > wrote: > > Best to look at proton's examples/messenger send.py and recv.py > > > > That's the only documentation besides messenger.h > > That's precisely my point. > We can't continue to point people at examples to figure out what the > API is. > Given that we are going to do a bunch of releases, we should spend > some time trying to document this API and it's intended behaviour. > > William, given that you've used it extensively, would you like to > take > a stab at it? I wouldn't say I've used it extensively. I am getting to know it better though. Can we get some suggestions on the format that we'd like to see this documentation in? William > > Rajith >
Re: What is Messenger API
On Thu, Sep 20, 2012 at 4:02 PM, William Henry wrote: > Best to look at proton's examples/messenger send.py and recv.py > > That's the only documentation besides messenger.h That's precisely my point. We can't continue to point people at examples to figure out what the API is. Given that we are going to do a bunch of releases, we should spend some time trying to document this API and it's intended behaviour. William, given that you've used it extensively, would you like to take a stab at it? Rajith
Re: What is Messenger API
Best to look at proton's examples/messenger send.py and recv.py That's the only documentation besides messenger.h William On Sep 20, 2012, at 1:37 PM, Rajith Attapattu wrote: > Given some of the recent discussions, it appears there isn't much > consensus as to what the "Messenger API" is. > For my own sanity, could someone with more knowledge on the $subject > please explain the following? > > 1. What is Messenger API ? > i.e Do we have a doc or a wiki page that documents what the API > is and more importantly what the expected behaviour is. > > 2. How is it different from the "Messaging API aka Qpid API" >I'm looking for something more than the matrix given by Rafi, all > though it provides a good start to understanding it. > > 3. How are we planning to position these various API's in the future? >I agree that a lot of things are up in the air, but it's also good > to share some early ideas all though they might change in the future. > > Regards, > > Rajith
Engine API
We should seriously consider documenting the Engine API and it's expected behaviour. This has several advantages. 1. Use that as a basis for a functional spec, which we can then write tests to verify the implementations. 2. Helps developers to navigate and understand the code more easily. 3. Finally we need this documentation sooner than later to accompany our releases to for the end users 4. Helps to keep both C and Java impls in sync. We should probably modify the doc before we change the code to ensure the doc is kept current. Any takers ? (Looking at Rafi :D) Regards, Rajith
What is Messenger API
Given some of the recent discussions, it appears there isn't much consensus as to what the "Messenger API" is. For my own sanity, could someone with more knowledge on the $subject please explain the following? 1. What is Messenger API ? i.e Do we have a doc or a wiki page that documents what the API is and more importantly what the expected behaviour is. 2. How is it different from the "Messaging API aka Qpid API" I'm looking for something more than the matrix given by Rafi, all though it provides a good start to understanding it. 3. How are we planning to position these various API's in the future? I agree that a lot of things are up in the air, but it's also good to share some early ideas all though they might change in the future. Regards, Rajith
[jira] [Commented] (PROTON-29) Provide the Messenger and Message classes for easy messaging.
[ https://issues.apache.org/jira/browse/PROTON-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13459876#comment-13459876 ] Darryl L. Pierce commented on PROTON-29: I've updated the Qpid::Proton::Messenger class to raise exceptions on methods with return codes. There's a new mixin called Qpid::Proton::ExceptionHandling that classes can use to work with those return codes in order to consistently raise exceptions. > Provide the Messenger and Message classes for easy messaging. > - > > Key: PROTON-29 > URL: https://issues.apache.org/jira/browse/PROTON-29 > Project: Qpid Proton > Issue Type: Sub-task >Reporter: Darryl L. Pierce > Attachments: 0001-Added-Ruby-language-mappings-for-pn_atom_t.patch, > 0002-Added-a-require-to-spec_helper-for-the-qpid_proton-A.patch, > 0003-Ruby-exceptions-and-exception-helpers.patch, > 0004-Created-the-new-Message-class.patch, > 0005-Created-the-new-Messenger-type.patch, > 0006-Rewrote-the-send-and-recv-Ruby-examples-to-use-the-n.patch > > > Provides code for the Qpid::Proton::Messenger and Qpid::Proton::Message > classes, including new mappings in Swig for pn_atom_t, and a rewrite of the > send and recv examples to use the new classes. -- 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-29) Provide the Messenger and Message classes for easy messaging.
[ https://issues.apache.org/jira/browse/PROTON-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce updated PROTON-29: --- Attachment: 0006-Rewrote-the-send-and-recv-Ruby-examples-to-use-the-n.patch 0005-Created-the-new-Messenger-type.patch 0004-Created-the-new-Message-class.patch 0003-Ruby-exceptions-and-exception-helpers.patch 0002-Added-a-require-to-spec_helper-for-the-qpid_proton-A.patch 0001-Added-Ruby-language-mappings-for-pn_atom_t.patch > Provide the Messenger and Message classes for easy messaging. > - > > Key: PROTON-29 > URL: https://issues.apache.org/jira/browse/PROTON-29 > Project: Qpid Proton > Issue Type: Sub-task >Reporter: Darryl L. Pierce > Attachments: 0001-Added-Ruby-language-mappings-for-pn_atom_t.patch, > 0002-Added-a-require-to-spec_helper-for-the-qpid_proton-A.patch, > 0003-Ruby-exceptions-and-exception-helpers.patch, > 0004-Created-the-new-Message-class.patch, > 0005-Created-the-new-Messenger-type.patch, > 0006-Rewrote-the-send-and-recv-Ruby-examples-to-use-the-n.patch > > > Provides code for the Qpid::Proton::Messenger and Qpid::Proton::Message > classes, including new mappings in Swig for pn_atom_t, and a rewrite of the > send and recv examples to use the new classes. -- 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
Re: Messenger API and subscriptions
On Thu, Sep 20, 2012 at 1:44 PM, William Henry wrote: > > > - Original Message - > > On Thu, Sep 20, 2012 at 12:32 PM, William Henry > > wrote: > > > > > > > > > > > - Original Message - > > > > How about: > > > > > > > > int pn_messenger_subscribe(pn_messenger_t *messenger, const char > > > > *source, > > > > void* context); > > > > > > This one I like. It makes a lot of sense. > > > > > > > void *pn_message_subscribe_context(pn_message_t *msg); > > > > > > > > > > This one less so. I have to make an extra call after I receive the > > > message. Then the implementation needs to do some sort of lookup. > > > I think > > > it would be much more efficient if I had an API that returned the > > > message > > > and the context. > > > > > > > I can't imagine there would be a significant difference in efficiency > > in > > any real world scenario. The internal mechanism to find the context > > should > > be exactly the same either way, and setting the context in an out > > parameter > > vs setting a slot on the message are both just pointer indirection. > > I didn't realize you were setting something in the message. So you would > modify the message? That's ok? > > If it is then I'm good with that. > > My thinking was: you'd have the context when you received the message. > You'd have to look it up the other way. But if you set something when you > receive it then is't more or less the same thing as what I was looking for. > Yeah, the way get works is that it just fills in the message object that you pass it. The idea being that for high performance scenarios you can reuse the same message object, e.g. call get to fill in the new message, process it, and then call get again on that same message object. --Rafael
[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-tabpanel&focusedCommentId=13459786#comment-13459786
]
Ted Ross commented on PROTON-31:
If the sender is modified to construct a new Message object for each loop, the
problem goes away. It appears that the issue is related to the reuse of the
message object in the sender.
> 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
Re: Messenger API and subscriptions
- Original Message - > On Thu, Sep 20, 2012 at 12:32 PM, William Henry > wrote: > > > > > > > - Original Message - > > > How about: > > > > > > int pn_messenger_subscribe(pn_messenger_t *messenger, const char > > > *source, > > > void* context); > > > > This one I like. It makes a lot of sense. > > > > > void *pn_message_subscribe_context(pn_message_t *msg); > > > > > > > This one less so. I have to make an extra call after I receive the > > message. Then the implementation needs to do some sort of lookup. > > I think > > it would be much more efficient if I had an API that returned the > > message > > and the context. > > > > I can't imagine there would be a significant difference in efficiency > in > any real world scenario. The internal mechanism to find the context > should > be exactly the same either way, and setting the context in an out > parameter > vs setting a slot on the message are both just pointer indirection. I didn't realize you were setting something in the message. So you would modify the message? That's ok? If it is then I'm good with that. My thinking was: you'd have the context when you received the message. You'd have to look it up the other way. But if you set something when you receive it then is't more or less the same thing as what I was looking for. William > The > only difference would be the procedure call overhead associated with > actually accessing the pointer stored inside the message, and if that > starts being an issue then I think (a) we have much bigger trouble > since > that's how all the fields inside a message are accessed, and (b) > we're > totally awesome because we must have done an impossibly great job of > optimizing the rest of the code for this to even show up on a > profile. ;-) > > --Rafael >
[jira] [Created] (PROTON-31) Message Corruption in point-to-point transfer via messenger
Ted Ross created PROTON-31:
--
Summary: 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
[jira] [Updated] (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:all-tabpanel
]
Ted Ross updated PROTON-31:
---
Attachment: send1.py
Invoked as:
$ ./send1.py -a //0.0.0.0/queue1
> 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
Re: Messenger API and subscriptions
On Thu, Sep 20, 2012 at 12:32 PM, William Henry wrote: > > > - Original Message - > > How about: > > > > int pn_messenger_subscribe(pn_messenger_t *messenger, const char > > *source, > > void* context); > > This one I like. It makes a lot of sense. > > > void *pn_message_subscribe_context(pn_message_t *msg); > > > > This one less so. I have to make an extra call after I receive the > message. Then the implementation needs to do some sort of lookup. I think > it would be much more efficient if I had an API that returned the message > and the context. > I can't imagine there would be a significant difference in efficiency in any real world scenario. The internal mechanism to find the context should be exactly the same either way, and setting the context in an out parameter vs setting a slot on the message are both just pointer indirection. The only difference would be the procedure call overhead associated with actually accessing the pointer stored inside the message, and if that starts being an issue then I think (a) we have much bigger trouble since that's how all the fields inside a message are accessed, and (b) we're totally awesome because we must have done an impossibly great job of optimizing the rest of the code for this to even show up on a profile. ;-) --Rafael
Re: Messenger API and subscriptions
- Original Message - > How about: > > int pn_messenger_subscribe(pn_messenger_t *messenger, const char > *source, > void* context); This one I like. It makes a lot of sense. > void *pn_message_subscribe_context(pn_message_t *msg); > This one less so. I have to make an extra call after I receive the message. Then the implementation needs to do some sort of lookup. I think it would be much more efficient if I had an API that returned the message and the context. William > 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. > > --Rafael > > On Wed, Sep 19, 2012 at 12:05 PM, William Henry > wrote: > > > > > > > - Original Message - > > > > > > > > > - Original Message - > > > > Can we expose the subscription for an incoming message on the > > > > messenger API in some way? > > > > > > > > > > Motivation: > > > > > > I'm trying to integrate with another messaging API. That API may > > > handle incoming messages differently based on their notion of a > > > subscription. Currently I would have to parse an incoming > > > message's > > > address and try to match that with some list of subscription > > > strings. > > > > > > It would be handier if I could just get something back form the > > > API > > > to help me track/lookup. > > > > > > > More thoughts: > > > > 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. > > > > Or something like that. > > > > Thoughts? > > > > William > > > > > William > > > > > > > > > > > > > > > > > > > William > > > > > >
Re: AMQP 1.0 support for JMS client via Proton
On Thu, Sep 20, 2012 at 4:00 AM, Rob Godfrey wrote: > On 20 September 2012 00:32, Rajith Attapattu wrote: > >> Hi All, >> >> There are a few folks who are keen to have AMQP 1.0 support for our JMS >> client. >> Given that the parent AMQP TC is starting a bindings and mappings TC >> which will cover JMS, I thought it would be a good idea to get a >> discussion going on here as well. >> We could aim to build the client as we progress through the TC and >> provide feedback if necessary. >> >> On the hand, we've had extensive discussions on building a new JMS >> client from scratch when adding 1.0 support. >> The primary motivation was to address some of the nagging issues >> around the old client. >> >> So far there have been two schools of thought on how to get AMQP 1.0 >> support. >> >> 1. JMS Client --> Qpid API --> Proton >> >> 2. JMS Client --> Proton >> >> While option #1 seems like killing two birds with one stone, I think >> we should seriously consider option #2 as well. >> >> > So, regardless of which path we take I think we need to carefully define > the functional requirements for our JMS client. Looking at the JIRAs, and > based on the experience of supporting the current client, the two areas > where it causes most problems are 1) failover and 2) addressing. > > For both (but especially failover) I think we need a very clear > understanding of the functionality we are looking for the client to provide > before we can decide which layer it is best placed in. If the functionality > is likely to be common across the JMS and Qpid APIs then it would seem > sensible not to write this code directly into the JMS layer. > > Before we start cutting any code I think we need general agreement in the > Qpid Java community about the functionality that is required and where it > is going to be implemented (and ideally we should also be coordinating by > whom it is going to be implemented also :-) ). Indeed! My intention was to get this conversation happening and for us to start formulating a plan. As I mentioned in my original email, a plan is very important, so we know who's doing what and more importantly some milestones as to when we can expect things to happen. I agree with you about the main problem areas. I also think we need to pay very close attention to our threading and synchronization strategies as we have quite a few issues there. We should put up a page on wiki to document the requirements and have a conversation happening on the lists to come to an agreement. We should then define milestones and deliverables. Without that it's going to be meaningless. Once we do that we could start coordinating about the code contributions and adjust the plan if we feel we have resourcing issues. Rajith > -- Rob > > > >> I would love to hear everybody's thoughts on this. >> More importantly it's good if we could also discuss on a plan and set >> some milestones to ensure we stay focused. >> >> Personally I would love to see a reasonably working prototype by 0.22. >> If we can get something going for 0.20 that would be a bonus, even if >> it's just experimental (preferably on a branch) and Alpha quality. >> >> I mentioned the above milestones to kick start the discussion and get >> things rolling. >> We could start on a branch and then move it to trunk during 0.22 if >> everybody is satisfied with the progress. >> >> Regards, >> >> Rajith >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org >> For additional commands, e-mail: dev-h...@qpid.apache.org >> >>
Re: AMQP 1.0 support for JMS client via Proton
On 20 September 2012 00:32, Rajith Attapattu wrote: > Hi All, > > There are a few folks who are keen to have AMQP 1.0 support for our JMS > client. > Given that the parent AMQP TC is starting a bindings and mappings TC > which will cover JMS, I thought it would be a good idea to get a > discussion going on here as well. > We could aim to build the client as we progress through the TC and > provide feedback if necessary. > > On the hand, we've had extensive discussions on building a new JMS > client from scratch when adding 1.0 support. > The primary motivation was to address some of the nagging issues > around the old client. > > So far there have been two schools of thought on how to get AMQP 1.0 > support. > > 1. JMS Client --> Qpid API --> Proton > > 2. JMS Client --> Proton > > While option #1 seems like killing two birds with one stone, I think > we should seriously consider option #2 as well. > > So, regardless of which path we take I think we need to carefully define the functional requirements for our JMS client. Looking at the JIRAs, and based on the experience of supporting the current client, the two areas where it causes most problems are 1) failover and 2) addressing. For both (but especially failover) I think we need a very clear understanding of the functionality we are looking for the client to provide before we can decide which layer it is best placed in. If the functionality is likely to be common across the JMS and Qpid APIs then it would seem sensible not to write this code directly into the JMS layer. Before we start cutting any code I think we need general agreement in the Qpid Java community about the functionality that is required and where it is going to be implemented (and ideally we should also be coordinating by whom it is going to be implemented also :-) ). -- Rob > I would love to hear everybody's thoughts on this. > More importantly it's good if we could also discuss on a plan and set > some milestones to ensure we stay focused. > > Personally I would love to see a reasonably working prototype by 0.22. > If we can get something going for 0.20 that would be a bonus, even if > it's just experimental (preferably on a branch) and Alpha quality. > > I mentioned the above milestones to kick start the discussion and get > things rolling. > We could start on a branch and then move it to trunk during 0.22 if > everybody is satisfied with the progress. > > Regards, > > Rajith > > - > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > For additional commands, e-mail: dev-h...@qpid.apache.org > >
