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

GOAWAY session_timed_out #81

Closed
asgoel opened this issue Aug 1, 2017 · 8 comments
Closed

GOAWAY session_timed_out #81

asgoel opened this issue Aug 1, 2017 · 8 comments

Comments

@asgoel
Copy link
Contributor

asgoel commented Aug 1, 2017

When using the FCM workers, I see a decent number of the GOT GOAWAY, NO_ERROR logs (which it seems like the worker code is aware of). Just wondering what the cause of this is and if there's a way I can mitigate it?

@hpopp
Copy link
Member

hpopp commented Aug 1, 2017

In the process of fixing on the reconnect-fix branch. FCM likes to close connections after a few minutes or so, which creates an infinite loop of reconnects (and eventually maxes out CPU).

New intended behavior:
FCM workers will gracefully drop the connection on close and only attempt to connect when there are new pushes to send. This will wipe the existing queue and reset stream IDs, but I think these disconnects are happening due to inactivity, so there shouldn't be pending pushes anyway.

@cstar

@asgoel
Copy link
Contributor Author

asgoel commented Aug 1, 2017

shouldn't we just make the default ping period lower then?

@hpopp
Copy link
Member

hpopp commented Aug 1, 2017

Tried variations down to 5 minutes with no luck. I'm not sure it respects pings, or when it does, GOAWAY, ENHANCE_YOUR_CALM, too_many_pings start showing up in the logs. The connection intervals seem to get shorter with every subsequent reconnect, and right about 45 minutes after the initial connection it's closing and reconnecting so fast it overloads everything.

@asgoel
Copy link
Contributor Author

asgoel commented Aug 1, 2017

Interesting... Dumb question, but I can't find any official documentation on whether FCM supports HTTP/2. Is this just an enhancement you've tried to make, and thus why we are running into so many problems?

@hpopp
Copy link
Member

hpopp commented Aug 1, 2017

@cstar wrote the initial implementation. The API works fine except for the reconnect issue, which I'm guessing is due to FCM servers not wanting to persist socket connections until the API is public.

I didn't discover it until I started rolling out onto some staging servers this morning. I should have the patch up pretty soon.

hpopp added a commit that referenced this issue Aug 1, 2017
Reconnects FCM socket only on subsequent pushes after a disconnect.
Prevents infinite reconnect loop.
@hpopp hpopp closed this as completed in 46fb94f Aug 1, 2017
@0x6e6562
Copy link

@hpopp I'm seeing this sporadically using pigeon 1.1.0 (c0d18bf) and kabadra 0.3.2 (d7afbcfa):

[error] Got GOAWAY, NO_ERROR, Last Stream: 0, Rest: session_timed_out

With various different stream ids.

Should I be looking into the details of this, or is the session time out just business as usual?

@hpopp
Copy link
Member

hpopp commented Oct 13, 2017

FCM closes the connection after idling for a minute or two. No big deal, it just reopens the next time a push is sent.

I should probably have Kadabra disable logging by default.

@0x6e6562
Copy link

Thanks for the heads up - there doesn't appear to be any material impact on message delivery in any case, so we can just treat this as an ignorable log message.

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

3 participants