Bill Shannon wrote:
> Is Hudson just making sure *it* doesn't allocate those ports for any
> other jobs?
>
> Or does it actually make sure no other processes on that machine are
> using those ports? And even if it does, there's nothing preventing
> a non-Hudson job from using those ports between when Hudson allocates
> them to your job, and when your job starts using them.
>
Thank for pointing this out.
Hudson checks if no two jobs are using the same port on the same node
concurrently. So if the process is not a Hudson job and it's
allocating a port used in the Hudson job, this will not be detected.
See Hudson documentation on "Assign unique TCP ports to avoid collisions":
This feature also allows jobs to require a certain fixed port. For
example, if your job is testing a mail server, where you'd require port
25 and no other ports would do, then simply add 25 as the name, so that
Hudson can make sure that no two jobs that require the same port will
run on the same node concurrently.
Can the test scripts be enhanced to check for an available port?
Jane
>
> Jane Young wrote on 06/11/10 04:05 PM:
>> A bug in Hudson?
>> File the bug here: http://issues.hudson-ci.org/secure/Dashboard.jspa
>>
>> Justin Lee wrote:
>>> We have those jobs configured to do that already, actually, which is
>>> why the port conflicts are so surprising.
>>>
>>> On 6/11/10 6:49 PM, Jane Young wrote:
>>>> Justin,
>>>>
>>>> You can configure Hudson job to allocate port number for a specified
>>>> variable or reserve the port number while it is running so it will
>>>> block other builds when port is in-use. This will help resolve port
>>>> conflicts test failures.
>>>>
>>>> Please take a look at the "Build Environment" section of the job
>>>> configuration. There is a checkbox: "Assign unique TCP ports to avoid
>>>> collisions".
>>>>
>>>> HTH,
>>>> Jane
>>>>
>>>>
>>>> Justin Lee wrote:
>>>>> I've seen a lot of test failures on hudson lately because of ports
>>>>> being in use by other processes. Is anyone else seeing those
>>>>> failures? Are the zombie processes we need to clean out? I see this
>>>>> especially on gerald and pigalle on the latest Grizzly_Integration
>>>>> and webtier-dev-tests-v3-source jobs.
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>