usefulness of per-worker listeners?

[Eric Wong]

Hi all, I'm wondering if folks find per-worker listeners useful for
unicorn.

When I started unicorn back in 2009, I thought it would be a very useful
feature, but really haven't used it since 2009...

The main problem is the necessity of the :tries/:delay parameters
when restarting workers, and the possibility of losing connections
to that worker momentarily during restarts/upgrades.

I'm not going to remove it from unicorn, though.  However, I am working
on a new TCP (not just HTTP) server based on unicorn, so I'm thinking
about not having it there...

Normally, if I have to track down a problem with an app running on
unicorn, I'll SIGTTOU to the point where there's only one worker
and work on that.

Thanks for reading!
___
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying

Re: usefulness of per-worker listeners?

[Greg Hazel]

On Sep 25, 2013, at 3:46 PM, Eric Wong normalper...@yhbt.net wrote:

 Hi all, I'm wondering if folks find per-worker listeners useful for
 unicorn.

One time, I made a few inspection calls for individual workers, to collect 
statistics on memory usage and object allocation and in-memory cache and things 
like that for rendering munin graphs. I used the per-worker listeners for 
expediency, but I could have come up with some other signaling and aggregation 
mechanism.

So, that's a use-case, but I'd also be fine if they went away or were not 
available in a new thing.

-Greg

___
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying