Jud White

@earwin I agree. We're okay with getting a failed PUB, tossing out old messages would not be desirable. Both use cases seem valid.

:+1: We have a real scenario where a Consumer can only call a downstream service every so often (let's say 1/s). We have multiple nsqds and multiple Consumers on this...

@mreiferson Yes, they should utilize some kind of rate limiting or resource pooling. Not my :circus_tent:, not my :hear_no_evil: :see_no_evil: :speak_no_evil:.

@danbf I agree cluster/node depth at the topic or channel level, and overall depth for a cluster/node, is helpful in many scenarios, not limited to shutdown. We extract this information...

Coming from the wonderful world of Windows, when executables are started by Service Control Manager (running as a Windows Service, which any semi-serious production app does) you don't get access...

@ploxiln [NSSM](http://nssm.cc/) is the de facto standard, but I'm not in favor of this approach. It would add another thing that can go wrong, can have compatibility issues, and has...

@ploxiln Honest answer, we don't log nsqd/nsqlookupd. We monitor the clients. If people prefer to use NSSM there are ways to support that without removing native support.

@andyxning Sorry we got on a tangent :smiley: If you have previous experience with `glog` and it meets the needs then great, let's try that if the core team is...

@mreiferson We don't log nsqd/nsqlookupd. I also agree that handling logs is the responsibility of the environment. In practice, on Windows, it doesn't work that way. I wish it did.

@andyxning Would you like to pair on this? You can find me on the Gopher Slack.