Open GoogleCodeExporter opened 9 years ago
Sounds like the same issue we get (running on Windows 2003). In our case, the
server and client both appear to be running, but the server does not detect the
client and so it times out after 30 seconds of waiting.
Original comment by willhol...@gmail.com
on 12 Aug 2010 at 11:53
That looks entirely like an issue with the windows box. The complaint is that
firefox doesn't call to the server within 30 seconds.
I'm dismissing this issue because we have a hudson build for JsTD that is doing
just fine. If you can determine that there is an issue with *how* the browser
is started, or is the browser displays an error after opening, feel free to
reopen the issue.
Original comment by corbinrs...@gmail.com
on 12 Aug 2010 at 2:09
I'm trying to gather more information on our issue. I have attached the tail
end of the log when it fails. Can you give me any direction as to how I could
investigate this further?
Original comment by willhol...@gmail.com
on 13 Aug 2010 at 8:43
Attachments:
We are experiencing this issue as well. About 1 in 10 builds fail with the
following exception from JsTestDriver:
java.lang.RuntimeException: Could not start browser CommandLineBrowserRunner
[browserPath=c:\Program Files (x86)\Mozilla Firefox\firefox.exe,
process=java.lang.ProcessImpl@132ae7,
processFactory=com.google.jstestdriver.SimpleProcessFactory@65b738] in 30
When it fails we force another build, and that one usually goes through, but
the team is understandably annoyed with the problem.
We are running 64-bit Windows 2008 Server with 32-bit CruiseControl.NET. Please
let us know if there is more information that we can provide (logs, machine
info, etc) to facilitate the investigation of this issue. We consider this to
be an intermittent defect in JsTestDriver, since JsTestDriver fails to reliably
manage its required resources (Firefox, in this case) under our server
configuration.
Thanks for re-opening this issue and allocating some bandwidth to investigating
it.
Original comment by marclitc...@gmail.com
on 4 Jan 2011 at 10:15
Original comment by corbinrs...@gmail.com
on 4 Jan 2011 at 10:22
The next version (or head for the adventurous) will have retries.
We solved this issue on the jstd cbuild by allocating more ram and processor to
it. I really wish I had more insight into why a resource constrained
environment makes the browsers so flaky.
Original comment by corbinrs...@gmail.com
on 10 Feb 2011 at 1:57
Original issue reported on code.google.com by
debounc...@gmail.com
on 12 Aug 2010 at 12:36