You are viewing a plain text version of this content. The canonical link for it is here.
Posted to proton@qpid.apache.org by aconway <ac...@redhat.com> on 2015/10/09 21:25:37 UTC
PN_REACTOR_QUIESCED
I'm fiddling with the C++ example broker, and when I install a debug
handler, I see that when the broker is doing absolutely nothing there
is a PN_REACTOR_QUIESCED event about every 3 seconds. Does anybody know
what this is about? Why is the reactor waking up just to tell us that
it is asleep?
Cheers,
Alan.
Re: PN_REACTOR_QUIESCED
Posted by aconway <ac...@redhat.com>.
On Wed, 2015-10-14 at 10:31 -0400, Rafael Schloming wrote:
> It wasn't actually an accidental commit. If I recall correctly I
> ended up
> using it more like a 0xDEADBEEF value. It makes it easy to
> distinguish
> between the failure mode of an actual hang (e.g. infinite loop or
> blocking
> call inside a handler) vs reaching a state where there are simply no
> more
> events to process. I guess you can think of it like a heartbeat in a
> way.
>
It seems like an odd default. Can we make it 0 in the code and set it
non-0 in tests if that is needed? Randomly waking up a user app that
hasn't asked for heartbeats every sort-of-3-seconds is a surprising
behavior.
> --Rafael
>
> On Tue, Oct 13, 2015 at 10:56 AM, Michael Goulish <
> mgoulish@redhat.com>
> wrote:
>
> >
> > But it's obvious how this constant was chosen.
> >
> > With circular reasoning.
> >
> > <rimshot/>
> >
> >
> >
> > ----- Original Message -----
> > > On Mon, 2015-10-12 at 16:05 -0400, aconway wrote:
> > > > ...
> > > > +1, that looks like the right fix. 3141 is an odd choice of
> > > > default,
> > > > even for a mathematician.
> > > >
> > >
> > > At this point, I'm desperately trying to find an appropriate pi
> > > joke :
> > > -)
> > >
> > > Andrew
> > >
> > >
> >
Re: PN_REACTOR_QUIESCED
Posted by Rafael Schloming <rh...@alum.mit.edu>.
It wasn't actually an accidental commit. If I recall correctly I ended up
using it more like a 0xDEADBEEF value. It makes it easy to distinguish
between the failure mode of an actual hang (e.g. infinite loop or blocking
call inside a handler) vs reaching a state where there are simply no more
events to process. I guess you can think of it like a heartbeat in a way.
--Rafael
On Tue, Oct 13, 2015 at 10:56 AM, Michael Goulish <mg...@redhat.com>
wrote:
>
> But it's obvious how this constant was chosen.
>
> With circular reasoning.
>
> <rimshot/>
>
>
>
> ----- Original Message -----
> > On Mon, 2015-10-12 at 16:05 -0400, aconway wrote:
> > > ...
> > > +1, that looks like the right fix. 3141 is an odd choice of default,
> > > even for a mathematician.
> > >
> >
> > At this point, I'm desperately trying to find an appropriate pi joke :
> > -)
> >
> > Andrew
> >
> >
>
Re: PN_REACTOR_QUIESCED
Posted by Michael Goulish <mg...@redhat.com>.
But it's obvious how this constant was chosen.
With circular reasoning.
<rimshot/>
----- Original Message -----
> On Mon, 2015-10-12 at 16:05 -0400, aconway wrote:
> > ...
> > +1, that looks like the right fix. 3141 is an odd choice of default,
> > even for a mathematician.
> >
>
> At this point, I'm desperately trying to find an appropriate pi joke :
> -)
>
> Andrew
>
>
Re: PN_REACTOR_QUIESCED
Posted by Andrew Stitcher <as...@redhat.com>.
On Mon, 2015-10-12 at 16:05 -0400, aconway wrote:
> ...
> +1, that looks like the right fix. 3141 is an odd choice of default,
> even for a mathematician.
>
At this point, I'm desperately trying to find an appropriate pi joke :
-)
Andrew
Re: PN_REACTOR_QUIESCED
Posted by aconway <ac...@redhat.com>.
On Sat, 2015-10-10 at 10:57 +0200, Bozo Dragojevic wrote:
> Hi Alan, Rafael,
>
> On 9. 10. 15 21.25, aconway wrote:
> > I'm fiddling with the C++ example broker, and when I install a
> > debug
> > handler, I see that when the broker is doing absolutely nothing
> > there
> > is a PN_REACTOR_QUIESCED event about every 3 seconds. Does anybody
> > know
> > what this is about? Why is the reactor waking up just to tell us
> > that
> > it is asleep?
> >
> >
>
> On first sight seems like a debug thing accidentally committed.
>
> I think something like this is in order:
>
> $ git diff
> diff --git a/proton-c/src/reactor/reactor.c b/proton
> -c/src/reactor/reactor.c
> index 6b328bc..7542d4c 100644
> --- a/proton-c/src/reactor/reactor.c
> +++ b/proton-c/src/reactor/reactor.c
> @@ -484,7 +484,6 @@ void pn_reactor_stop(pn_reactor_t *reactor) {
>
> void pn_reactor_run(pn_reactor_t *reactor) {
> assert(reactor);
> - pn_reactor_set_timeout(reactor, 3141);
> pn_reactor_start(reactor);
> while (pn_reactor_process(reactor)) {}
> pn_reactor_stop(reactor);
>
> workaround is to pn_set_reactor_timeout(r, 0) in PN_REACTOR_INIT in
> your
> broker.
+1, that looks like the right fix. 3141 is an odd choice of default,
even for a mathematician.
Re: PN_REACTOR_QUIESCED
Posted by Bozo Dragojevic <bo...@digiverse.si>.
Hi Alan, Rafael,
On 9. 10. 15 21.25, aconway wrote:
> I'm fiddling with the C++ example broker, and when I install a debug
> handler, I see that when the broker is doing absolutely nothing there
> is a PN_REACTOR_QUIESCED event about every 3 seconds. Does anybody know
> what this is about? Why is the reactor waking up just to tell us that
> it is asleep?
>
>
On first sight seems like a debug thing accidentally committed.
I think something like this is in order:
$ git diff
diff --git a/proton-c/src/reactor/reactor.c b/proton-c/src/reactor/reactor.c
index 6b328bc..7542d4c 100644
--- a/proton-c/src/reactor/reactor.c
+++ b/proton-c/src/reactor/reactor.c
@@ -484,7 +484,6 @@ void pn_reactor_stop(pn_reactor_t *reactor) {
void pn_reactor_run(pn_reactor_t *reactor) {
assert(reactor);
- pn_reactor_set_timeout(reactor, 3141);
pn_reactor_start(reactor);
while (pn_reactor_process(reactor)) {}
pn_reactor_stop(reactor);
workaround is to pn_set_reactor_timeout(r, 0) in PN_REACTOR_INIT in your
broker.
Bozzo