All right,
I looked into this further and I guess I found a better solution.
Basically the server needs to be setup once for all the [Test]
methods. [SetUp] SetUp() and [TearDown] TearDown() will "bracket" each
call to a [Test] method. So I dropped those altogether. Instead I have
these:
[TestFixtureSetUp]
public void FixtureSetup()
{
if (!serverStarted)
{
Random rnd = new
Random((int)(DateTime.Now.Ticks & 0x7fffffff));
port = rnd.Next(System.Net.IPEndPoint.MinPort,
System.Net.IPEndPoint.MaxPort);
Console.WriteLine("Port " + port);
httpChannel = new
System.Runtime.Remoting.Channels.Http.HttpChannel(port);
StartServer();
}
}
[TestFixtureTearDown]
public void FixtureTeardown()
{
try
{
System.Runtime.Remoting.Channels.ChannelServices.UnregisterChannel(httpChannel);
}
catch
{
}
httpChannel = null;
}
[TestFixtureSetUp] and [TestFixtureTearDown] methods are called only
once and "bracket" the [TestFixutre] class. So the server gets setup,
then all the [Test] methods are run, and the we do
UnregisterChannel().
I ran the test a whole bunch of times without a single failure.
What do you say?
tjk :)
P.S. HttpChannel() does not automatically get an available port. :(
On Mon, Jan 12, 2009 at 4:36 PM, Digy <digyd...@gmail.com> wrote:
> Hi Ben,
> You are right, but it is still possible to choose a free port rather that a
> random port which may be in use.
>
> DIGY.
>
> -----Original Message-----
> From: Ben Martz [mailto:benma...@gmail.com]
> Sent: Monday, January 12, 2009 11:57 PM
> To: lucene-net-dev@incubator.apache.org
> Subject: Re: TestRemoteSearchable and random port
>
> Hi DIGY,
>
> That's what I thought at first as well until I realized that the SetUp
> method is explicitly choosing a random port number each time its called. If
> it wasn't for the random port numbering I would perhaps suggest an explicit
> call to UnregisterChannel.
>
> Cheers,
> Ben
>
> On Mon, Jan 12, 2009 at 1:51 PM, Digy <digyd...@gmail.com> wrote:
>
>> Hi TJ,
>>
>> You can open an issue on JIRA
>> (https://issues.apache.org/jira/browse/LUCENENET) and submit your patches.
>> But as far as I can see, your patch reduces the probability of a port
>> conflict but does not solve the real problem. I think, the real problem
>> lies
>> in some previously running test cases not closing the ports appropriately.
>>
>> DIGY
>>
>>
> --
> 13:37 - Someone stole the precinct toilet. The cops have nothing to go on.
> 14:37 - Officers dispatched to a daycare where a three-year-old was
> resisting a rest.
> 21:11 - Hole found in nudist camp wall. Officers are looking into it.
>
>
