Understanding Issue - Could not launch browser

[karanjeets]

Hello,

I want to understand about the exception Could not launch browser. What is it checking for and what does it indicate when we get this exception.

I understand that the exception is raised from the below code:

https://github.com/MachinePublishers/jBrowserDriver/blob/master/src/com/machinepublishers/jbrowserdriver/JBrowserDriver.java#L318

Can you please provide me some direction?

_Error Log_:

org.openqa.selenium.WebDriverException: Could not launch browser.
Build info: version: 'unknown', revision: 'unknown', time: 'unknown'
System info: host: 'Karanjeets-MacBook-Pro.local', ip: '192.168.0.2', os.name: 'Mac OS X', os.arch: 'x86_64', os.version: '10.12', java.version: '1.8.0_74'
Driver info: driver.version: JBrowserDriver
    at com.machinepublishers.jbrowserdriver.Util.handleException(Util.java:140)
    at com.machinepublishers.jbrowserdriver.JBrowserDriver.<init>(JBrowserDriver.java:318)
    at edu.usc.irds.sparkler.plugin.FetcherJBrowser.createBrowserInstance(FetcherJBrowser.java:85)
    at edu.usc.irds.sparkler.plugin.FetcherJBrowser.fetch(FetcherJBrowser.java:55)
    at edu.usc.irds.sparkler.pipeline.FetchFunction$.apply(FetchFunction.scala:48)
    at edu.usc.irds.sparkler.pipeline.FetchFunction$.apply(FetchFunction.scala:36)
    at edu.usc.irds.sparkler.pipeline.FairFetcher.next(FairFetcher.scala:52)
    at edu.usc.irds.sparkler.pipeline.FairFetcher.next(FairFetcher.scala:29)
    at scala.collection.Iterator$$anon$12.next(Iterator.scala:444)
    at org.apache.spark.storage.MemoryStore.unrollSafely(MemoryStore.scala:285)
    at org.apache.spark.CacheManager.putInBlockManager(CacheManager.scala:171)
    at org.apache.spark.CacheManager.getOrCompute(CacheManager.scala:78)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:268)
    at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:38)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:306)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:270)
    at org.apache.spark.scheduler.ResultTask.runTask(ResultTask.scala:66)
    at org.apache.spark.scheduler.Task.run(Task.scala:89)
    at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:214)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IllegalStateException: Could not launch browser.
    ... 21 more

[hollingsworthd]

JBrowserDriver essentially forks itself for each new instance of JBrowserDriver and then communicates with that child process via Java RMI. And that child process is the "browser". Further down on line 403 it gets stdout from the child proc: String[] parts = line.substring("ready on ports ".length()).split("/"); ... that is the child proc saying what RMI ports to use. If that line is never received or another exception takes place in launching that child proc, then the "Could not launch browser" exception is thrown. That exception is probably too lacking in detail. Also see JBrowserDriverServer: there's a main method in there and is the starting point for the child process.

[karanjeets]

@hollingsworthd Thanks for the details. Do you know, how can I check the output of child proc? I am not sure what's going wrong here. If I can refer to the exception, maybe I can get some lead.

I am trying to run JBrowserDriver on top of Apache Spark. Also, I am using OSGi bundle to package all the dependencies of JBrowserDriver.

[hollingsworthd]

OSGi might be the problem. JBD inspects the classpath at runtime and attempts to launch the child proc with the same classpath, and if there are jars within jars readable by custom classloaders (common with lots of frameworks) JBD attempts to unpack those jars to be used by a standard classloader.

The log/error messages get bubbled up and output to Java Util Logging with logger name "com.machinepublishers.jbrowserdriver" which comes with a default handler that will echo to stdout/stderr. Log4j and Slf4j have bridges which can be used to redirect those, otherwise those framework I think bury the messages.

Overall visibility to debug this is something that needs improvement. If possible I'd recommend creating as simple test as possible to recreate the error. It may be useful to clone the project and use maven to deploy it locally (mvn clean compile install from project root). Then in your main project, change the dependency to 0.16.5-SNAPSHOT and that will pull in your local copy of the build. That will let you add debug statements etc. Also for attaching a debugger see Settings.javaOptions("..") and you can add a setting that will cause the Java child proc to wait for a debugger to attach.

[hollingsworthd]

This issue can be combined with #181