Return to Question

In developing the firehose service, I found that the /events API often "pauses" for a couple of minutes before resuming. Is this a known issue?

Specifically, I am polling /events every 10 seconds using a custom filter with all fields turned on. I'm using the since parameter to ask for only events that are newer than the most recent one received so far. I'll always get at least one previously seen event back (and ignore it because I've already seen it). The numbers I'm getting every 10 seconds look something like (count of new events):

..., 8, 1, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 42, 4, 1, 3, ...
..., 2, 5, 7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 38, 4, 4, 2, ...

It appears that the events that were not sent during the quiet period are all sent after the flow resumes.

I do recognise the backoff element but I'm not receiving any of those.

In developing the firehose service, I found that the /events API often "pauses" for a couple of minutes before resuming. Is this a known issue?

Specifically, I am polling /events every 10 seconds using a custom filter with all fields turned on. I'm using the since parameter to ask for only events that are newer than the most recent one received so far. I'll always get at least one previously seen event back (and ignore it because I've already seen it). The numbers I'm getting every 10 seconds look something like (count of new events):

..., 8, 1, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 42, 4, 1, 3, ...
..., 2, 5, 7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 38, 4, 4, 2, ...

It appears that the events that were not sent during the quiet period are all sent after the flow resumes.

I do recognise the backoff element but I'm not receiving any of those.