Mailing-List: contact lucene-net-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: lucene-net-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of tjkolev@gmail.com designates
 209.85.134.185 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=aDOUU0t0ClOQnzStFU6WjtX4Ryp1pyHTsSlyOlCY6ZUGj5IJ+DWrJC5oIRlPvdaJUY
         q64+Ruy8qDWt8/Ku9VEDREZASPlvDoyBm3RHThityhAhMnpVy6VlV0nrirWArGRsIopC
         a7QdoYgyAv65KAf4viO/TuJv7lKlTxv4TPutY=
Message-ID: <743c5bb40901121831j7a0e94d4m197a52a0016479c6@mail.gmail.com>
Date: Mon, 12 Jan 2009 20:31:38 -0600
From: "TJ Kolev" <tjkolev@gmail.com>
To: lucene-net-dev@incubator.apache.org
Subject: Re: TestRemoteSearchable and random port
In-Reply-To: <003801c9750c$af57bd30$0e073790$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <743c5bb40901121312i235ccffch990142ab7baaf8eb@mail.gmail.com>
	 <002a01c974ff$ded085e0$9c7191a0$@com>
	 <380bd16a0901121357k32382716v95bd685185e38432@mail.gmail.com>
	 <003401c97506$2cc26240$864726c0$@com>
	 <743c5bb40901121455y35c3635etdf3c49d0936b2c01@mail.gmail.com>
	 <003801c9750c$af57bd30$0e073790$@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 <digydigy@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 <digydigy@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 <digydigy@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.
>>
>>
>
>