D'oh......
OK so I reread your notes around the async python code and noted:
"Also, the status is not updated when a message is settled without an
explicit disposition. I believe this is just a bug. The workaround is to
set a nonzero incoming window and explicitly accept/reject at the receiver."
that turned out to be more significant than I had realised (slaps head
very hard with back of hand......) adding
pn_messenger_set_outgoing_window(messenger, 1024);
pn_messenger_set_incoming_window(messenger, 1024);
made it work .......
would you perhaps be able to explain what's going on with respect to
"disposition" and "window" here? Am I correct in thinking that the
received message *should* be implicitly accepted? I've *no idea* what
the optimal window sizes would be so I copied your values.
I'm fairly familiar with the qpid::messaging setCapacity() stuff and how
that helps tune the internal queues, but I'm not clear at all how
messenger concepts map to the qpid::messaging/JMS stuff that I'm more
familiar with. I can see how to get the internal queue depth, but I'm
not clear if it's bounded or unbounded - is the window stuff the
equivalent of the sender/receiver setCapacity() or something else entirely?
I don't suppose that you have a "messenger for qpid::messaging
programmers" kick start guide do you :-D
As I get a bit more familiar I'd really like to understand how to get
the best performance out of this - though I'm probably a little way off
that at the moment - are there any plans to add "proton perftest" code
as a sort of canonical "here's how to make proton rock" guide? That'd be
*really* useful.
Anyway thanks yet again for all of your help, I'm definitely making
progress now.
Cheers,
Frase
On 15/12/13 18:40, Fraser Adams wrote:
Hi again Rafael,
really sorry to keep on at this one :-(
I seem to be having trouble with the tracker/status stuff now......
I got your python examples working, so I figured I'd try and go along
similar lines (using pn_messenger_work as the loop blocker for now
rather than my pn_messenger_wait just to rule out that as a potential
issue) so I've got:
while (1) {
//pn_messenger_wait(messenger, -1); // Block indefinitely until
there has been socket activity.
pn_messenger_work(messenger, -1); // Block indefinitely until
there has been socket activity.
process(NULL);
}
I've tried doing the explicit accept using a tracker but my
recv-async.c doesn't *seem* to be sending it??
I've tried my ./recv-async using your python send_async.py and I don't
end up in the ACCEPTED state :-(
similarly when I try ./recv_async.py and use my ./send-async my stuff
keeps reporting status = 0 which is PN_STATUS_UNKNOWN
<http://qpid.apache.org/releases/qpid-proton-0.5/protocol-engine/c/api/messenger_8h.html#a242e4ee54b9c0a416443c7da5f6e045ba0b46b1041679460baaba2ddcdb2173f2>
This is really starting to drive me nuts now. I must be doing
something stupid, but I can't see what.
The code I've attached is rather hacky as I've been trying to mess
around, but I'd be really grateful for any suggestions as to what I'm
doing wrong.
This is feeling a bit like voodoo at the moment :-D
Cheers.
Frase
On 13/12/13 18:40, Rafael Schloming wrote:
On Fri, Dec 13, 2013 at 12:54 PM, Fraser Adams <
[email protected]> wrote:
Hey Rafael,
many thanks again for your relies, I'll take a look at the python code.
For info in the branch that I'm doing my JavaScript stuff in I "pimped"
messenger.h and messenger.c slightly adding
PN_EXTERN int pn_messenger_wait(pn_messenger_t *messenger, int timeout);
to messenger.h and
int pn_messenger_wait(pn_messenger_t *messenger, int timeout)
{
return pn_driver_wait(messenger->driver, timeout);
}
to messenger.c
so my notifier now looks like:
while (1) {
pn_messenger_wait(messenger, -1); // Block indefinitely until there
has been socket activity.
main_loop(NULL);
}
And that works perfectly - yay :-)
Would you have any issues with that going forward as an interim step until
you're able to move forward with the fully decoupled driver?
Not at all. Please feel free.
--Rafael
