1

I'm experiencing some unexpected errors while trying to subscribe on Podio Push service. I use golang concurrency pattern defined here and here is the bayeux client library used for subscription.

Basically the flow tries to retrieve the item first and then subscribe into push object provided with the item object. There is channel object where i store each task (taskLoad: ~each item_id with credentials it needs for retrieval)

item := new(podio.Item)
item, err = podio.GetItem(itemId)
if err != nil {
    log.Errorf("PODIO", "Could not get item %d -> %s", itemId, err)

    return
}

and, later inside another func

messages := make(chan *bayeux.Message)
server := GetBayeux()
defer server.Close()

if err = push.Subscribe(server, messages); err != nil {
    // log err, with item details
    log.Errorf("PODIO", "%s", err, push)

    // re-enqueue the task in taskLoad channel
    go enqueueTask(true, messages, sigrepeat, timer)

    // release sigwait channel on subscription error
    <-sigwait

    return
}

here GetBayeux func is just a singleton which wraps the client

func GetBayeux() *bayeux.Client {
    bayeuxOnce.Do(func() {
        Bayeux = bayeux.NewClient("https://push.podio.com/faye", nil)
    })

    return Bayeux
}

there is about ~15000 items to listen and I should subscribe to each of them but unfortunately sometimes I got one of these errors while processing subscriptions

401:k9jx3v4qq276k9q84gokpqirhjrfbyd:Unknown client [{"channel":"/item/9164xxxxx","signature":"46bd8ab3ef2a31297d8f4f5ddxxxx","timestamp":"2018-01-02T14:34:02Z","expires_in":21600}]

OR

HTTP Status 400 [{"channel":"/item/9158xxxxx","signature":"31bf8b4697ca2fda69bd7fd532d08xxxxxx","timestamp":"2018-01-02T14:37:02Z","expires_in":21600}]

OR

[WRN] Bayeux connect failed: HTTP Status 400

OR

Bayeux connect failed: Post https://push.podio.com/faye: http2: server sent GOAWAY and closed the connection; LastStreamID=1999, ErrCode=NO_ERROR, debug=""

So now, i'd like to know why i got these errors and most of all how i can fix them to ensure to listen to all items in the scope.

If anyone knows, is there any limitation about concurrent access into podio push service?

Thanks

UPDATE 2019-01-07

it was the singleton that messed the process. as it was in a goroutine context there was some subscriptions that was not allowed because the server has been closed by another goroutine. The fix was to exposing Unsubscribe method and use it instead of Close method which disconnect the client from the server.

defer server.Close()

became

defer push.Unsubscribe(server)

Community
  • 1
  • 1
irzhy
  • 920
  • 1
  • 9
  • 15
  • Aren't this regular errors that can happen if instances on podio.com restart or the network has a glitch? Shouldn't you simply be able to recover from those situations? And how often is "sometimes"? – thst Jan 03 '19 at 12:59
  • here "sometimes" is like 10% maybe or little more among all of 15000. when i try the same codes with less number of items, it seems to be free of these errors. what i implemented so far is a [retry flow](https://upgear.io/blog/simple-golang-retry-function) to repeat the subscription until no errors but i think it would be better to avoid the errors instead – irzhy Jan 03 '19 at 13:12
  • the question is indeed, if these errors are created by you, subscribing to 15000 items, or if there is a problem in the client. Since the 4xx errors are often created from the server, there maybe is an issue with the amount of subscriptions. Maybe open an incident with podio? – thst Jan 03 '19 at 13:42
  • glad you found your issue, maybe you want to update your question with an "Update:" section to present the working solution. – thst Jan 07 '19 at 13:31

0 Answers0