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

libs/pubsub: use non-blocking send when dispatching messages #1880

Closed
zramsay opened this issue Jul 3, 2018 · 2 comments
Closed

libs/pubsub: use non-blocking send when dispatching messages #1880

zramsay opened this issue Jul 3, 2018 · 2 comments
Assignees
Labels
C:libs Component: Library T:bug Type Bug (Confirmed) T:perf Type: Performance
Milestone

Comments

@zramsay
Copy link
Contributor

zramsay commented Jul 3, 2018

original issue: tendermint/tmlibs#153

see ^ for extensive discussion

@zramsay zramsay added the C:libs Component: Library label Jul 3, 2018
@xla xla added T:bug Type Bug (Confirmed) T:perf Type: Performance labels Jul 8, 2018
@xla xla added this to the launch milestone Jul 8, 2018
@melekes
Copy link
Contributor

melekes commented Oct 2, 2018

Re The slow subscriber problem

This is an exciting topic for discussion.

Option 1

On one hand, we have blocking send current implementation:

func (state *state) send(msg interface{}, tags TagMap) {
    for q, clientToChannelMap := range state.queries {
        if q.Matches(tags) {
            for _, ch := range clientToChannelMap {
                ch <- msg
            }
        }
    }
}

If there's slow subscriber, all other subscribers must wait.

Jae's thoughts: #951 (comment)

Option 2

Non-blocking send

for _, ch := range clientToChannelMap {
        select {
        case ch <- msg:
        default:
            // implement retry logic, or probably just do nothing,
            // drop the message for this subscriber on this query
            // it seems fair if it couldn't keep up with its buffer
        }
    }

If there's a slow client, others do not wait because we skip it. The problem here is that slow client does not know it had missed the message and this can be a source of potentially hidden&hardtofind bugs.

melekes added a commit that referenced this issue Oct 2, 2018
melekes added a commit that referenced this issue Oct 4, 2018
melekes added a commit that referenced this issue Oct 4, 2018
melekes added a commit that referenced this issue Nov 1, 2018
melekes added a commit that referenced this issue Nov 2, 2018
* pubsub adr

Refs #951, #1879, #1880

* highlight question

* fix typos after Ismail's review
@ebuchman ebuchman modified the milestones: v1.0, v0.30.0 Jan 13, 2019
@melekes melekes self-assigned this Jan 29, 2019
@melekes melekes mentioned this issue Feb 23, 2019
4 tasks
@ebuchman
Copy link
Contributor

Done in #3227! Pubsub now uses non-blocking sends on buffered subscriptions (still blocks for explicility unbuffered subscriptions)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C:libs Component: Library T:bug Type Bug (Confirmed) T:perf Type: Performance
Projects
None yet
Development

No branches or pull requests

4 participants