On 20/06/2011 10:12 AM, oleksiys [via Grizzly] wrote:
> On 06/20/2011 03:53 PM, cowwoc wrote:
>>
>> I'm initializing the server with a PortRange(1, 65535):
>> final NetworkListener listener = new NetworkListener("grizzly",
>> host, new PortRange(1, 65535));
>>
>> I assume this guarantees that, although servers are presented
>> with the same range, no two servers will bind to the same port.
> Yes, it should work.
So how do we find out why the Filter is active when destroy() is
invoked? Is there anything we could log that would help us track this down?
>> PS: The documentation should probably indicate somewhere that port 0
>> is not allowed (and the code should prevent its use). If I recall
>> correctly, using port 0 causes the server to fail silently (you don't
>> get back an exception).
>
> Port 0 should work. May be it's what you might want to use. When you
> set 0 - it means you let OS to assign a port number.
> You can try the code bellow.
>
That's fine when the user specifies a single port, but it doesn't
make much sense for a PortRange, does it? :)
Thanks,
Gili
> WBR,
> Alexey.
>
> public static void main(String[] args) throws Exception {
> HttpServer httpServer = new HttpServer();
> final NetworkListener listener =
> new NetworkListener(LISTENER_NAME,
> NetworkListener.DEFAULT_NETWORK_HOST,
> 0);
>
> httpServer.addListener(listener);
> httpServer.getServerConfiguration().addHttpHandler(new
> PingHttpHandler());
> configureServer(httpServer);
>
> try {
> httpServer.start();
>
> System.out.println("TCP PORT=" +
> httpServer.getListener(LISTENER_NAME).getPort());
>
> System.out.println("Press enter to exit...");
> System.in.read();
> } catch (IOException e) {
> e.printStackTrace();
> } finally {
> httpServer.stop();
> }
> }
>
>>
>> Gili
>>
>> On 20/06/2011 9:46 AM, oleksiys [via Grizzly] wrote:
>>> Hi,
>>>
>>> how are you initializing the server? Is it possible they reuse the
>>> same TCP port?
>>>
>>> WBR,
>>> Alexey.
>>>
>>> On 06/20/2011 03:21 PM, cowwoc wrote:
>>>> Hi Oleksiys,
>>>>
>>>> I guess first of all I'm wondering why the Filter is in
>>>> mid-execution when destroy() is being invoked. It shouldn't be in
>>>> my case. I'm running a single client connection per unit test and
>>>> shut down when it returns. Is it possible to improve logging to
>>>> help figure out what is going on?
>>>>
>>>> Once I understand exactly what is going on I'd be in a better
>>>> position to decide on how destroy() should behave.
>>>>
>>>> Thanks,
>>>> Gili
>>>>
>>>> On 20/06/2011 4:42 AM, oleksiys [via Grizzly] wrote:
>>>>> Hi Gili,
>>>>>
>>>>> I took a look at the issue.
>>>>>
>>>>> "Expected behavior: destroy() methods should inform all other threads
>>>>> that no further requests will be accepted, wait for pending
>>>>> requests to
>>>>> complete, and terminate the handlers once that's done."
>>>>>
>>>>> Not sure it is really expected. For sure it sounds good, but there
>>>>> might
>>>>> be long-lasting requests in process, which may take long time to
>>>>> complete, we shouldn't wait for such a requests, right? We might
>>>>> want to
>>>>> introduce some destroy(long timeout), so it gives some time to
>>>>> requests
>>>>> to complete and after timeout expires - just forces destroy. This may
>>>>> require API extension and finally not sure if this method will be
>>>>> that
>>>>> useful.
>>>>>
>>>>> I propose to not assign null to filters and servletInstance fields in
>>>>> ServletHandler.destroy(), in that case NPE won't be thrown and each
>>>>> Filter will be able to throw some meaningful
>>>>> FilterIsAlreadyDestroyedException, which we may "fine"ly log.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Thanks.
>>>>>
>>>>> WBR,
>>>>> Alexey.
>>>>>
>>>>> On 06/19/2011 08:29 AM, cowwoc wrote:
>>>>>
>>>>> > I am very close to getting parallel unit tests working under
>>>>> Jersey, Guice
>>>>> > and Grizzly. I suspect the only remaining problem are
>>>>> race-conditions in
>>>>> > Grizzly's code. I'm seeing Grizzly-specific exceptions and some
>>>>> behavior
>>>>> > that leads me to believe that Grizzly is invoking Filters and
>>>>> > ServletContextListener methods out of order.
>>>>> >
>>>>> > Please take a look at
>>>>> http://java.net/jira/browse/GRIZZLY-1030 for starters
>>>>> > and we'll take it from there.
>>>>> >
>>>>> > Thanks,
>>>>> > Gili
>>>>> >
>>>>> > --
>>>>> > View this message in context:
>>>>> http://grizzly.1045725.n5.nabble.com/Parallel-unit-tests-tp4502842p4502842.html
>>>>> > Sent from the Grizzly - Users mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>> If you reply to this email, your message will be added to the
>>>>> discussion below:
>>>>> http://grizzly.1045725.n5.nabble.com/Parallel-unit-tests-tp4502842p4505579.html
>>>>>
>>>>> To unsubscribe from Parallel unit tests, click here.
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>> View this message in context: Re: Parallel unit tests
>>>> <http://grizzly.1045725.n5.nabble.com/Parallel-unit-tests-tp4502842p4506369.html>
>>>> Sent from the Grizzly - Users mailing list archive
>>>> <http://grizzly.1045725.n5.nabble.com/Grizzly-Users-f3726882.html>
>>>> at Nabble.com.
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>> If you reply to this email, your message will be added to the
>>> discussion below:
>>> http://grizzly.1045725.n5.nabble.com/Parallel-unit-tests-tp4502842p4506426.html
>>>
>>> To unsubscribe from Parallel unit tests, click here.
>>
>>
>> ------------------------------------------------------------------------
>> View this message in context: Re: Parallel unit tests
>> <http://grizzly.1045725.n5.nabble.com/Parallel-unit-tests-tp4502842p4506455.html>
>> Sent from the Grizzly - Users mailing list archive
>> <http://grizzly.1045725.n5.nabble.com/Grizzly-Users-f3726882.html> at
>> Nabble.com.
>
>
>
> ------------------------------------------------------------------------
> If you reply to this email, your message will be added to the
> discussion below:
> http://grizzly.1045725.n5.nabble.com/Parallel-unit-tests-tp4502842p4506522.html
>
> To unsubscribe from Parallel unit tests, click here
> <http://grizzly.1045725.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4502842&code=Y293d29jQGJicy5kYXJrdGVjaC5vcmd8NDUwMjg0MnwxNTc0MzIxMjQ3>.
>
--
View this message in context: http://grizzly.1045725.n5.nabble.com/Parallel-unit-tests-tp4502842p4506822.html
Sent from the Grizzly - Users mailing list archive at Nabble.com.