SuriGill / js-test-driver

Automatically exported from code.google.com/p/js-test-driver
0 stars 0 forks source link

Running tests hang #249

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?

1. Start server:
java -jar JsTestDriver-1.3.2.jar --port 9876
2. Start capturing in browser
3. Try to run tests with the following command:
java -jar JsTestDriver-1.3.2.jar --tests all --server http://localhost:9876

What is the expected output? What do you see instead?

I expect the tests to be run, the JAR run to finish and give feedback of the 
tests having executed. Instead, the script hangs.

I attached the output from the debug mode. This pattern seems to be repeating 
infinitely:

Jun 28, 2011 7:08:44 PM com.google.jstestdriver.HttpServer fetch
FINEST: Fetch response 
{"last":false,"response":{"type":"UNKNOWN","response":"{}","browser":

{"id":1309279631300,"name":"Chrome","version":"14.0.797.0","os":"Windows","uploa
dSize":50,"serverReceivedHeartbeat":tru

e},"error":"","executionTime":0}}
Jun 28, 2011 7:08:44 PM com.google.jstestdriver.FileUploader uploadToTheBrowser
FINEST: LOADTEST response for Response (
browser=[Chrome 14.0.797.0 Windows],
error=[],
executionTime=[0],
response=[{}],
type=[UNKNOWN])
Jun 28, 2011 7:08:44 PM com.google.jstestdriver.HttpServer fetch
FINEST: Fetching http://localhost:9876/cmd?id=1309279631300

What version of the product are you using? On what operating system?
js-test-driver 1.3.2, java:

$ java -version
java version "1.6.0_17"
OpenJDK Runtime Environment (IcedTea6 1.7.5) (rhel-1.16.b17.el5-x86_64)
OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)

Please provide any additional information below.
When running the server with automatic launching the browsers (1st step with 
--browser XXX) it runs flawlessly

Original issue reported on code.google.com by tczol...@gmail.com on 28 Jun 2011 at 5:21

Attachments:

GoogleCodeExporter commented 9 years ago
Same with FF:

