Jump to content

API time out & subsequent wait time


Sailaboat

Recommended Posts

Posted

Is there any point in piling on? Indicating that I am also in the fraction-of-a-percent non-functional group?

 

7155bb6b-c587-425c-b668-234f8b765dcc.jpg

 

There's very much a point to it! Looks like the "fraction-of-a-percent" is growing! As for "non-functional", well, I'll likely still be that even after this gets fixed.

Posted

Add me to the list ... We're leaving for Vancouver Island first thing tomorrow morning. After the initial 900 or so downloaded caches, the message "Api response: "The number of calls allowed for this Method has been exceeded". GSAK will now wait for 1 minute and try again." shows at least 12 times and then times out. As previous cachers mentioned it's babysitting at the computer as I have to manually restart the api again. I really hope that Groundspeak will find a solution soon.

Posted
.. I am not seeing the time-outs (or whatever they are) when pulling down GSAK rectangles...

 

try an 'refresh cache data' on your database (see msg #7 in this thread) and watch what happens after 900 caches...

None of my rectangles reach 900. I believe the count on my largest one is around 750.

and that is why you probably don't see the problem. My smaller db's are okay, my bigger ones definitely show the problem.

Posted

A local cacher offered to bring by a bottle of Maker's Mark if the devs will fix this ASAP. Needless to say, they are working feverishly on the issue! :)

Well heck, if I knew the devs ran on alcohol, I'd have sent some good Canadian beer down to Seattle a long time ago! :laughing:

Posted

None of my rectangles reach 900. I believe the count on my largest one is around 750.

and that is why you probably don't see the problem. My smaller db's are okay, my bigger ones definitely show the problem.

It would seem so. Some of my current rectangles are somewhat bound by maximum 62.1 area issues, and I've limited the others to avoid going over 1000. At present, they look like this, with the largest checking in at 766 (presently):

 

Northern Colorado 40.77,-105.21 40.00,-104.45 186 05/07/14

 

Northwest of Denver 40.00,-105.33 39.75,-104.80 280 05/07/14

 

Northeast of Denver 40.00,-104.80 39.75,-104.45 368 05/07/14

 

NW Denver 39.75,-105.27 39.63,-104.90 702 05/07/14

 

NE Denver 39.75,-104.90 39.63,-104.65 766 05/07/14

 

SW Denver 39.63,-105.20 39.53,-104.92 614 05/14/14

 

SE Denver 39.63,-104.92 39.53,-104.65 705 05/14/14

 

Deep S Denver 39.53,-105.11 39.40,-104.65 515 05/14/14

Posted

The issue should now be fixed (it appears to have been related to a time mismatch on some of the servers). Please check and let us know if you continue to see issues.

Standby while we all hammer the API... :laughing:

Posted

Woohoo, it's fixed! I just did a "full" refresh of ~2000 caches in GSAK, and it motored through with no pauses in exactly 4 minutes.

 

I'm glad to hear it was a relatively simple fix. Please pass along our heartfelt thanks to the devs for dealing with it. Try not to let them get too drunk from the bourbon... :laughing:

Posted

The issue should now be fixed (it appears to have been related to a time mismatch on some of the servers). Please check and let us know if you continue to see issues.

 

My found database just did a status check without a problem.

 

Snoopy-Happy-Dance-230x300_zps7b3bf698.jpg

 

Pass our thanks on to the engineering team and the unnamed cacher bearing gifts of Makers Mark. Unfortunately, or is it fortunately ?, we now know the engineering team can be bought for the right price. :)

Posted

The issue should now be fixed (it appears to have been related to a time mismatch on some of the servers). Please check and let us know if you continue to see issues.

 

Wow - full speed again!

 

Thanks! Please tell us upfront next time which beverage we need to sent to Seattle to get something fixed :-)

Posted

The issue should now be fixed (it appears to have been related to a time mismatch on some of the servers). Please check and let us know if you continue to see issues.

 

High 5 to the devs , it seems to be working as expected again !

 

