On 06/20/2011 05:39 PM, cowwoc wrote:
> 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?
All the important exceptions are being logged on SEVERE level, so you
might have seen them.
As for the general Grizzly monitoring, you can register probes:
httpServer.getServerConfiguration().getMonitoringConfig()... for
different HttpServer components.
>
>>> 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? :)
Yes, for port range it doesn't. Can I ask you to create the issue? :)
Here I'm attaching the ServletHandler, which should fix the NPE you
observe. Can you pls. try it?
Thanks.
WBR,
Alexey.
>
> 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.
>
>
> ------------------------------------------------------------------------
> View this message in context: Re: Parallel unit tests
> <http://grizzly.1045725.n5.nabble.com/Parallel-unit-tests-tp4502842p4506822.html>
> Sent from the Grizzly - Users mailing list archive
> <http://grizzly.1045725.n5.nabble.com/Grizzly-Users-f3726882.html> at
> Nabble.com.