FINEST: LOADTEST response for Response (
browser=[Firefox 4.0.1 Windows],
error=[],
executionTime=[0],
response=[{}],
type=[UNKNOWN])
Jun 30, 2011 4:16:32 PM com.google.jstestdriver.HttpServer fetch
FINEST: Fetching http://localhost:9876/cmd?id=1309443347065
Jun 30, 2011 4:16:34 PM com.google.jstestdriver.HttpServer fetch
FINEST: Fetch response 
{"last":false,"response":{"type":"UNKNOWN","response":"{}","browser":{"id":13094
43347065,"name":"Firefox","version":"4.0.1","os":"Windows","uploadSize":50,"serv
erReceivedHeartbeat":true},"error":"","executionTime":0}}
Jun 30, 2011 4:16:34 PM com.google.jstestdriver.FileUploader uploadToTheBrowser
FINEST: LOADTEST response for Response (
browser=[Firefox 4.0.1 Windows],
error=[],
executionTime=[0],
response=[{}],
type=[UNKNOWN])

[...]

Original comment by tczol...@gmail.com on 30 Jun 2011 at 2:16

GoogleCodeExporter commented 9 years ago
I can't say that these logs make a whole lot of sense to me. It looks like it 
executed the tests then attempted to load them, which is just plain wrong. Can 
you simplify the reproduction case by using a simple test like this:

var SimpleCase = TestCase('SimpleCase');
SimpleCase.prototype.testSanity = function() {
  assertTrue(true);
};

And including the full log? The repeated section out of context doesn't help. 
Specifically, I need the start through the 3rd repetition. As I can't get it to 
repro locally.

Original comment by corbinrs...@gmail.com on 30 Jun 2011 at 3:11

GoogleCodeExporter commented 9 years ago
Hi,

Thanks a lot for your answer.
Sure, I attached the full output with the simple test (I stripped my user name, 
because of NDA)

Original comment by tczol...@gmail.com on 30 Jun 2011 at 4:12

Attachments:

GoogleCodeExporter commented 9 years ago
FYI the browser doesn't run on the same host. I doubt this should be an issue 
though.

Original comment by tczol...@gmail.com on 30 Jun 2011 at 4:14

GoogleCodeExporter commented 9 years ago
Hi,

I've experienced something similar. 
I run a very simple test (attached) in a loop on a single browser - in this 
case Chrome. After a certain amount of iterations the communication between the 
server and the browser seems to break down and never recovers.

for i in {1..1000}; do java -jar 
/home/kumar/Downloads/js-test-driver/1.3.2/JsTestDriver/target/bin/JsTestDriver.
jar --reset --verbose --tests all --runnerMode DEBUG; done >> output.txt 2>&1

In the gzipped tar:

output.txt.gz is the debug output. You'll see after some time that the browser 
appears to return:

FINEST: Fetch response 
{"last":false,"response":{"type":"UNKNOWN","response":"{}","browser":{"id":13105
44264437,"name":"Chrome","version":"9.0.597.107","os":"Linux","uploadSize":50,"s
erverReceivedHeartbeat":true},"error":"","executionTime":0}}

for every request. The test then is cancelled.

In the tar I've also attached the test that I run and the config file.

Ideally we'd like to use jsTestDriver in the following configuration:

1. Server runs on a central location with fixed number of browsers *always* 
captured
2. Developers can then run tests against this configuration
3. CI builds run tests against same configuration

At the moment this issue means that a browser quickly becomes unusable, so the 
above scenario is not possible.

Any help with this would be greatly appreciated.

Original comment by Krish...@gmail.com on 13 Jul 2011 at 8:18

Attachments:

GoogleCodeExporter commented 9 years ago
At some point I closed the browser, so please ignore the log lines that 
indicate that there were no browsers attached

Original comment by Krish...@gmail.com on 13 Jul 2011 at 8:36

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago

Original comment by corbinrs...@gmail.com on 28 Jul 2011 at 2:49

GoogleCodeExporter commented 9 years ago
I can't determine a root cause, but it looks like the browser is waiting for 
the load of the test to finish.

Next version has better defined protocol semantics, which should, at the very 
least, make it easier to debug.

Original comment by corbinrs...@gmail.com on 28 Jul 2011 at 3:00

GoogleCodeExporter commented 9 years ago
OK, I'll try to compile the head and see if I can still find the problem.
Thanks so far!

Original comment by tczol...@gmail.com on 28 Jul 2011 at 3:03

GoogleCodeExporter commented 9 years ago
I did try all the versions including head and the same problem is there

Original comment by Krish...@gmail.com on 28 Jul 2011 at 3:19

GoogleCodeExporter commented 9 years ago
Hi,

I compiled the HEAD, although now it's a different error, still hangs. Attached 
output.
Revision: 1003.

Now it seems that it does not get into loop, but it stops at this line:
FINE: Sending LOADTEST to 1312196649864 for [
/test/test.js]

I was waiting for 10 minutes then killed it.

Original comment by tczol...@gmail.com on 1 Aug 2011 at 11:11

Attachments:

GoogleCodeExporter commented 9 years ago
Hmmm... please include the logs from the server? The client logs are only half 
the story. It looks like something odd is happening during the loading of the 
test file in the browser.

Original comment by corbinrs...@gmail.com on 1 Aug 2011 at 11:48

GoogleCodeExporter commented 9 years ago
Sure, makes sense. Attached.

Original comment by tczol...@gmail.com on 1 Aug 2011 at 1:42

Attachments:

GoogleCodeExporter commented 9 years ago
...hangs on the last line

Original comment by tczol...@gmail.com on 1 Aug 2011 at 1:43

GoogleCodeExporter commented 9 years ago
Was this ever resolved and/or has it been looked at recently?

Original comment by bret.lit...@gmail.com on 28 Aug 2012 at 10:06

GoogleCodeExporter commented 9 years ago
Well, I just made a few changes that should cut down on random hangs. 
Unfortunately, I wasn't able to reproduce this case while testing. If you can 
give head a shot and let me know, that'd be great.

Original comment by corbinrs...@gmail.com on 28 Aug 2012 at 10:14