I took a couple minutes to try to get one of them "einhorned"; I lost most of my time to trying to satisfy EM gem dependencies (we use em-http-request, which has a fussy gemspec). I got Stripe's EM built, file descriptors passed to my proxy, and EventMachine::start_server set up with the fd instead of the address; I'm getting accept callbacks, but not received data.
Will tinker later. High hopes. Thank you very much for open sourcing this.
You might find that you get better performance by having the parent call accept() and hand off sockets to the children. With sufficient abuse of LD_PRELOAD you can probably do this without making any changes to the child processes -- you just need to override accept() with a function which checks if any sockets have been handed off.
I noticed that the Stripe blog doesn't allow comments. I think most people find it odd or frustrating when they can't add their 2 cents to something (for better or for worse!). Any idea which things might have driven this decision?
- Not wanting to deal with how most people act on the net? (Or maybe they're in a highly competitive space where the juggernauts wouldn't think twice about trying to destroy their image.)
- To encourage people who want to discuss the blog entry to submit it to their favorite discussion communities?
- To avoid possible PR issues sitting right on their company's blog? (Related to point #1)
There is a kind of beautiful simplicity to the page that comments would probably destroy.
Further, when I did have both, comments that self-selected the blog (vs HN) are - in my opinion - much more likely to be spam/promotional, or generally less 'valuable' (e.g. more likely to be simple questions that are already answered in the post).
I would expect more negative comments to be left directly on the blog as well since the commenter won't have to deal with the potential backlash from their community. Which is probably also a good reason to never allow any kind of anonymous of guest comments. (Although that wouldn't stop the truly motivated negative commenters.)
This is a problem we ran into at PhpPhotoUploadr. In our case we have a very talented team so we hacked together a solution.
PS: We're always hiring 忍者!
"This is what I have to say, I've wrote it and re-written it, and reformulated it and I think its good for publishing. I then published it and if you have comments, send me an Email and I'll consider amending my post".
Now, since you've extracted the capabilities of Unicorn out into something that isn't coupled to a Web server (and it's written in pure Ruby, so is portable), we should be able to use it as a shim between nginx for managing Trinidad (Tomcat) instances. Very much looking forward to giving it a try - thanks for your efforts!
EDIT: Whoops, guess I spoke a bit too soon. I get this error:
NotImplementedError: fork is not available on this platform
I'm new to this whole concept, so am just about to get my feet wet.
Hopefully, Heroku will implement something like this internally, as it seems it would help them to eliminate the greatest flaw with their system - that each deployment require 5-10 seconds of downtime as new dynos are started.