-
Notifications
You must be signed in to change notification settings - Fork 442
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nsq_to_nsq: panic on shutdown #95
Conversation
hi @twmb, thanks for the report. I'm having trouble reproducing this locally - can you provide more of the logs before where you began to paste? |
more logs before:
|
|
(from discussion on IRC)
The problem is that in this case it has already ingested Also, because there is only one destination host configured, So, in this case, because the consumer has ingested In this example the problem is exacerbated by the fact that this destination address is like a black hole, where each connection blocks for We obviously can/should fix the panic, but the practical problem of handlers blocking is a much larger issue. Thinking out loud, I guess Thoughts? |
RFR, one possible "solution" @jehiah |
There's nothing we can do about the general case of a handler blocking and clean close, but I'm going to open an issue to discuss the |
ping @jehiah |
My steps:
Using the following run file for nsq_to_nsq, have a local nsqd running. Do not have a destination nsqd running.
sv stop
nsq_to_nsq once (this hangs for 10 seconds). nsq_to_nsq continues backing off that it cannot connect to the remote nsqd.sv stop
again, panic. If you need more details, please ask.Run file:
Log trace on panic: