You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Alan Conway (JIRA)" <qp...@incubator.apache.org> on 2007/01/18 15:37:29 UTC
[jira] Created: (QPID-304) qpidd --daemon should not return until
broker has started.
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
[jira] Commented: (QPID-304) qpidd --daemon should not return until
broker has started.
Posted by "Alan Conway (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492736 ]
Alan Conway commented on QPID-304:
----------------------------------
Fixed on M2 branch r533819.
> 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
> Affects Versions: M1
> Reporter: Alan Conway
> Assigned To: Alan Conway
> Fix For: M2
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-304) qpidd --daemon should not return until
broker has started.
Posted by "Alan Conway (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alan Conway updated QPID-304:
-----------------------------
Affects Version/s: M2
> 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
> Affects Versions: M2
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (QPID-304) qpidd --daemon should not return until
broker has started.
Posted by "Alan Conway (JIRA)" <qp...@incubator.apache.org>.
[ 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 <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.
> 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
[jira] Resolved: (QPID-304) qpidd --daemon should not return until
broker has started.
Posted by "Alan Conway (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alan Conway resolved QPID-304.
------------------------------
Resolution: Fixed
Merged to trunk.
> 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
> Affects Versions: M1
> Reporter: Alan Conway
> Assigned To: Alan Conway
> Fix For: M2
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (QPID-304) qpidd --daemon should not return until
broker has started.
Posted by "Alan Conway (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alan Conway reassigned QPID-304:
--------------------------------
Assignee: Alan Conway
> 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
> Affects Versions: M1
> Reporter: Alan Conway
> Assigned To: Alan Conway
> Fix For: M2
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-304) qpidd --daemon should not return until
broker has started.
Posted by "Alan Conway (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alan Conway updated QPID-304:
-----------------------------
Fix Version/s: M2
Affects Version/s: (was: M2)
M1
> 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
> Affects Versions: M1
> Reporter: Alan Conway
> Fix For: M2
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.