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.
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
>