Skip to content
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

Way of checking if all message are sent out #228

Open
ssukienn opened this issue Feb 16, 2022 · 2 comments
Open

Way of checking if all message are sent out #228

ssukienn opened this issue Feb 16, 2022 · 2 comments

Comments

@ssukienn
Copy link

ssukienn commented Feb 16, 2022

Hi.

I wonder if there is some approach using this lib to check whether all messages published on the channel/connection were already sent out. In other words, if message queues are empty. And if we can await it.

Thanks

@jwalton
Copy link
Owner

jwalton commented Feb 16, 2022

publish() returns a promise which will resolve when the message is sent, so if you could do something like:

const promises = [];
promises.push(chan.publish(...));
promises.push(chan.publish(...));
promises.push(chan.publish(...));

// Wait until all messages are sent, or one message has failed
await Promise.all(promises);

@ssukienn
Copy link
Author

Oh, I get that, I could describe context better. I wonder if that would be possible from the library side to expose its promises or some behavior that would expose it more like executor queue?

My scenario is that I could emit messages from different not interconnected places so it would be hard for me to capture all of msg promises. But I would have access to connection/channel.
Let's assume that the application is handling lots of "parallel" logic during which it publishes messages to the connection manager.
Then there comes a point in time that I decide that I am not expecting to send any more messages (or they are not relevant for me):
a) and the first time the manager queue is empty I would like to block on it or be notified (ofc it might never be empty, so I would block indefinitely or with some timeout?).
b) more advanced mechanism would be not allowing the new messages to be published to queue but I am still very much interested to send all that are still there without rejecting them

It is a little similar concept to ThreadExecutor in Java.

Personally, I am more interested with a) as I actually know that I won't block indefinitely in my scenario but probably something more versatile would be more useful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants