Closed
Bug 58176
Opened 24 years ago
Closed 22 years ago
Test servers such as selfserv should not bind to a fixed port.
Categories
(NSS :: Tools, enhancement, P2)
Tracking
(Not tracked)
RESOLVED
WONTFIX
4.0
People
(Reporter: wtc, Assigned: bishakhabanerjee)
Details
Test servers such as 'selfserv' should not bind to
a fixed port because this makes it impossible to
run two instances of a test server simultaneously
on the same machine.
A test server should try the next higher port if
a port is in use until the bind call succeeds.
Then it should write the port it is listening on
in a file so that the test clients know which
port to connect to. By the way, the test server
can also use this file to indicate that it has
started listening for connections and the test
script can start up the test clients.
Updated•24 years ago
|
Status: NEW → ASSIGNED
Reporter | ||
Updated•24 years ago
|
Target Milestone: --- → 3.3
Comment 1•24 years ago
|
||
I think you have fixed this behavior Nelson?
Assignee: sonmi → nelsonb
Status: ASSIGNED → NEW
Comment 2•24 years ago
|
||
This enhancement request is targeted at NSS 3.3
It was just assigned to me today, and has not yet been
implemented.
When the work in selfserv is done, I'll reassign this bug
back to you, Sonja, to make the associated changes to the
test scripts.
Severity: normal → enhancement
Status: NEW → ASSIGNED
Comment 3•24 years ago
|
||
Selfserv takes an optional argument that specifies the port number.
I suggest that when the port number is given, that is the number
that selfserv should use. When it is not given, selfserv could
take the next available port (like a client does) and report that
somehow (e.g. write it to a file).
Comment 4•24 years ago
|
||
What is the real benefit of the desired behavior, do we really need it? I will
certainly not use this feature for QA.
I thought some of the work that Nelson did on selfserver a long time ago fixed
what was really a problem, it is now possible to run 2 or more instances of
selfserver on one machine by specifying different portnumbers.
The added benefit that the selfserver can communicate over this file that it has
finished starting up is not needed, because we have the tstclnt -q for this purpose.
Comment 5•24 years ago
|
||
Sonja,
The point of Wan-Teh's enhancement request is to make it so that
there are never any accidental cases where two separate tests
are trying to use the same server port on the same server system.
The scheme we have now, which allows the port numbers to be
specified explicitly, still allows for occasional problems, e.g.
when an old server is still running on a port, and you attempt
to run a new server on that same port. We see this sort of
failure fairly frequently.
With Wan-Teh's proposal, the server would start up and select
an unused port number at random, and then put that port number
into a file where the script that started the server could
find it. The script would then use the port number from that
file in the commands that start the client(s).
Comment 6•24 years ago
|
||
OK, I didn't know that it is a frequent problem, I thought this enhancement was
mainly for the use of the QA scripts. I for my part would rather see an
errormessage if there is an old server hanging on the machine, especially if it
is one that a previous (or the current) QA run has started. I hope selfsrv -p
will not be changed.
The change to the QA script to read the file with the PORT information and -p it
to the testclient is trivial, but why I don't want to use it is:
How do I tell if QA doesn't kill the old selfservers properly?
What if two or more selfservers are started in the same directory (frequently
the case in QA) and they (or one of them) start hanging (or QA doesn't kill them
as expected)? Do they share one file? Or does QA need to look at the file
modification date?
I'd need to write new tests that test for hanging selfservers (right now the
tests just fail)
How will it work for Windows, I noticed there you can start multiple servers on
the same port and they don't fail?
Reporter | ||
Comment 8•23 years ago
|
||
Assigned the bug to Bishakha.
Assignee: nelsonb → bishakhabanerjee
Status: ASSIGNED → NEW
Priority: P3 → P2
Target Milestone: 3.4 → 4.0
Comment 9•23 years ago
|
||
I think it will interfere with QA as it currently is. I run 3 varieties of QA on
one machine on 3 different ports simultaneously, and it will take a lot more
than a small fix in the selfserv to make this work.
Reporter | ||
Comment 10•23 years ago
|
||
Changed the QA contact to Bishakha.
QA Contact: sonja.mirtitsch → bishakhabanerjee
Reporter | ||
Comment 11•22 years ago
|
||
Marked the bug WONTFIX. WONTFIX may not be the best
resolution of this RFE, so here is an explanation for
why I closed this RFE.
1. Allowing selfserv to use any unused port creates
problems for automated QA (described in comment #6).
2. I didn't realize that we could set the PORT environment
variable to specify the port used by our QA scripts.
Using the PORT environment variable allows multiple
simultaneous QA runs on the same machine, which is what
I need.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•