Parallel unit tests

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Parallel unit tests

cowwoc
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
Reply | Threaded
Open this post in threaded view
|

Re: Parallel unit tests

oleksiys
Administrator
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.

Reply | Threaded
Open this post in threaded view
|

Re: Parallel unit tests

cowwoc
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.

Reply | Threaded
Open this post in threaded view
|

Re: Parallel unit tests

oleksiys
Administrator
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
Sent from the Grizzly - Users mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

Re: Parallel unit tests

cowwoc

    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.

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).

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
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-tp4502842p4506426.html
To unsubscribe from Parallel unit tests, click here.

Reply | Threaded
Open this post in threaded view
|

Re: Parallel unit tests

oleksiys
Administrator
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.


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.

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
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-tp4502842p4506426.html
To unsubscribe from Parallel unit tests, click here.



View this message in context: Re: Parallel unit tests
Sent from the Grizzly - Users mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

Re: Parallel unit tests

cowwoc
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
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-tp4502842p4506426.html
To unsubscribe from Parallel unit tests, click here.



View this message in context: Re: Parallel unit tests
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-tp4502842p4506522.html
To unsubscribe from Parallel unit tests, click here.

Reply | Threaded
Open this post in threaded view
|

Re: Parallel unit tests

oleksiys
Administrator
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
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-tp4502842p4506426.html
To unsubscribe from Parallel unit tests, click here.



View this message in context: Re: Parallel unit tests
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-tp4502842p4506522.html
To unsubscribe from Parallel unit tests, click here.



View this message in context: Re: Parallel unit tests
Sent from the Grizzly - Users mailing list archive at Nabble.com.


ServletHandler.java (36K) Download Attachment