Re: FYI, bdbstore: Instrument all tests so that they are run via valgrind

[Alan Conway <ac...@redhat.com>]

On Tue, 2007-01-16 at 11:29 -0500, Alan Conway wrote:

> Waiting for startup is a classic problem, we need a good general
> solution. How about 
> qpidd --waitforbroker <timeout>
>   Attempt to contact the broker for up to <timeout> seconds. Exit status
> 0 if the broker was contacted, 1 if the timeout expired.

A better solution: have qpidd --daemon itself wait until it has started
successfully! We could create a shared semaphore or somesuch before we
fork the daemon, and have the daemon process signal when it has
successfully called accept(). That way you can always safely start a
client immediately after starting qpidd --daemon. 

Any snags with that?

Cheers,
Alan.

Re: FYI, bdbstore: Instrument all tests so that they are run via valgrind

[Alan Conway <ac...@redhat.com>]

On Wed, 2007-01-17 at 22:45 +0100, Jim Meyering wrote:
> Alan Conway <ac...@redhat.com> wrote:
> > On Tue, 2007-01-16 at 11:29 -0500, Alan Conway wrote:
> >> Waiting for startup is a classic problem, we need a good general
> >> solution. How about
> >> qpidd --waitforbroker <timeout>
> >>   Attempt to contact the broker for up to <timeout> seconds. Exit status
> >> 0 if the broker was contacted, 1 if the timeout expired.
> >
> > A better solution: have qpidd --daemon itself wait until it has started
> > successfully! We could create a shared semaphore or somesuch before we
> > fork the daemon, and have the daemon process signal when it has
> > successfully called accept(). That way you can always safely start a
> > client immediately after starting qpidd --daemon.
> 
> I prefer the former, since it would be useful not just at start-up --
> e.g., also to test whether a broker (or something) is listening on the
> specified port at any later time.

Good point. How about this:

1. qpidd --check <timeout> [--port x] will try to connect to port x and
verify a basic AMQP handshake. It will retry up to <timeout> seconds. It
will return status 0 if it succeeds 1 otherwise.

2. qpidd --daemon=<timeout> will fork a background daemon and then do
the equivalent of qpidd --check<timeout> in the foreground process.
qpidd --daemon uses a default timeout of 30 seconds.

So qpidd --daemon will automatically self-check, qpidd --check lets you
test for a daemon without starting one.

I like it, will update JIRA.

Re: FYI, bdbstore: Instrument all tests so that they are run via valgrind

[Jim Meyering <ji...@meyering.net>]

Alan Conway <ac...@redhat.com> wrote:
> On Tue, 2007-01-16 at 11:29 -0500, Alan Conway wrote:
>> Waiting for startup is a classic problem, we need a good general
>> solution. How about
>> qpidd --waitforbroker <timeout>
>>   Attempt to contact the broker for up to <timeout> seconds. Exit status
>> 0 if the broker was contacted, 1 if the timeout expired.
>
> A better solution: have qpidd --daemon itself wait until it has started
> successfully! We could create a shared semaphore or somesuch before we
> fork the daemon, and have the daemon process signal when it has
> successfully called accept(). That way you can always safely start a
> client immediately after starting qpidd --daemon.

I prefer the former, since it would be useful not just at start-up --
e.g., also to test whether a broker (or something) is listening on the
specified port at any later time.