[
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 <[EMAIL PROTECTED]> 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
