usefulness of per-worker listeners?

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 <normalperson@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