You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by TJ Kolev <tj...@gmail.com> on 2009/01/12 22:12:47 UTC
TestRemoteSearchable and random port
Hello!
I was getting sporadic (more often then not) port conflicts on this
unit test (/Test/Search/TestRemoteSearchable.cs). I rewrote the test a
bit, and I have not had problems since. If this looks good, how do I
submit the patch?
tjk :)
Index: TestRemoteSearchable.cs
===================================================================
--- TestRemoteSearchable.cs (revision 732813)
+++ TestRemoteSearchable.cs (working copy)
@@ -16,7 +16,7 @@
*/
using System;
-
+using System.Net.Sockets;
using NUnit.Framework;
using Lucene.Net.Documents;
@@ -38,13 +38,29 @@
private static int port;
private static bool serverStarted;
+ private const int MAX_PORT_TRIES = 10;
+
[SetUp]
public override void SetUp()
{
base.SetUp();
Random rnd = new Random((int)(DateTime.Now.Ticks & 0x7fffffff));
- port = rnd.Next(System.Net.IPEndPoint.MinPort,
System.Net.IPEndPoint.MaxPort);
- httpChannel = new System.Runtime.Remoting.Channels.Http.HttpChannel(port);
+
+ int portTry = 0;
+ while (true)
+ {
+ try
+ {
+ port = rnd.Next(System.Net.IPEndPoint.MinPort,
System.Net.IPEndPoint.MaxPort);
+ httpChannel = new System.Runtime.Remoting.Channels.Http.HttpChannel(port);
+ break;
+ }
+ catch (SocketException)
+ {
+ if (++portTry > MAX_PORT_TRIES)
+ throw;
+ }
+ }
if (!serverStarted)
StartServer();
}
Re: TestRemoteSearchable and random port
Posted by Ben Martz <be...@gmail.com>.
I seem to recall that most methods that open endpoints have the option to
pass 0 as the port number and have the stack assign an available port to
you. Have you tried that with the HttpChannel constructor instead of just
choosing a random number? You could then save the value of port after the
channel is constructed. I don't know for sure if this is applicable to
HttpChannel or not but retry loops always make me nervous for some reason
and it may be a valid solution. Sorry I don't have time to look it up right
now.
Cheers,
Ben
On Mon, Jan 12, 2009 at 1:12 PM, TJ Kolev <tj...@gmail.com> wrote:
> Hello!
>
> I was getting sporadic (more often then not) port conflicts on this
> unit test (/Test/Search/TestRemoteSearchable.cs). I rewrote the test a
> bit, and I have not had problems since. If this looks good, how do I
> submit the patch?
>
> tjk :)
>
> Index: TestRemoteSearchable.cs
> ===================================================================
> --- TestRemoteSearchable.cs (revision 732813)
> +++ TestRemoteSearchable.cs (working copy)
> @@ -16,7 +16,7 @@
> */
>
> using System;
> -
> +using System.Net.Sockets;
> using NUnit.Framework;
>
> using Lucene.Net.Documents;
> @@ -38,13 +38,29 @@
> private static int port;
> private static bool serverStarted;
>
> + private const int MAX_PORT_TRIES = 10;
> +
> [SetUp]
> public override void SetUp()
> {
> base.SetUp();
> Random rnd = new Random((int)(DateTime.Now.Ticks &
> 0x7fffffff));
> - port = rnd.Next(System.Net.IPEndPoint.MinPort,
> System.Net.IPEndPoint.MaxPort);
> - httpChannel = new
> System.Runtime.Remoting.Channels.Http.HttpChannel(port);
> +
> + int portTry = 0;
> + while (true)
> + {
> + try
> + {
> + port =
> rnd.Next(System.Net.IPEndPoint.MinPort,
> System.Net.IPEndPoint.MaxPort);
> + httpChannel = new
> System.Runtime.Remoting.Channels.Http.HttpChannel(port);
> + break;
> + }
> + catch (SocketException)
> + {
> + if (++portTry > MAX_PORT_TRIES)
> + throw;
> + }
> + }
> if (!serverStarted)
> StartServer();
> }
>
--
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.
Re: TestRemoteSearchable and random port
Posted by Ben Martz <be...@gmail.com>.
I'm glad that worked out, TJ. Sorry that my original post was unclear.
Thanks for tackling the issue!
On Mon, Jan 12, 2009 at 6:31 PM, TJ Kolev <tj...@gmail.com> wrote:
> I just finished trying HttpChannel(0) :) I initially misread Ben's
> suggestion and he and you are correct: HttpChannel(0) does give you an
> available port. The HttpChannel() I used is of not much use.
>
> Another improvement I found while testing. The port variable is not
> needed (unless we decide to report on it). This works instead:
>
> private static Lucene.Net.Search.Searchable LookupRemote()
> {
> //return
> (Lucene.Net.Search.Searchable)Activator.GetObject(typeof(Lucene.Net.Search.Searchable),
> string.Format("http://localhost:{0}/RemoteSearchable", port));
>
> return
> (Lucene.Net.Search.Searchable)Activator.GetObject(typeof(Lucene.Net.Search.Searchable),
> httpChannel.GetUrlsForUri("RemoteSearchable")[0]);
> }
>
>
> I will make a jira and attach a patch.
>
> tjk :)
>
>
--
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.
Re: TestRemoteSearchable and random port
Posted by TJ Kolev <tj...@gmail.com>.
I just finished trying HttpChannel(0) :) I initially misread Ben's
suggestion and he and you are correct: HttpChannel(0) does give you an
available port. The HttpChannel() I used is of not much use.
Another improvement I found while testing. The port variable is not
needed (unless we decide to report on it). This works instead:
private static Lucene.Net.Search.Searchable LookupRemote()
{
//return (Lucene.Net.Search.Searchable)Activator.GetObject(typeof(Lucene.Net.Search.Searchable),
string.Format("http://localhost:{0}/RemoteSearchable", port));
return (Lucene.Net.Search.Searchable)Activator.GetObject(typeof(Lucene.Net.Search.Searchable),
httpChannel.GetUrlsForUri("RemoteSearchable")[0]);
}
I will make a jira and attach a patch.
tjk :)
On Mon, Jan 12, 2009 at 5:22 PM, Digy <di...@gmail.com> wrote:
> 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:tjkolev@gmail.com]
> Sent: Tuesday, January 13, 2009 12:55 AM
> To: lucene-net-dev@incubator.apache.org
> 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 <di...@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:benmartz@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 <di...@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.
>>
>>
>
>
RE: TestRemoteSearchable and random port
Posted by Digy <di...@gmail.com>.
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:tjkolev@gmail.com]
Sent: Tuesday, January 13, 2009 12:55 AM
To: lucene-net-dev@incubator.apache.org
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 <di...@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:benmartz@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 <di...@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.
>
>
Re: TestRemoteSearchable and random port
Posted by Jokin Cuadrado <jo...@gmail.com>.
just to make a note, previous revision of the test suite have a
static port chosen instead of a random port. The problem with that
was that UnregisterChannel doesn't free the resources synchronously.
for example from:
http://social.msdn.microsoft.com/Forums/en-US/netfxremoting/thread/04b543b0-1569-430b-ad9b-16f468627ede/
"Hi folks, Unregistering the service doesn't force a synchronous
freeing of resources; instead, it marks the underlying structures as
"available for cleanup". Given that, the actual timing of the cleanup
will vary depending on system load, number of processors, etc. If
you're going to be repeatedly stopping a and starting a service you'll
need to 1) wait a few seconds before you startup and 2) if you see the
SocketException, catch it, wait, and retry (a finite number of times
in case you have a non-transient problem)."
On Mon, Jan 12, 2009 at 11:55 PM, TJ Kolev <tj...@gmail.com> wrote:
> 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 <di...@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:benmartz@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 <di...@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.
>>
>>
>
Re: TestRemoteSearchable and random port
Posted by TJ Kolev <tj...@gmail.com>.
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 <di...@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:benmartz@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 <di...@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.
>
>
RE: TestRemoteSearchable and random port
Posted by Digy <di...@gmail.com>.
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:benmartz@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 <di...@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.
Re: TestRemoteSearchable and random port
Posted by Ben Martz <be...@gmail.com>.
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 <di...@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.
RE: TestRemoteSearchable and random port
Posted by Digy <di...@gmail.com>.
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
-----Original Message-----
From: TJ Kolev [mailto:tjkolev@gmail.com]
Sent: Monday, January 12, 2009 11:13 PM
To: lucene-net-dev@incubator.apache.org
Subject: TestRemoteSearchable and random port
Hello!
I was getting sporadic (more often then not) port conflicts on this
unit test (/Test/Search/TestRemoteSearchable.cs). I rewrote the test a
bit, and I have not had problems since. If this looks good, how do I
submit the patch?
tjk :)
Index: TestRemoteSearchable.cs
===================================================================
--- TestRemoteSearchable.cs (revision 732813)
+++ TestRemoteSearchable.cs (working copy)
@@ -16,7 +16,7 @@
*/
using System;
-
+using System.Net.Sockets;
using NUnit.Framework;
using Lucene.Net.Documents;
@@ -38,13 +38,29 @@
private static int port;
private static bool serverStarted;
+ private const int MAX_PORT_TRIES = 10;
+
[SetUp]
public override void SetUp()
{
base.SetUp();
Random rnd = new Random((int)(DateTime.Now.Ticks &
0x7fffffff));
- port = rnd.Next(System.Net.IPEndPoint.MinPort,
System.Net.IPEndPoint.MaxPort);
- httpChannel = new
System.Runtime.Remoting.Channels.Http.HttpChannel(port);
+
+ int portTry = 0;
+ while (true)
+ {
+ try
+ {
+ port =
rnd.Next(System.Net.IPEndPoint.MinPort,
System.Net.IPEndPoint.MaxPort);
+ httpChannel = new
System.Runtime.Remoting.Channels.Http.HttpChannel(port);
+ break;
+ }
+ catch (SocketException)
+ {
+ if (++portTry > MAX_PORT_TRIES)
+ throw;
+ }
+ }
if (!serverStarted)
StartServer();
}