qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan Conway (JIRA)" <qpid-...@incubator.apache.org>
Subject [jira] Commented: (QPID-304) qpidd --daemon should not return until broker has started.
Date Fri, 19 Jan 2007 20:09:30 GMT

    [ https://issues.apache.org/jira/browse/QPID-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466138
] 

Alan Conway commented on QPID-304:
----------------------------------

On Wed, 2007-01-17 at 22:45 +0100, Jim Meyering wrote:
> Alan Conway <aconway@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.




> qpidd --daemon should not return until broker has started.
> ----------------------------------------------------------
>
>                 Key: QPID-304
>                 URL: https://issues.apache.org/jira/browse/QPID-304
>             Project: Qpid
>          Issue Type: Bug
>          Components: C++ Broker
>            Reporter: Alan Conway
>
> Running qpidd --daemon followed immediately by a client sometimes fails becaue the background
qpidd has not yet started accept()ing connections.
> To fix this the, foreground qpidd process (which forks the background one with --daemon)
 should not return until the background qpidd is accepting connections.
> There are several ways to implement this. One is for the foreground qpidd to set up some
inter-process communication (pipe, semaphore, whatever) and wait to be notified, the background
qpidd would notify after calling accept() . Alternatively the foreground qpidd could repeatedly
try to connect until it is succssful.
> Whatever the approach be careful that the foreground qpidd returns with zero status only
if the background daemon starts listening, and returns with non-zero exit status if the background
 process fails for any reason. Under no circumstance should the foreground process hang forever.
If the background qpidd does not start accepting within some reasonable delay (a minute or
so) the foreground process should kill it and return non-zero status.
> Once implemented, go thru all tests and remove arbitrary sleeps introduced to work around
this problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message