These are chat archives for fanout/pushpin

Oct 2018
Justin Karneges
Oct 26 2018 16:01
@yukw777 pretty much. it rate limits the outgoing messages so pushpin doesn't get overwhelmed with output processing. this is mainly an issue if you broadcast to thousands of clients at the same time, causing pushpin cpu to max out
Justin Karneges
Oct 26 2018 16:07
when message_rate is non-zero, then message_hwm comes into effect which is how many pending messages to buffer. if you're losing messages it's because you had more than message_hwm messages queued up due to the rate limiting
by default, message_rate=2500 and message_hwm=25000, so if you were losing messages with default settings then they were queued up for over 10 seconds. I don't recommend setting message_rate=0 to disable this stuff. instead, tune the params and operate within their boundaries
Peter Yu
Oct 26 2018 16:34
ok makes sense

@jkarneges from the websocket over http example from go-gripcontrol, I noticed this:

    body, _ := ioutil.ReadAll(request.Body)
    inEvents, err := gripcontrol.DecodeWebSocketEvents(string(body))
    if err != nil {
        panic("Failed to decode WebSocket events: " + err.Error())

    if inEvents[0].Type == "OPEN" {

Is there ever a case where inEvents may have more than one element, i.e. could pushpin ever send out an http request with more than one websocket event?

Justin Karneges
Oct 26 2018 18:20
@yukw777 yup. there is only one request per connection at any time (to ensure in-order delivery) and so events from the client may get buffered and the next request could have multiple TEXT events for example