I am writing a game application with an event queue. The idea is that the event queue is polled every second and if there is one or more active events then we take the first one and action it,
The events themselves are represented by Ember Models (of type Event). Actioning the event just means passing the event to a function that will check the attributes and take some action accordingly - probably update some other Ember models. And the event queue itself is an Ember Service.
I am using Ember Concurrency to set up a task that will get called every second. However I have a lot of problems with the code inside this task. Often the calls to the store seem to fail. Do I need to wrap all calls to the store (to fetch data or update data) in Ember.run? Are there any add-ons/articles that might help me here?
Thanks for any help
I wouldn’t think you’d need to wrap your code in an Ember.run or anything like that. Sounds like you’ve got everything set up pretty well. Any idea why the store calls fail? Do they ever make it to the server?
FWIW we have several pollers in our app. We don’t use ember-concurrency for those pollers specifically (though it is a really nice addon and we use it other places). We just do an ember.run.later on the poll function, which does a data fetch of some sort, and then we set up the next poll in both the .then and the .catch so it keeps going. Works pretty well for us.
One thing you may want to be careful of is if you poll using store.query there is still (AFAIK) a memory leak in store.query and polling with it can really start to clutter things up. We had to change all of our store.query usage to ajax calls in our pollers.
Thanks, glad to hear you are doing something similar with success. Setting off the polling with Ember Calling Ember.run.later and then finishing with a new call to Ember.run.later seems simple. I’ll give it a go if I cannot resolve my issues. I am also aware of pollTask in Ember lifeline.
It’s possible that the data issues occur in other code. I also use Ember-Concurrency to load all my data in the route model functions. And it’s the code there that has problems when the Event Queue is running. If the Event Queue is not running there are no errors. The sort of errors I am getting are: “No ‘Access-Control-Allow-Origin’ header is present on the requested resource.” or “Attempted to handle event becameError on user-calendar-event:6555 while in state root.loaded.updated.uncommitted”, And this is what made me think I was doing things outside the runloop.
That’s a good point about the potential memory leaks. The game is intended to run for two hours without reloading so memory leaks are an issue and I do use store.query in some parts of the code.
Perhaps I need to somehow pause my Event Queue whilst the Route model is loading and then restart it again once the the route model has loaded?
Any reason you’re using ember-concurrency in the model hooks of your routes? AFAIK one of the most common uses cases for EC is to use it in cases where you need to fetch async data but cannot use the router to do it. The router should be sufficient for most use cases for loading models. Though that’s all generalities of course, if you have a specific reason for doing it there it might not be an issue. If possible though I’d consider removing EC from your model hooks and using it in places where you can’t use the router.
Also FWIW most of our pollers are only used by specific views, so we start them in the setupController hook usually and stop them in the willTransition hook of each route that needs it. Of course if you’ve got a game then maybe your poller just needs to run all the time.
And as for the query memory leak, it could definitely be an issue if you’re using it every second for 2 hours, but if it’s just random model hook calls here and there I don’t think you’d notice it.
Yes there is no specific reason. I just liked the convenience of being able to write {{#if model.task.isRunning}} in the route template and then to display different content depending ob whether the model was being loaded or had loaded, I also like the power of Ember Concurrency and wanted to start learning it.
That’s a good heads up on the memory leak - I’ll look out for it.
Gotcha, my recommendation would be to back out of using it in your route model hooks if you can. Definitely use it anywhere else it’s appropriate, but technically using it in the router is pretty redundant and could cause you issues, maybe like the ones you’re seeing with your event service.
Assuming your model hooks return promises, the router will pause until the model is resolved. There is also ember’s “loading” substate which you can probably use as a substitute for the model.task.isRunning check you described above.
The only other thing I’d recommend is trying Ember.run.later in your poller instead of ember-concurrency, but I’d say if taking EC out of your model hooks fixes the event service then my all means keep using EC there (that’s more what it’s designed for). Good luck!