Thanks for getting this fixed !

Posted

The issue should now be fixed (it appears to have been related to a time mismatch on some of the servers). Please check and let us know if you continue to see issues.

Wow, the servers times drifted several minutes apart. Better turn that clock synchronization on.

 

Thanks for getting this resolved!

Posted

Now that I've put my eyes back into their sockets and picked my jaw up off the floor, I can reply to this.

Moun10Bike: Thank you. Seriously. You could have swept this under the forum's carpet, but you stuck with it for us. I really appreciate that. Could you also please let the devs know how much their response and fix is appreciated.

I have a 4000+ DB to load up, but have been putting that off for days. As soon as I get back to the office later tonight I'll excitedly give that a try. My favourite hobby is fun again!

Thank you!

Posted

it appears to have been related to a time mismatch on some of the servers

Okay, I have to ask, Don't you have NTP running on your servers if time is a critical thing? I seem to remember another problem a while back caused by mismatched time. I could never imagine running my unix servers without NTP running and I'm sure windows has a version.

Posted

NTP had gotten corrupted and it took time for the mismatch to grow large enough to become noticed. This was made more difficult by the large number of servers and configs that we have throughout the system. The team is now investigating and looking to set up monitors to prevent such a thing from happening again.

Posted

NTP had gotten corrupted and it took time for the mismatch to grow large enough to become noticed. This was made more difficult by the large number of servers and configs that we have throughout the system. The team is now investigating and looking to set up monitors to prevent such a thing from happening again.

Thanks for the reply, I appreciate it.

Posted (edited)

I encountered some intermittent API timeouts and API is sometimes extreem slow when doing a "refresh cache data" in GSAK.

 

One API call took about +- 30 sec (normally 5 to 10 sec)

 

Please have a look.

Edited by DanPan
Posted (edited)

When writing this post i have issues with the API in GSAK.

 

Impossible to fetch my api limits, membership type or "refresh cache data":

 

Fetching api limits

Previous request ended in error, now doing a retry.... 1/1

... no response after 40 seconds

Retry requested by user

... no response after 40 seconds

Previous request ended in error, now doing a retry.... 1/1

... no response after 40 seconds

Retry requested by user

... no response after 40 seconds

Previous request ended in error, now doing a retry.... 1/1

... no response after 40 seconds

Retry requested by user

... no response after 40 seconds

Previous request ended in error, now doing a retry.... 1/1

... no response after 40 seconds

Retry requested by user

 

Fetching membership type

... no response after 40 seconds

Previous request ended in error, now doing a retry.... 1/1

... no response after 40 seconds

Retry requested by user

... no response after 40 seconds

Previous request ended in error, now doing a retry.... 1/1

... no response after 40 seconds

Retry requested by user

... no response after 40 seconds

Previous request ended in error, now doing a retry.... 1/1

 

Generating GPX file

... no response after 40 seconds

Previous request ended in error, now doing a retry.... 1/1

... no response after 40 seconds

Retry requested by user

... no response after 40 seconds

Previous request ended in error, now doing a retry.... 1/1

 

Fetching user name

... no response after 40 seconds

Previous request ended in error, now doing a retry.... 1/1

... no response after 40 seconds

Retry requested by user

Edited by DanPan
Posted

It seems my access token was not valid anymore.

I just ran into this too.

 

Here's my situation:

2 GSAK installations

2 Geocaching.com accounts on each

=4 total tokens

 

Both tokens on one of the GSAK installations have become invalid, while the others are fine. I can't think of any logical reason why only those two tokens would become invalid. They weren't the oldest. They do get used often. Why are actively-used tokens being invalidated?

Posted

I saw the problem pop up again yesterday too after a long period of not seeing it. GSAK throttles on it's own so it's rare to see that problem again. I doubt that the normal call/min were exceeded :-/

Posted (edited)

I'm having that issue right now. Haven't been able to load my PQ's or publish logs to gc.com via gsak since last night. I also got 2 script errors every time I opened a new log page.

Edited by hikerT

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...