create_browser problems

[quirkey]

I'm having problems similar to #8 in an application I'm working on. I'm creating this as a seperate issue, because in my fork I've actually switched to using create_browser_sync, and browser creation is failing way more than once in a while. I know (based on your notes) that this is not the ideal way to do things, however, this puts me in a bind because I need access to the cef_browser instance so that I can get access to the cef_frame and call functions on it (i.e. execute_javascript and load_url). It seems like you had some ideas on reconciling but I'm lost as to how to hook into those cef lifespan events.

Any help is hugely appreciated. Thanks for the great work on this wrapper - its enabling us to build some pretty awesome things!

[quirkey]

I should add that this is in a linux environment using the latest cef

[cztomczak]

Please ask questions on the CEF2go Forum. As to creating browser asynchronously and getting cefbrowser instance, see the fork created by fromkeith. It implements lifespan handler and the onaftercreated callback, see:

https://github.com/fromkeith/cef2go/blob/master/cefLifeSpanHandler.c
https://github.com/fromkeith/cef2go/blob/master/cefLifeSpanHandler.go

[cztomczak]

Fromkeith has made too many changes, changed file and function naming conventions, almost everything, so incorporating his changes into the main repo is not possible. Also, he is testing only one platform from what I've read in the commits.

[quirkey]

Thanks for the help. I've also been working on a fork that moves a bunch of files around (https://github.com/paperlesspost/cef2go). This was a requirement as I wanted to be able to use cef2go as a library from other application. I've only been testing on OSX and Linux as I dont have a Windows machine handy to test with. My usecase might be different than the general one though, as I'm using cef2go as a way to build a serverside headless application.

[quirkey]

I got the cef_lifespan hooks working and now do not observe this problem anymore. Thanks

[cztomczak]

I don't see how implementing lifespanhandler could fix create_browser problems reported in Issue #8. Maybe there were some other changes in your code that affected CEF execution and that some way fixed the problem. Have you tried writing an automation script that launches application 100-500 times to have a proof that it's really fixed? I have created Issue 1207 in CEF-tracker with a python script to provide such stress testing capability. Details in Issue #8.

[quirkey]

I should have been more clear, I implemented cef_lifespan_handler which allowed me to implement create_browser (async version) and still get a reference to the browser I created: https://github.com/paperlesspost/cef2go/blob/master/cef/cef_life_span_handler.go Using the async version, I haven't seen the problem again but I have not created a stress test (though I've definitely launched the process a couple hundred times)

[quirkey]

After more thorough testing, and creating a real test case that launches over and over, this is still a problem but happens much less frequently before ~2/150 runs.

[cztomczak]

It seems that this issue is occuring more frequently when app is heavy overloaded during startup. I think it really occurs during CEF initialization, some kind of race condition happening in a thread that is still running after Initialize() has returned. How about offloading cpu after Initialize() is called using time.Sleep for half a second ? Could you please test it using the test case you've already created?

After adding time.sleep(0.5) in CEF Python, the issue completely disappeared. See details here:
https://code.google.com/p/cefpython/issues/detail?id=131#c2

[quirkey]

Yes! I think your theory is correct. I wish there was a more reliable way to know how long to do the sleep, but adding a 0.5 second sleep after cef initialize did the trick.

Before:

[paperless@r2 cef2go (master)]$ RELEASE_PATH=../r2/Release ruby restart_test.rb 100
Running cef2go 100 times
.........F..F..........F.F..F...F...F....F....F....F....F..F......F.F......F.F...F.....F.......F..F.
Successes: 80. Failures: 20. Fail Rate: 20.0

After:

[paperless@r2 cef2go (master)]$ RELEASE_PATH=../r2/Release ruby restart_test.rb 100
Running cef2go 100 times
....................................................................................................
Successes: 100. Failures: 0. Fail Rate: 0.0

I ran a bunch of times and the failure rate before fluctuated between 8-20%.

Heres the commit in my fork: paperlesspost@69e8ec0

Test case here if you're curious:
https://github.com/paperlesspost/cef2go/blob/master/restart_test.rb

[cztomczak]

A corresponding issue in CEF tracker was created (star it so that it gets more attention):
https://code.google.com/p/chromiumembedded/issues/detail?id=1362