-
Notifications
You must be signed in to change notification settings - Fork 38
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
Close producer no matter if @producer_enabled
or not
#127
Comments
For producers, by default they are only opened/closed when you produce: def publish_list(messages)
producer = sync_producer || create_sync_producer
produce_messages(producer, messages)
producer.deliver_messages
ensure
producer&.shutdown unless Phobos.config.producer_hash[:persistent_connections]
end If you have at_exit do
MyProducer.producer.sync_producer_shutdown
end |
Yeah, sorry I didn't explain the use case clearly in the description:
If I understand this correctly, this needs to happen inside the same thread that does the producing, where do you recommend to put this logic for phobos-consumer? Right now my approach is:
That's why I proposed to have this logic inside the existing |
One option is for you to define your producer classes outside the listener, e.g. in an initializer (if you're running Rails), a railtie, etc. This means your consumers would share the producer objects and you could shut them down from a single place. |
Ah - just realized Phobos has a |
For other application rails/sinatra, we handled it by puma For publishing inside the phobos consumer, I'm not sure how to share the producer across different threads though (we're using
This is the output:
So the boot thread isn't the same one as those store producers, any thoughts on how to address this? Thanks! |
You first need to actually create the producer before starting up the listeners. So it's not enough to put in the at_exit block, you actually have to initialize the producer there by calling |
Hm? are you saying it's actually the same |
Hmm... now that I'm looking at it I think you're right. It would be stored in thread variables and sharing the object reference wouldn't share the producer. I'm not sure why I've never come across this, because we also do producing inside our consumers. 😮 I'm down for a PR to add a callback before a listener shuts down so you can add code to shut down your producers there. |
cool, yeah, callback sounds better than looping the OpenSpace.
btw, back the original question in 1), do you know what's the downside if we don't close the connection? I think broker may still close the idle connection after certain time? |
Yeah I don't know of any ramifications of not closing the producer. I think you're right, the broker should kill the extra one after some time. |
btw, I reviewed this today and realize I made a mistake: on_worker_shutdown only has access to worker context, each worker could have multiple threads and seems impossible to shutdown the producer in this case |
Hi phobos team,
By reading the current code, it would only close the producer when
@producer_enable
:phobos/lib/phobos/listener.rb
Lines 115 to 118 in c953492
This assumes we have a class that extends both Listener and Producer. In our code, we have something like:
..and it has been used in the consumer/listener, but didn't get closed when we reboot the consumer.
OpenSpace
find all the classes that inherit Phobos::Producer and close them?Thanks!
The text was updated successfully, but these errors were encountered: