Random Time Outs / Resets When Exchanging OAuth Code for Token

Matt Topper

unread,

May 24, 2017, 7:56:21 PM5/24/17

to Untappd API Developer Group

Hey Untappd Team,

For the last 9 months we've been seeing on a semi-regular / random basis resets coming from the Untappd servers when exchanging the OAuth Code for a token. Everything else is fine, just when we do this exchange. I've attached our Squid proxy log of the behavior to this message. I was wondering if anyone else has been seeing this behavior. I know a lot of people just use the direct keys but this seems to be when we're doing an exchange for a user log in specifically.

Thanks in advance,

Matt

squid_log_snippet.rtf

Greg Avola

unread,

May 24, 2017, 8:20:29 PM5/24/17

to untappd-api-d...@googlegroups.com

Hey Matt,

What do you mean resets? Anything in particular about these timeouts that we can replicate?

Greg

Sent from my iPhone

--
You received this message because you are subscribed to the Google Groups "Untappd API Developer Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to untappd-api-develop...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

<squid_log_snippet.rtf>

Matt Topper

unread,

May 24, 2017, 8:24:26 PM5/24/17

to untappd-api-d...@googlegroups.com

Specifically we are getting connection resets from the untappd servers. It's only happening on the token exchange. We have replicated on developer desktops and in AWS so it doesn't seem to be source / hosting provider related.

On May 24, 2017 8:20 PM, "Greg Avola" <gr...@untappd.com> wrote:

Hey Matt,

What do you mean resets? Anything in particular about these timeouts that we can replicate?

Greg

Sent from my iPhone

On May 24, 2017, at 7:56 PM, Matt Topper <ma...@pombe.com> wrote:

Hey Untappd Team,
For the last 9 months we've been seeing on a semi-regular / random basis resets coming from the Untappd servers when exchanging the OAuth Code for a token. Everything else is fine, just when we do this exchange. I've attached our Squid proxy log of the behavior to this message. I was wondering if anyone else has been seeing this behavior. I know a lot of people just use the direct keys but this seems to be when we're doing an exchange for a user log in specifically.

Thanks in advance,
Matt

--
You received this message because you are subscribed to the Google Groups "Untappd API Developer Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to untappd-api-developer-group+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

<squid_log_snippet.rtf>

--
You received this message because you are subscribed to a topic in the Google Groups "Untappd API Developer Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/untappd-api-developer-group/ImBFmiD2TQo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to untappd-api-developer-group+unsub...@googlegroups.com.

Greg Avola

unread,

May 25, 2017, 9:16:48 AM5/25/17

to untappd-api-d...@googlegroups.com

How can you replicate it? What are the steps?

Greg

Sent from my iPhone

To unsubscribe from this group and stop receiving emails from it, send an email to untappd-api-develop...@googlegroups.com.

Matt Topper

unread,

May 30, 2017, 9:29:10 AM5/30/17

to untappd-api-d...@googlegroups.com

Hey Greg,

When going through Squid, as a forward proxy, something fails at the Untappd side and our app gets a connection reset.

The timeouts sometimes seemed to happen on our desktop and within our app.

To duplicate, goto https://test.pombe.com/enjoy, create an account or login, open the menu and select account settings, goto accounts, and then Link and Unlink the Untappd account. Sometimes it will work, sometimes it will not. It seems to work for awhile and then stop for awhile. I do not have a pattern but normally if it works, within an hour or so it stops working.

From the back end, the link action (which is what will fail) redirects the user to the Untappd oauth server for an oauth code, then when we get the code back we try to exchange it for the token. This token exchange API is the one that fails...

On Thu, May 25, 2017 at 9:16 AM, Greg Avola <gr...@untappd.com> wrote:

How can you replicate it? What are the steps?

Greg

Sent from my iPhone

On May 24, 2017, at 8:24 PM, Matt Topper <ma...@pombe.com> wrote:

Specifically we are getting connection resets from the untappd servers. It's only happening on the token exchange. We have replicated on developer desktops and in AWS so it doesn't seem to be source / hosting provider related.

On May 24, 2017 8:20 PM, "Greg Avola" <gr...@untappd.com> wrote:

Hey Matt,

What do you mean resets? Anything in particular about these timeouts that we can replicate?

Greg

Sent from my iPhone

On May 24, 2017, at 7:56 PM, Matt Topper <ma...@pombe.com> wrote:

Hey Untappd Team,
For the last 9 months we've been seeing on a semi-regular / random basis resets coming from the Untappd servers when exchanging the OAuth Code for a token. Everything else is fine, just when we do this exchange. I've attached our Squid proxy log of the behavior to this message. I was wondering if anyone else has been seeing this behavior. I know a lot of people just use the direct keys but this seems to be when we're doing an exchange for a user log in specifically.

Thanks in advance,
Matt

--
You received this message because you are subscribed to the Google Groups "Untappd API Developer Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to untappd-api-developer-group+unsubs...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

<squid_log_snippet.rtf>

--
You received this message because you are subscribed to a topic in the Google Groups "Untappd API Developer Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/untappd-api-developer-group/ImBFmiD2TQo/unsubscribe.

To unsubscribe from this group and all its topics, send an email to untappd-api-developer-group+unsubs...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Untappd API Developer Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to untappd-api-developer-group+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Greg Avola

unread,

May 30, 2017, 9:39:36 AM5/30/17

to untappd-api-d...@googlegroups.com

Those logs that you sent, show the DNS fails to resolve, is that what you are seeing?

Greg

To unsubscribe from this group and stop receiving emails from it, send an email to untappd-api-developer-group+unsubs...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Untappd API Developer Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/untappd-api-developer-group/ImBFmiD2TQo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to untappd-api-developer-group+unsubs...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Untappd API Developer Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to untappd-api-developer-group+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Greg Avola

Co-Founder / CTO

Untappd

gr...@untappd.com

Matt Topper

unread,

May 30, 2017, 10:17:27 AM5/30/17

to untappd-api-d...@googlegroups.com

No, that's a cache miss for DNS on the first call of the day for us (yeah TTL). The file I sent didn't really give the info you needed. Here is the text we're seeing...the line to care about is:

2017/05/24 10:24:19.234| tunnel.cc(342) copy: Nothing to write or client gone. Terminate the tunnel.

It's showing the Untappd server terminating the connection with nothing to return. I can give you the full in depth log of the request/response from beginning to end if you want it.

2017/05/24 10:24:19.234| AsyncCall.cc(30) make: make call TunnelBlindCopyReadHandler [call103]

2017/05/24 10:24:19.234| cbdata.cc(510) cbdataReferenceValid: cbdataReferenceValid: 0x7f208054d8f8

2017/05/24 10:24:19.234| tunnel.cc(295) readClient: local=127.0.0.1:3128 remote=127.0.0.1:60201 FD 8 flags=1, read 0 bytes, err=0

2017/05/24 10:24:19.234| tunnel.cc(316) copy: from={local=127.0.0.1:3128 remote=127.0.0.1:60201 FD 8 flags=1}, to={local=172.31.4.141:57263 remote=166.78.193.77:443 FD 10 flags=1}

2017/05/24 10:24:19.234| cbdata.cc(419) cbdataInternalLock: cbdataLock: 0x7f208054d8f8=7

2017/05/24 10:24:19.234| cbdata.cc(419) cbdataInternalLock: cbdataLock: 0x7f208054d8f8=8

2017/05/24 10:24:19.234| cbdata.cc(419) cbdataInternalLock: cbdataLock: 0x7f208054d8f8=9

2017/05/24 10:24:19.234| AsyncCall.cc(18) AsyncCall: The AsyncCall tunnelTimeout constructed, this=0x7f208054d400 [call109]

2017/05/24 10:24:19.234| cbdata.cc(419) cbdataInternalLock: cbdataLock: 0x7f208054d8f8=10

2017/05/24 10:24:19.234| cbdata.cc(456) cbdataInternalUnlock: cbdataUnlock: 0x7f208054d8f8=9

2017/05/24 10:24:19.234| cbdata.cc(456) cbdataInternalUnlock: cbdataUnlock: 0x7f208054d8f8=8

2017/05/24 10:24:19.234| comm.cc(773) commSetConnTimeout: local=127.0.0.1:3128 remote=127.0.0.1:60201 FD 8 flags=1 timeout 900

2017/05/24 10:24:19.234| cbdata.cc(456) cbdataInternalUnlock: cbdataUnlock: 0x7f208054d8f8=7

