504 constant timeouts?

[NuckChorris]

I'm trying to use this to prerender hummingbird.me but I've run into two problems: (1) it gives a 504 error on all endpoints (which it seems to attempt to continue using that worker too) and I can't seem to get it to be more verbose and help me understand the problem and (2) it refuses to switch to JSDOM so I can debug it better (since I understand jsdom better than phantomjs)

I'm not sure if this might be related to my clustering it to increase rendering thoroughput. Any help would be appreciated, I took a look but didn't find anything obviously wrong.

I'd really prefer to use this over something like prerender.io because (a) it's open-source completely and (b) it's deterministic, and I have a hatred of nondeterministic systems from my user scripting days 😉

[Stanback]

Thanks for reporting the issue.

Have you tried running the example project in this repo? Curious to know if that works for you.

You might also try installing ember-prerender from Github instead of NPM as NPM is a few commits behind (use: npm -g install zipfworks/ember-prerender). I need to start using Github releases and publishing to NPM more regularly.

What version of Ember are you running? I would make sure the XContentReady event is firing and maybe setup a very minimal route to test with.

As far as I know, ember-prerender shouldn't ever be sending a 504. It sends a 503 on timeout and 500 in the case of a fatal JS error. I do need to revisit JSDOM, I was having some problems with Ember 1.8 and beyond, not sure what the issue is yet. You could try running it with the webdriver option as an additional way to try pinpointing the issue.

[NuckChorris]

Thanks for the help! I can say it's definitely giving a 504 error (which makes sense for timeout, since that's a Gateway Timeout error) though I can't find anywhere in the source which is giving a 504.

Anyways, it looks like XContentReady is indeed never being fired. In fact, the didTransition action appears to never fire, judging from a console.log I put at the top. Really quite strange. We're using Ember 1.8.1, which is old but should still function.

I've made some improvements to the Ember-side hooks, namely using CustomEvent instead of createEvent and moving things to match ember-cli standards, but it's all still functionally equivalent and the example project appears to make the same changes (you should probably also add them to the README).

For reference, my didTransition hook is this bit in app/app.js:

Ember.Route.reopen({
  willComplete: function() {
    return Ember.RSVP.resolve();
  },

  actions: {
    didTransition: function() {
      console.log('transitioning');
      this._super();
      let promises = [];
      this.router.router.currentHandlerInfos.forEach((handler) => {
        if (handler.handler.willComplete) {
          promises.push(handler.handler.willComplete());
        }
      });
      Ember.RSVP.all(promises).then(() => document.dispatchEvent(window.XContentReadyEvent));
    }
  }
});

the transitioning log doesn't ever happen, oddly

Edit: could it be that the action is being overridden by route subclasses? Wouldn't function () {}.on('didTransition') be better anyways?

[NuckChorris]

Fixed all that, confirmed that it's emitting the events now (the didTransition event is on Router, not Route), but I'm still getting the 504 error. I'm testing live against https://hummingbird.me/anime/sword-art-online and I'm totally stumped.

I tried my cluster'd version (linked in OP) with the example app and got the following error:

2015-03-31T06:55:00.076Z getting 
phantom stderr: PhantomJS has crashed. Please read the crash reporting guide at https://github.com/ariya/phantomjs/wiki/Crash-Reporting and file a bug report at https://github.com/ariya/phantomjs/issues/new with the crash dump file attached: /tmp/C17C723B-C047-4560-9BB3-394BFAD6498F.dmp
2015-03-31T06:55:03.476Z phantom crashed, restarting...
2015-03-31T06:55:03.477Z starting phantom on port [12304]
2015-03-31T06:55:06.806Z started phantom
2015-03-31T06:55:10.414Z PhantomJS restarted in the middle of this request. Aborting...
2015-03-31T06:55:10.420Z got 504 in 10344ms for

(no, that's not truncated, it really ends at "for", I think because I'm getting / route)

I would say "maybe it's not threadsafe" except Node isn't threading it, it's forking multiple processes. Color me doublestumped.