unsetbit
Errors initializing browser providers (browserstack)
As far as I can tell, queen never falls into the code path for actually initializing the remote worked, both in the stable branch and in master. Is this feature working currently? I see the plugins initialized, but I never see the code for a specific provide called (browserstack, in my case).
Turns out there's a typo in the manager or README file. Manager.js in queen-populator-plugin checks for config.populator on line 14, versus 'populators' which is in the example for the queen config file. I'll do a fork/pull request if you'll let me know which you'd prefer to run with.
Second issue that I'm seeing - it appears that the browserstack client instances never complete initialization. If I manually direct a Browserstack client to the localhost:9000 URL when tunneled, then I see the socket events happen and a message is passed back to queen. But when using the automatic initialization, the client never responds and queen just repeatedly terminates the client when it times out.
I see where the example says that it may not work, but can you give me an idea of whether this might just be an API change in Browserstack and this was working at one time, or something else?
Looks like the correct use is a singular "populator", and you have the option of passing an array or an a single object (https://github.com/oztu/queen-populator-plugin/blob/stable/lib/manager.js). This makes sense, because 80% of the time, you'll want one populator, using many would be an exceptional case, so I think it makes sense to keep it singular.
As for the browserstack issue, I'm not sure about that one. It worked at one point (which was 5 months ago), so the api could definitely have changed to break integration since then, unfortunately I won't have time to debug that one until July.
Not a problem, I have a need for this use so I'll dig into it and see what I can find. We're going to be using BrowserStack, so I've got a vested interest in learning their API more fully.
I updated the wiki as per your comments to be more clear.
I have no idea why, but it appears things are working now. I was running the tests inside terminal using tmux, and it's possible that my shell was not picking up changes that I was making to the files across the various sessions? Either way, will close this out now.
Reopening as I'm still seeing erratic behavior. I suspect, possibly related to #7, that the listeners for the browser clients are not being initialized in time to catch the browsers reporting that they are ready. Not being familiar with socket.io and how it might retry, I could be completely wrong.
When I init several browsers upon startup, I can them make a manual rest call to see the status of those browsers. Only a browser that reports itself being in queue actually starts talking to queen after that. So it appears that everything is working as intended, but a race case might be why Queen keeps killing and restarting browsers, but they never actually communicate.
Believe I have confirmation on this as the issue. I changed the browser versions I was requesting to be 'latest', which triggers a recursive call to the createWorker function here: https://github.com/scottgonzalez/node-browserstack/blob/master/lib/browserstack.js#L54
When this happens, it looks like the 2 calls enable queen to finish getting set up to listen for browsers BEFORE Browserstack comes back with the browsers, due to the 2 REST calls being chained together.
So it does appear to be a race case. I will keep looking further into the code to determine what changes are needed.
Figured you might want more reading material on vacation. :) Finally occured to me to start rolling back nodejs versions as well. I get stack overflows with 0.8, but using the latest on the 0.9 runs correctly for me from the start, w/o having to introduce the 2 rest calls. In other words, I can use it exactly as intended, so long as I am on v0.9.12 of node.
Did some more testing, and with node 0.9.12, everything appears to work as expected as far as browsers being picked up. I am seeing some issues with event emitter warnings and queen making calls for browsers that are already running. I'll get this error:
[Queen] Connection on capture port didn't register within timeout period
and it will spin up a new browser. It's not a huge issue, but it makes the test results odd because you get more than expected numbers of browsers doing the testing. It also seems like there are some persistent socket.io connections that don't go away, even when the browser is reported as dead by browserstack.
I'll make a note about node 0.9.12 on the wiki and keep testing.
Sweet, thanks for the diligence, Scott. Sorry I'm not much help right now.