From: "Ken Giusti" <[email protected]>
To: [email protected]
Sent: Tuesday, November 19, 2013 3:17:37 PM
Subject: Re: using proton messenger *asynchronously*
Hi Fraser,
----- Original Message -----
From: "Fraser Adams" <[email protected]>
To: [email protected]
Sent: Sunday, November 17, 2013 7:04:53 AM
Subject: using proton messenger *asynchronously*
Hey all,
I've been messing around trying to get messenger to do something in
asynchronous mode. The comments here:
http://qpid.apache.org/components/messenger/book/sending-and-receiving.html
Suggest that it's possible - though the doc there probably needs an edit
because |pn_messenger_send(messenger) |isn't legal - it needs a second
parameter, the actual prototype is:
/*
* @param[in] messenger the messager
* @param[in] n the number of messages to send
*
* @return an error code or zero on success
* @see error.h
*/
PN_EXTERN int pn_messenger_send(pn_messenger_t *messenger, int n);
But that's by the by:
When I started playing with this I eventually figured out that I needed
to have:
pn_messenger_set_blocking(messenger, false);
After I've created a messenger, as well as doing:
pn_messenger_send(messenger, 0);
But it all seems a lot more cryptic than that. Under the hood there's a
call to pn_messenger_tsync, which in blocking mode eventually ends up
blocking on a poll and has a while loop internally. Now that tsync call
seems to do a whole bunch of things actually leading to sends and
receives of the sockets, so it seems just calling pn_messenger_send in
non-blocking mode isn't enough and I need to call
pn_messenger_work(messenger, 0); too.
You're correct here - it appears that the web page you reference hasn't been
updated since Rafi added the non-blocking stuff. You definitely need to
call pn_messenger_work() in order to have data hit the wire.
I've attached some *really hacky* code. The code is pretty rubbishy, in
the case of send it's calling pn_messenger_send then calling a main loop
that does pn_messenger_work(messenger, 0); periodically. The select to
sleep every second is a massive hack, and I've tried different values of
sleep - ultimately I'd want it to be a proper asynchronous application.
As far as I can see using the send and recv I've attached things get as
far as completing the AMQP negotiation, but the actual message isn't
being sent and it *looks like* something to do with credit.
I've hacked around in proton "instrumenting" it - OK I've added a bunch
of printfs :-)
Hands up who knows that code best? fancy volunteering to document the
call graph, trying to work my way around that made my *head explode* ;-D
I'm sure it's easy when you know, but trying to figure the path of the
actual message.........
I *think* that there's some sort of "store" where pn_messenger_put
actually puts the message and at some point the message should be
retrieved from there by the transport.
Looking through transport.c I've added printfs to
"pn_output_write_amqp_header" and "pn_output_write_amqp" and can see
those getting called and pn_process(transport) seems to be getting
called too.
Looking at where I'm at; the message is being put into the store
pn_messenger_put
calling pn_buffer_append 93
0 83 112 -48 0 0 0 11 0 0 0 5 66 80 4 64 66 82 0 0 83 115 -48 0 0 0 49 0
0 0 13 64 64 -95 14 97 109 113 112 58 47 47 48 46 48 46 48 46 48 64 64
64 64 64 -125 0 0 0 0 0 0 0 0 -125 0 0 0 0 0 0 0 0 64 82 0 64 0 83 119
-95 12 72 101 108 108 111 32 87 111 114 108 100 33
So that's the "Hello World!" at the end of the buffer :-) but when I
print out the values needed for the test in pn_process_tpwork_sender I
keep getting:
pn_process_tpwork_sender state->sent = 0 delivery->done = 1 93
ssn_state->remote_incoming_window = 0
link_state->link_credit = 0
This *seems* to be saying that the message is still in the store but
remote_incoming_window and link_credit are zero. That basically prints
out every time I call pn_messenger_work(messenger, 0);
There's clearly something I'm missing? There wasn't anything in the
synchronous send/recv that explicitly set credits though? I've spent
most of the weekend tearing my hair out on this, so I'd be grateful for
any ideas.
You're correct - it does come down to credit. In your recv.c code, the
main_loop needs to supply a credit count to the pn_messenger_recv() call:
// XXX pn_messenger_recv(messenger, 0);
pn_messenger_recv(messenger, 1);
This will cause the receiver to send a "flow" frame.
All in all, your code is pretty close - I've made a few tweaks (attached). I
think the big difference is the call to pn_messenger_work() on the sender -
you need to call that until the outgoing message has been sent
(pn_messenger_outgoing() == 0).
And from what I can tell - again, not documented - you need to keep calling
pn_messenger_work() until it returns a non-zero value. This is inconsistent
with the Java variant (which returns 0 when there's no more work to do) -
I've got a proposed fix pending (https://reviews.apache.org/r/15458/diff/#5)
for 0.6.
As you've noticed the docs tend to not keep up with the code changes, and
that makes things difficult to understand. Usually the header files are
more up to date. Personally, I've learned most from reading the python unit
tests (tests/python/proton_tests/*).
I was serious about the call graph documentation BTW, being pretty new
to the code base it was pretty daunting following the various levels of
indirection and I'm still nowhere near actually understanding how it
works, how do you guys find your way around when it comes to debugging -
is it just experience or are you using other debug tools?
Cheers,
Frase
BTW, if you set an environment variable called "PN_TRACE_FRM" to one:
$ export PN_TRACE_FRM=1
proton will dump a trace of the traffic "on the wire" when you run your
programs. Doing that, I could see that the code was getting "stuck" at the
point where I would think recv should issue a flow frame.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
