I would suggest favouring a range of ports - possibly trying one at a time, bind(0) has the chance of stuffing other perfectly honourable daemons (if that isn't an oxymoron! :o) Of course, in turn the range could be configurable from 0 thru 64K if necessary.
M On 6/5/07, John O'Hara (JIRA) <[email protected]> wrote:
[ https://issues.apache.org/jira/browse/QPID-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12501563] John O'Hara commented on QPID-504: ---------------------------------- I've not run the C qpidd (shame on me); is it in the tradition of a 100% silent daemon, or does it print startup messages? If the latter, it could always print out the port number in the same place everytime....along with other pertinent info like version numbers and whether or not the server is running with default security. Both the C and Java brokers should behave in the same way and accept the same command line options (where that makes sense). Thoughts? John > Dynamic port for automated tests. > --------------------------------- > > Key: QPID-504 > URL: https://issues.apache.org/jira/browse/QPID-504 > Project: Qpid > Issue Type: Test > Components: C++ Broker > Reporter: Alan Conway > > As development ramps up we will have multiple qpid builds on the same machine clashing for use of the AMQP default port. > All automated tests should use a *dynamically assigned* (i.e. bind(0)) port. > Allowing a manually specified port number for tests doesn't solve the problem as there's no way to choose > a port that is guaranteed not to be used by any other test on the same host. > One way to do this: > - add qpidd --print-port option to print the actual bound port > - add qpid option processing to qpid client library, enable in all test programs. > - test harness does "qpidd --daemon --port 0 --print-port" and sets the printed port to QPID_PORT in env for all test clients. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
