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

Add callback to signal successful publish #511

Open
lthibault opened this issue Dec 6, 2022 · 2 comments
Open

Add callback to signal successful publish #511

lthibault opened this issue Dec 6, 2022 · 2 comments

Comments

@lthibault
Copy link
Contributor

lthibault commented Dec 6, 2022

On several occasions, I have found myself wanting to know exactly when a particular call to Topic.Publish has written the message to the wire. This is either because of some business logic (e.g. wait until peers have been signaled before doing something) or because I want to pool the []byte argument in high-throughput applications.

From an API perspective, this would ideally take the form of a PubOpt, allowing us to write:

err := t.Publish(ctx, data, WithCallback(func(m *Message) {
    pool.Put(m.Data)  // sync.Pool
})

The main difficulty I'm seeing is that messages are fanned out to a number of peers via buffered channels, so this would likely require some kind of refcounting scheme to ensure the callback is not called prematurely.

Is this a sensible ask? Any recommendations?

@vyzo
Copy link
Collaborator

vyzo commented Dec 6, 2022

From an api perspective, i wouldnt say no if we had an implementation, as it is indeed quite useful.

On the same time this really isnt straightforward to implement, there are complexities with dropped messages etc.

I guess we could put a barrier in the Message struct and invoke it when (if we can do that reliably) we are done sending or dropping. Probably a 1-buffer channel better than a callback, as it solves thread ownership issues.

I will be happy to review and ultimately merge a pr if you can come up with something reasonable.

@lthibault
Copy link
Contributor Author

lthibault commented Dec 6, 2022

Sounds like a plan.

Do you have any thoughts on how a barrier might be implemented? Are you thinking sync.WaitGroup?

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