Hi TJ,
I haven't tested your code yet but it seems to be a good solution.
And,a sample code to create a HttpChannel with a free port:
httpChannel = new
System.Runtime.Remoting.Channels.Http.HttpChannel(0);
port =
Convert.ToInt32((httpChannel.GetUrlsForUri("")[0]).Split(new char[] { ':'
})[2].Replace("/", ""));
DIGY
-----Original Message-----
From: TJ Kolev [mailto:[email protected]]
Sent: Tuesday, January 13, 2009 12:55 AM
To: [email protected]
Subject: Re: TestRemoteSearchable and random port
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(httpChann
el);
}
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 <[email protected]> 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:[email protected]]
> Sent: Monday, January 12, 2009 11:57 PM
> To: [email protected]
> 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 <[email protected]> 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.
>
>