2017/05/24 10:24:19.234| cbdata.cc(419) cbdataInternalLock: cbdataLock: 0x7f208054d8f8=8

2017/05/24 10:24:19.234| cbdata.cc(419) cbdataInternalLock: cbdataLock: 0x7f208054d8f8=9

2017/05/24 10:24:19.234| AsyncCall.cc(18) AsyncCall: The AsyncCall tunnelTimeout constructed, this=0x7f2080550f70 [call110]

2017/05/24 10:24:19.234| cbdata.cc(419) cbdataInternalLock: cbdataLock: 0x7f208054d8f8=10

2017/05/24 10:24:19.234| cbdata.cc(456) cbdataInternalUnlock: cbdataUnlock: 0x7f208054d8f8=9

2017/05/24 10:24:19.234| cbdata.cc(456) cbdataInternalUnlock: cbdataUnlock: 0x7f208054d8f8=8

2017/05/24 10:24:19.234| comm.cc(773) commSetConnTimeout: local=172.31.4.141:57263 remote=166.78.193.77:443 FD 10 flags=1 timeout 900

2017/05/24 10:24:19.234| cbdata.cc(456) cbdataInternalUnlock: cbdataUnlock: 0x7f208054d8f8=7

2017/05/24 10:24:19.234| tunnel.cc(342) copy: Nothing to write or client gone. Terminate the tunnel.

2017/05/24 10:24:19.234| comm.cc(1102) _comm_close: comm_close: start closing FD 8

2017/05/24 10:24:19.234| comm.cc(760) commUnsetFdTimeout: Remove timeout for FD 8

2017/05/24 10:24:19.234| cbdata.cc(456) cbdataInternalUnlock: cbdataUnlock: 0x7f208054d8f8=6

2017/05/24 10:24:19.234| comm.cc(955) commCallCloseHandlers: commCallCloseHandlers: FD 8

2017/05/24 10:24:19.234| comm.cc(963) commCallCloseHandlers: commCallCloseHandlers: ch->handler=0x7f208054d6e0*1

2017/05/24 10:24:19.234| AsyncCall.cc(85) ScheduleCall: comm.cc(964) will call SomeCloseHandler(FD -1, data=0x7f208054d8f8) [call67]

2017/05/24 10:24:19.234| comm.cc(963) commCallCloseHandlers: commCallCloseHandlers: ch->handler=0x7f208097cbd0*1

2017/05/24 10:24:19.234| AsyncCall.cc(85) ScheduleCall: comm.cc(964) will call ConnStateData::connStateClosed(FD -1, data=0x7f208097d218) [call63]

2017/05/24 10:24:19.234| AsyncCall.cc(18) AsyncCall: The AsyncCall comm_close_complete constructed, this=0x7f208054d400 [call111]

2017/05/24 10:24:19.234| AsyncCall.cc(85) ScheduleCall: comm.cc(1178) will call comm_close_complete(FD 8) [call111]

2017/05/24 10:24:19.234| comm.cc(1102) _comm_close: comm_close: start closing FD 10

2017/05/24 10:24:19.234| comm.cc(760) commUnsetFdTimeout: Remove timeout for FD 10

2017/05/24 10:24:19.234| cbdata.cc(456) cbdataInternalUnlock: cbdataUnlock: 0x7f208054d8f8=5

2017/05/24 10:24:19.234| ModEpoll.cc(139) SetSelect: FD 10, type=1, handler=0, client_data=0, timeout=0

2017/05/24 10:24:19.234| IoCallback.cc(108) finish: called for local=172.31.4.141:57263 remote=166.78.193.77:443 FD 10 flags=1 (-10, 0)

2017/05/24 10:24:19.234| AsyncCall.cc(85) ScheduleCall: IoCallback.cc(127) will call TunnelBlindCopyReadHandler(local=172.31.4.141:57263 remote=166.78.193.77:443 FD 10 flags=1, flag=-10, data=0x7f208054d8f8, size=0, buf=0x7f208098dbe0) [call108]

2017/05/24 10:24:19.234| comm.cc(955) commCallCloseHandlers: commCallCloseHandlers: FD 10

2017/05/24 10:24:19.234| comm.cc(963) commCallCloseHandlers: commCallCloseHandlers: ch->handler=0x7f2080550360*1

