Scheduler and DeferredCommand stopping in unit tests

[salk31]

Has anybody else had cases where Scheduler and DeferredCommands have stopped being scheduled/run when used in unit tests?

We have a lot of async code so need to use them a lot but currently, seemingly at random, our tests stall until they get timed out. Even setting up a periodic job that is never meant to stop will fail at the same time/point as our normal jobs.

Lot of code going on with junit/GWTTestCase/htmlunit/jetty/requestfactory/database... and because it is hard to reproduce it is proving tough to fix.

Many thanks

Sam

[Joseph Lust]

I have found that scheduling a deferred event can be at times an anti-pattern. For example, let's say I've got a bunch of UI elements getting initialized. I had in the past used a deferred command to finish the UI init once everything is there. In this case there would be errors that occurred 5% of time when a user was on a stressed browser/old client and the event was returned before all init tasks were complete.

The better way to deal with this I've found is the EventBus and latches. Let's say I needed 10 things setup before the UI can continue, then those 10 things will throw an event to that latch listener and once all 10 are complete, it fires an event to carry on now at the UI is ready. Perhaps this is applicable to your case.

Hope that helps.

Sincerely,

Joseph

[salk31]

Thanks Joseph,

I'd like to have events fired as the RPC queue changes but my boss, quite rightly, would kill me if I changed production code to get the unit tests to work ;) 

I've just tried using a Timer (the GWT one) but still stalls :(

Regards

Sam

[salk31]

Maybe related to this:

http://code.google.com/p/google-web-toolkit/issues/detail?id=2391 

(Only just remembered that Timer exists!)

[salk31]

Sorry for talking to myself but...

waitForBackgroundJavaScriptStartingBefore looks like a possible cause. It is called here:

http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/google/gwt/junit/RunStyleHtmlUnit.java#158 

with a value of 2s the implementation of this method seems a bit odd:

http://grepcode.com/file/repo1.maven.org/maven2/net.sourceforge.htmlunit/htmlunit/2.9/com/gargoylesoftware/htmlunit/WebClient.java#WebClient.waitForBackgroundJavaScriptStartingBefore%28long%29 

It seems to block while the number of jobs is different to the number of jobs after the time passed to it...

This time starts _before_ servlet startup so in our case that could easily be longer than 2s....

Just me or both these bits of code a bit dodgy? Maybe gwt should pass the unit test timeout value to htmlunit or just some huge value?

Thanks

Sam

On Friday, July 6, 2012 10:23:02 AM UTC+1, salk31 wrote:

[Thomas Broyer]

On Wednesday, July 11, 2012 9:21:10 AM UTC+2, salk31 wrote:

Sorry for talking to myself but...

waitForBackgroundJavaScriptStartingBefore looks like a possible cause. It is called here:

http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/google/gwt/junit/RunStyleHtmlUnit.java#158 

with a value of 2s the implementation of this method seems a bit odd:

http://grepcode.com/file/repo1.maven.org/maven2/net.sourceforge.htmlunit/htmlunit/2.9/com/gargoylesoftware/htmlunit/WebClient.java#WebClient.waitForBackgroundJavaScriptStartingBefore%28long%29 

It seems to block while the number of jobs is different to the number of jobs after the time passed to it...

This time starts _before_ servlet startup so in our case that could easily be longer than 2s....

Just me or both these bits of code a bit dodgy? Maybe gwt should pass the unit test timeout value to htmlunit or just some huge value?

IIUC, that code is called when loading the page, to wait for the GWT code to launch, but before tests are executed. I doubt it's the culprit.

BTW, have you set the logs to SPAM level? that could help find where things hang. Also maybe a threaddump (not sure I could help, but pretty sure the people knowing the internals better than me would find them useful)

[salk31]

Hi Thomas,

It is called at the loading of the page but the HtmlUnitThread only runs while that call is blocking...

I'm struggling to point the finger at a particular line of code but:

* Fiddling with the number of seconds GWT specifies to HTMLUnit can make the problem appear and disappear (a colleague has duplicated but I had to mess with Maven dependencies so not as reliable at test as wanted)

* I noticed that when a test stalls the HTMLUnit JavaScript thread was "gone".

I'll try and write a unit test before raising an issue but is not easy as seems non-deterministic.

btw Congratulations on your new role in the steering committee. Bit scary as the code as been sooooooooo good so far but fingers crossed.

Cheers

Sam

[salk31]

OK. Last post but just in case somebody hits this in the future. I have a simple unit test (below) that fails about 50% of the time... However it doesn't fail in 2.5-rc1 so as it is so obscure anyway I won't raise a issue.

Sorry for the spam!

package com.google.gwt.sample.dynatablerf.client;

import com.google.gwt.junit.client.GWTTestCase;

import com.google.gwt.user.client.Timer;

public class GwtTestStall extends GWTTestCase {

    @Override

    public String getModuleName() {

        return "com.google.gwt.sample.dynatablerf.DynaTableRf";

    }

    public void testStall() {

        this.delayTestFinish(2 *60 * 1000);

        Timer slowJob = new Timer() {

            @Override

            public void run() {

                System.out.println("Slow job: done");

            }

        };

        System.out.println("Slow job: start");

        slowJob.schedule(3000);

        Timer repeatingJob = new Timer() {

            int done;

            @Override

            public void run() {

                System.out.println("timer "  + done);

                if (done < 100) {

                    done++;

                    schedule(100);

                } else {

                    System.out.println("Repeating job: done");

                    finishTest();

                }

            }

        };

        System.out.println("Repeating job: start");

        repeatingJob.schedule(1000);

    }

}