Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
@emcmanus I've been thinking about this problem and how to solve it. My solution that I've been focusing on is to tear down the connection after several hours. For instance, as soon as we connect, schedule the socket be torn down as a beanstalk job, in 18 hours or something like that. Next push will then create the socket. What are your thoughts?
This comment has been minimized.
This comment has been minimized.Show comment Hide comment
Hi Jeremy. The latest push looks great! Really like the new name.
Do you have any insight on what casuses Apple to drop the connection? (Network problem, inactivity or other...) If idleness is a factor it might make sense to purge killer on each successful write, but that's a small optimization.
Incidentally the one problem I had when getting started was marshaling a job message. You can see how I handled that, here. But I'll likely revert my job format updates -- the new readme is a huge improvement!
I'm pretty sure it's inactivity. I wrote a short blog post about how I'm going to handle this long term (just was easier to do this today) ... I want to keep a timer in the @clients[project_name] that tells me when the last push was sent; poll periodically and see which items are older than 20 minutes, close those connections (since they don't need to be open any longer)... there's likely a more elegant solution to this, just haven't thought about it much.
The new readme isn't complete, but yeah, I've deviated far enough from the original apnserver that it was time for a new name, and a new readme. :)
The reason i don't want to purge after each successful right is based on advice I was given by an apple engineer who works on the apns system; they will end up notifying my users (who are the ones with the apps) that their push service is configured inappropriately (if they do volume pushes), if it's constnatly making connections. This is why I'm thinking long term, killing an idle session after X minutes of inactivity would be best long term.
And finally, yeah I want to go over how I'm handling the push jobs and rework things to reduce the size of the job, and clean up the code, it's a mess. :) But that'll likely be next weekend when I get at that.