2017/05/24 10:24:19.234| AsyncCall.cc(85) ScheduleCall: comm.cc(964) will call SomeCloseHandler(FD -1, data=0x7f208054d8f8) [call74]

2017/05/24 10:24:19.234| AsyncCall.cc(18) AsyncCall: The AsyncCall comm_close_complete constructed, this=0x7f2080550f70 [call112]

2017/05/24 10:24:19.234| AsyncCall.cc(85) ScheduleCall: comm.cc(1178) will call comm_close_complete(FD 10) [call112]

2017/05/24 10:24:19.234| cbdata.cc(456) cbdataInternalUnlock: cbdataUnlock: 0x7f208054d8f8=4

2017/05/24 10:24:19.234| AsyncCallQueue.cc(53) fireNext: leaving TunnelBlindCopyReadHandler(local=127.0.0.1:3128 remote=127.0.0.1:60201 flags=1, data=0x7f208054d8f8, size=0, buf=0x7f208097dbd0)

2017/05/24 10:24:19.234| cbdata.cc(456) cbdataInternalUnlock: cbdataUnlock: 0x7f208054d8f8=3

2017/05/24 10:24:19.234| AsyncCallQueue.cc(51) fireNext: entering SomeCloseHandler(FD -1, data=0x7f208054d8f8)

2017/05/24 10:24:19.234| AsyncCall.cc(30) make: make call SomeCloseHandler [call67]

2017/05/24 10:24:19.234| cbdata.cc(510) cbdataReferenceValid: cbdataReferenceValid: 0x7f208054d8f8

2017/05/24 10:24:19.234| tunnel.cc(168) tunnelClientClosed: local=127.0.0.1:3128 remote=127.0.0.1:60201 flags=1

2017/05/24 10:24:19.234| tunnel.cc(185) tunnelStateFree: tunnelState=0x7f208054d8f8

2017/05/24 10:24:19.234| cbdata.cc(348) cbdataInternalFree: cbdataFree: 0x7f208054d8f8

2017/05/24 10:24:19.234| cbdata.cc(360) cbdataInternalFree: cbdataFree: 0x7f208054d8f8 has 3 locks, not freeing

2017/05/24 10:24:19.234| AsyncCallQueue.cc(53) fireNext: leaving SomeCloseHandler(FD -1, data=0x7f208054d8f8)

2017/05/24 10:24:19.234| cbdata.cc(456) cbdataInternalUnlock: cbdataUnlock: 0x7f208054d8f8=2

2017/05/24 10:24:19.234| AsyncCallQueue.cc(51) fireNext: entering ConnStateData::connStateClosed(FD -1, data=0x7f208097d218)

2017/05/24 10:24:19.234| AsyncCall.cc(30) make: make call ConnStateData::connStateClosed [call63]

2017/05/24 10:24:19.234| cbdata.cc(510) cbdataReferenceValid: cbdataReferenceValid: 0x7f208097d218

2017/05/24 10:24:19.234| AsyncJob.cc(117) callStart: ConnStateData status in: [ job2]

2017/05/24 10:24:19.235| cbdata.cc(510) cbdataReferenceValid: cbdataReferenceValid: 0x7f208097d218

2017/05/24 10:24:19.235| AsyncJob.cc(49) deleteThis: ConnStateData will NOT delete in-call job, reason: ConnStateData::connStateClosed

2017/05/24 10:24:19.235| cbdata.cc(510) cbdataReferenceValid: cbdataReferenceValid: 0x7f208097d218

2017/05/24 10:24:19.235| AsyncJob.cc(131) callEnd: ConnStateData::connStateClosed(FD -1, data=0x7f208097d218) ends job [Stopped, reason:ConnStateData::connStateClosed job2]

2017/05/24 10:24:19.235| client_side.cc(778) swanSong: local=127.0.0.1:3128 remote=127.0.0.1:60201 flags=1

To unsubscribe from this group and stop receiving emails from it, send an email to untappd-api-developer-group+unsubs...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

--

Greg Avola
Co-Founder / CTO
Untappd

gr...@untappd.com

--

You received this message because you are subscribed to a topic in the Google Groups "Untappd API Developer Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/untappd-api-developer-group/ImBFmiD2TQo/unsubscribe.

To unsubscribe from this group and all its topics, send an email to untappd-api-developer-group+unsub...@googlegroups.com.

Reply all

Reply to author

Forward