FYI, I filed this under PROTON-222. We should (fingers crossed) get a fix out in upcoming 0.4 release.
--Rafael On Tue, Jan 29, 2013 at 7:43 AM, Rafael Schloming <r...@alum.mit.edu> wrote: > There is definitely a bug here, I was able to reproduce it locally late > yesterday. I'm still investigating, but I'll file a JIRA today and let you > know what I learn. > > --Rafael > > > On Mon, Jan 28, 2013 at 10:03 PM, Paul O'Fallon <p...@ofallonfamily.com>wrote: > >> I tried your suggestion and set an outgoing window of 1 and that did in >> fact allow me to omit the stop() after every send(). It seems that >> whatever you are suspecting is probably right! :-) >> >> Thanks! >> >> - Paul >> >> On Mon, Jan 28, 2013 at 12:26 PM, Paul O'Fallon <p...@ofallonfamily.com >> >wrote: >> >> > Thanks for the reply! To your first question -- I haven't created a >> > special test case for this, but it is in my code here: >> > >> > >> > >> https://github.com/pofallon/node-qpid/blob/master/src/messenger.cc#L168-L177 >> > >> > (I'm in the early stages of writing node.js bindings to proton-c's >> > Messenger API) >> > >> > This code calls put, start, send and stop for each message (and will >> send >> > the message). If I comment out the "stop" on line 177 the messages are >> not >> > sent. (To see how this is invoked via node.js, see: >> > https://github.com/pofallon/node-qpid/blob/master/test/test.js#L18) >> > >> > To your second question, my end goal is "yes" to share it between >> threads. >> > Today my "Messenger" javascript object uses two pn_messenger instances >> -- >> > one to send and another to receive. However, I'd like to collapse that >> > into one instance for both sending and receiving (across multiple >> threads). >> > >> > Thanks again! >> > >> > - Paul >> > >> > On Mon, Jan 28, 2013 at 6:32 AM, Rafael Schloming <r...@alum.mit.edu >> >wrote: >> > >> >> On Fri, Jan 25, 2013 at 9:53 PM, Paul O'Fallon <p...@ofallonfamily.com >> >> >wrote: >> >> >> >> > Hello! I'm new to proton (and AMQP), and have some questions about >> >> using >> >> > the Messenger API in the C library to send messages to Windows Azure. >> >> I've >> >> > noticed that it takes three steps before a message is actually sent >> >> (i.e. >> >> > before it is fetched when running the 'recv' command line example). >> I >> >> call >> >> > pn_messenger_put(), pn_messenger_send(), and then >> pn_messenger_stop(). >> >> My >> >> > question is about the third call -- to pn_messenger_stop(). If I >> omit >> >> that >> >> > and just call the first two, the message is not actually sent. >> >> > >> >> > My concern is whether calling stop() after every send will be a >> problem >> >> in >> >> > the case where I want to use the same instance of messenger to call >> >> recv() >> >> > in a separate thread. The API docs state "A messenger cannot send or >> >> recv >> >> > messages when it is stopped.". >> >> > >> >> > So, two questions: >> >> > >> >> > (1) Is the need to call stop() after each send() expected behavior? >> >> > >> >> >> >> I wouldn't expect that you need to call stop() after each send(), >> however >> >> you should call it before exiting the program. Do you have a code >> fragment >> >> you could post that reproduces the behaviour you're seeing? It sounds >> like >> >> it could be a bug, if it is what I suspect you could try working >> around it >> >> by setting a positive outgoing window. >> >> >> >> >> >> > (2) Will repeatedly calling stop() affect the recv() running in the >> >> > separate thread? >> >> > >> >> >> >> Are you sharing a single messenger between the two threads? >> >> >> >> --Rafael >> >> >> > >> > >> > >
