On Tue, Feb 26, 2013 at 8:02 AM, Alan Conway <[email protected]> wrote:
> This is a good start! We should start a proton book so this has a place > to live. The Qpid books are in docbook under qpid/doc/book. I'm not a > huge fan of docbook but probably best to stick with it unless there's > something significantly better. > > A few comments on the content: > > On Fri, 2013-02-22 at 05:14 -0500, Michael Goulish wrote: > [snip] > > > > You can also grant 'infinite' credit by using a negative > > value as the second arg to pn_messenger_recv(). This will > > have the effect of granting 10 units of credit to every link > > on that call to pn_messenger_recv(). > > Typo, "10 units of" should be "infinite". > I wouldn't say it's infinite, it's just an unspecified amount. The implementation will attempt to manage an optimal bound based on the assumption that you will be receiving messages indefinitely. > > A single messenger, listening on a single port, may have > > many incoming links. > > Clarify - is the credit per-link or per-messenger? Also move this out of > the "infinite credit" section, it doesn't apply only to infinite credit. > Also, a single messenger may have many incoming links regardless of whether it is listening on a single port, many ports, or no ports at all. > > According to API docs recv(self, n) > > Receives up to n messages into the incoming queue of the > Messenger. This method will block until at least one message is > available or the operation times out. > > So it sounds like credit is per messenger, so it is incorrect to say > that recv "grants N units of credit to every link." > > > Credit does not drain > > -------------------------- > > > > Once granted by a call to pn_messenger_recv(), unusued credit > > on a link does not go away when control returns from > > pn_messenger_recv(). It remains at the link, and successive > > calls can increase it. > > Successive calls to what? > > Can I control the credit per link? messenger_recv sets it globally for > the messenger. What happens if I call messenger_recv again - does the > credit get reset on existing Links, or does it apply only to new links. > > Presumably credit get used up as messages arrive. Need to discuss that > and also when/how "used" credit gets "unused" - is it at > pn_messenger_get or is it delayed till the user acknowledges the > message. (How do you acknowledge a message in proton? I couldn't find > anything obvious in the API doc. The semantics of pn_messenger_recv is intended to match exactly a typical blocking read call you make to do file or socket I/O. Calling read(n) will block until at least one byte of data is available and return no more than n bytes. Likewise, calling pn_messenger_recv(n) will block until at least one message is available and it will never receive more than n messages. I don't actually know if the implementation behaves this way (I suspect it doesn't) as it depends on properly implementing drain and early on not everyone did that (including messenger itself), so it isn't a code path that's been tested much. --Rafael
