API time out & subsequent wait time

April 20, 2014

I use the geocaching program "GSAK". I'm running the latest version 8.4.1.32 on a Windows 7 box.

I have several small GSAK databases (with 25 - 70) caches for geographically isolated areas e.g. an Island.

With the 5 Pocket Query/day threshold, I don't feel like running a PQ for these small databases. Instead, GSAK has a feature whereby you can update logs real time through the geocaching.com API.

I believe for performance purposes the API has a limit (not sure if it's time or volume of data based) whereby the API "takes a break" for a minute prior to the next pull of data.

Just prior to the major upgrade at Groundspeak a few weeks ago, I noticed that the API cycled twice before resuming the data pull. I.e. it would count down from 59 seconds, briefly flash as though it was resuming the data pull, and then count down for an additional minute prior to resuming the data pull. It was taking a 2 minute break.

I posted a message in the GSAK forums. One of the moderators suggested the additional cycle might go away with the Groundspeak upgrade.

Well it hasn't gone away. In fact it's added one more cycle to the time out. So API time out cycles three times now, for a total of 3 minutes prior to resuming the data pull.

Is the API "working as designed" or is this a defect?

Thanks in advance.

7.4k · April 21, 2014

The API will only allow 30 logs per call and 30 calls per minute (so, 900 logs per minute). I'm not sure what GSAK might be doing that leads to three successive 1-minute countdowns before resuming, but it sounds like Clyde might need to contact our devs to work out what the issue might be.

April 23, 2014

Thanks for the speedy response.

I have posted the response on the GSAK forums, and will wait for a response. Unfortunately, Clyde had a cyling accident recently, which resulted in him ending up in the hospital with some broken bones. Full recovery is expected, however, he'll be off-line for a little while.

Cheers,

Sailaboat

May 9, 2014

This is not a GSAK only problem. GDAK has the same problem. The GetMoreGeocaches call seems to have an extra restriction although the API still reports that 30 calls per minute are allowed.

May 10, 2014

The LonelyCache web application is seeing this issue too. I have fairly detailed logs of when all the transactions occur. Here's a summary (times are EDT) of SearchForGeocaches requests:

First call made after 05/07/14 04:59:18.858, but before 05/07/14 04:59:19.716

30th call made after 05/07/14 05:00:08.827, but before 05/07/14 05:00:09.732

31st call made after 05/07/14 05:00:20.013, but before 05/07/14 05:00:20.200 with Status 140

The number of calls allowed for this Method has been exceeded

32nd call made after 05/07/14 05:01:30.309, but before 05/07/14 05:01:30.512 with Status 140

33rd call made after 05/07/14 05:02:40.621, but before 05/07/14 05:02:40.808 with Status 140

34th call made after 05/07/14 05:03:50.917, but before 05/07/14 05:03:51.104 with Status 140

35th call made after 05/07/14 05:05:01.229, but before 05/07/14 05:05:01.416 with Status 140

36th call made after 05/07/14 05:06:11.541, but before 05/07/14 05:06:11.759 with Status 140

37th call made after 05/07/14 05:07:21.868, but before 05/07/14 05:07:22.960 with Status 0, success.

Basically, the 31st call was made about 60.5 seconds after the first call. From there, the call was retried about 70 seconds later six times before success, or just over 8 minutes from the first call.

This behavior doesn't occur all the time. I have not looked to see how frequently it occurs.

Edited May 10, 2014 by Corfman Clan

May 10, 2014

When the problem occurs the API returns strange values:

<GetGeocacheDataResponse xmlns="http://www.geocaching.com/Geocaching.Live/data" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"><Status><StatusCode>140</StatusCode><StatusMessage>The number of calls allowed for this Method has been exceeded</StatusMessage><ExceptionDetails/><Warnings/></Status><Geocaches xmlns:a="http://schemas.datacontract.org/2004/07/Tucson.Geocaching.WCF.API.Geocaching.Types"/><PQCount>0</PQCount><CacheCodes xmlns:a="http://schemas.microsoft.com/2003/10/Serialization/Arrays"/><CacheLimits xmlns:a="http://schemas.datacontract.org/2004/07/Groundspeak.API.AuthorizationLib"><a:CachesLeft>2147483647</a:CachesLeft><a:CurrentCacheCount>2147483647</a:CurrentCacheCount><a:MaxCacheCount>2147483647</a:MaxCacheCount></CacheLimits></GetGeocacheDataResponse>

May 10, 2014

I started a "refresh cache data" of my GSAK database.

After exactly 900 caches i received a final message "The number of calls allowed for this Method has been exceeded" and the process stopped although my full format balance was 5100.

...

11/05/2014 1:47:33 api call was successful

11/05/2014 1:47:42 api call was successful

11/05/2014 1:47:51 api call was successful

11/05/2014 1:48:05 api call was successful

11/05/2014 1:48:15 api call was successful

11/05/2014 1:48:24 api call was successful

11/05/2014 1:48:34 api call was successful

11/05/2014 1:48:43 api call was successful

11/05/2014 1:48:57 api call was successful

11/05/2014 1:49:10 api call was successful

Api response: "The number of calls allowed for this Method has been exceeded". GSAK will now wait for 1 minute and try again.

Retry requested by user

Api response: "The number of calls allowed for this Method has been exceeded". GSAK will now wait for 1 minute and try again.

11/05/2014 1:56:18 api call was successful

11/05/2014 1:56:27 api call was successful

11/05/2014 1:56:37 api call was successful

11/05/2014 1:56:46 api call was successful

11/05/2014 1:56:58 api call was successful

11/05/2014 1:57:07 api call was successful

11/05/2014 1:57:16 api call was successful

11/05/2014 1:57:26 api call was successful

11/05/2014 1:57:39 api call was successful

11/05/2014 1:57:48 api call was successful

11/05/2014 1:57:57 api call was successful

11/05/2014 1:58:07 api call was successful

11/05/2014 1:58:16 api call was successful

11/05/2014 1:58:25 api call was successful

11/05/2014 1:58:34 api call was successful

11/05/2014 1:58:47 api call was successful

11/05/2014 1:58:56 api call was successful

11/05/2014 1:59:05 api call was successful

11/05/2014 1:59:14 api call was successful

11/05/2014 1:59:24 api call was successful

11/05/2014 1:59:35 api call was successful

11/05/2014 1:59:47 api call was successful

11/05/2014 1:59:57 api call was successful

11/05/2014 2:00:07 api call was successful

11/05/2014 2:00:17 api call was successful

11/05/2014 2:00:27 api call was successful

11/05/2014 2:00:36 api call was successful

11/05/2014 2:00:50 api call was successful

11/05/2014 2:01:00 api call was successful

11/05/2014 2:01:10 api call was successful

Api response: "The number of calls allowed for this Method has been exceeded". GSAK will now wait for 1 minute and try again.

Retry requested by user

11/05/2014 15:26:48 api call was successful

11/05/2014 15:28:05 api call was successful

11/05/2014 15:29:12 api call was successful

11/05/2014 15:30:17 api call was successful

11/05/2014 15:31:35 api call was successful

11/05/2014 15:32:53 api call was successful

11/05/2014 15:34:15 api call was successful

11/05/2014 15:35:30 api call was successful

11/05/2014 15:36:45 api call was successful

11/05/2014 15:38:10 api call was successful

11/05/2014 15:39:01 api call was successful

11/05/2014 15:39:57 api call was successful

11/05/2014 15:40:46 api call was successful

11/05/2014 15:41:47 api call was successful

11/05/2014 15:42:39 api call was successful

11/05/2014 15:43:29 api call was successful

11/05/2014 15:43:51 api call was successful

11/05/2014 15:44:06 api call was successful

11/05/2014 15:44:20 api call was successful

11/05/2014 15:44:41 api call was successful

11/05/2014 15:44:52 api call was successful

11/05/2014 15:45:07 api call was successful

11/05/2014 15:45:21 api call was successful

11/05/2014 15:45:39 api call was successful

11/05/2014 15:45:52 api call was successful

11/05/2014 15:46:08 api call was successful

11/05/2014 15:46:17 api call was successful

11/05/2014 15:46:30 api call was successful

11/05/2014 15:46:39 api call was successful

11/05/2014 15:46:51 api call was successful

11/05/2014 15:47:01 api call was successful

11/05/2014 15:47:10 api call was successful

11/05/2014 15:47:23 api call was successful

11/05/2014 15:47:40 api call was successful

11/05/2014 15:47:55 api call was successful

11/05/2014 15:48:04 api call was successful

11/05/2014 15:48:14 api call was successful

11/05/2014 15:48:25 api call was successful

11/05/2014 15:48:38 api call was successful

11/05/2014 15:48:50 api call was successful

11/05/2014 15:49:01 api call was successful

Api response: "The number of calls allowed for this Method has been exceeded". GSAK will now wait for 1 minute and try again.

11/05/2014 15:52:16 api call was successful

11/05/2014 15:52:25 api call was successful

11/05/2014 15:52:36 api call was successful

11/05/2014 15:52:50 api call was successful

11/05/2014 15:53:02 api call was successful

11/05/2014 15:53:21 api call was successful

11/05/2014 15:53:42 api call was successful

11/05/2014 15:53:58 api call was successful

11/05/2014 15:54:12 api call was successful

11/05/2014 15:54:36 api call was successful

11/05/2014 15:54:50 api call was successful

11/05/2014 15:55:08 api call was successful

11/05/2014 15:55:23 api call was successful

11/05/2014 15:55:35 api call was successful

11/05/2014 15:55:51 api call was successful

11/05/2014 15:56:05 api call was successful

11/05/2014 15:56:15 api call was successful

11/05/2014 15:56:31 api call was successful

11/05/2014 15:56:44 api call was successful

11/05/2014 15:56:55 api call was successful

11/05/2014 15:57:10 api call was successful

11/05/2014 15:57:21 api call was successful

11/05/2014 15:57:31 api call was successful

11/05/2014 15:57:43 api call was successful

11/05/2014 15:58:00 api call was successful

11/05/2014 15:58:22 api call was successful

11/05/2014 15:58:42 api call was successful

11/05/2014 15:58:56 api call was successful

11/05/2014 15:59:18 api call was successful

11/05/2014 15:59:35 api call was successful

Api response: "The number of calls allowed for this Method has been exceeded". GSAK will now wait for 1 minute and try again.

Retry requested by user

11/05/2014 17:40:11 api call was successful

11/05/2014 17:40:27 api call was successful

11/05/2014 17:40:46 api call was successful

11/05/2014 17:40:58 api call was successful

Edited May 11, 2014 by DanPan

5.7k · May 11, 2014

Had a friend using GSAK that complained about this exact issue to me today. FWIW, his handle on gc.com is CoBiker.

Thus far, it hasn't beat me up, but it may be something transient.

May 11, 2014

Api using is almost inpossible now. Please give us a working api back or a good solution how to use the api optimal.

Edited May 11, 2014 by Jurgen & co

2.1k · May 11, 2014

Same issue. .

RequestHeader: POST /LiveV6/Geocaching.svc/CreateFieldNoteAndPublish HTTP/1.1

StartSendingRequest: 1126

PercentDone: 100

HttpInfo: Begin reading response

Api response: "The number of calls allowed for this Method has been exceeded". GSAK will now wait for 1 minute and try again.

HttpRequestBegin: POST,api.Groundspeak.com:443/LiveV6/Geocaching.svc/CreateFieldNoteAndPublish

RequestHeader: POST /LiveV6/Geocaching.svc/CreateFieldNoteAndPublish HTTP/1.1

StartSendingRequest: 1126

PercentDone: 100

HttpInfo: Begin reading response

Api response: "The number of calls allowed for this Method has been exceeded". GSAK will now wait for 1 minute and try again.

Edited May 11, 2014 by Maingray

8.3k · May 11, 2014

more of the same

Status check

05/11/2014 2:44:35 PM api call was successful

05/11/2014 2:44:37 PM api call was successful

05/11/2014 2:44:39 PM api call was successful

05/11/2014 2:44:41 PM api call was successful

05/11/2014 2:44:44 PM api call was successful

05/11/2014 2:44:46 PM api call was successful

05/11/2014 2:44:48 PM api call was successful

05/11/2014 2:44:50 PM api call was successful

05/11/2014 2:44:52 PM api call was successful

05/11/2014 2:44:54 PM api call was successful

05/11/2014 2:44:56 PM api call was successful

05/11/2014 2:44:58 PM api call was successful

05/11/2014 2:45:01 PM api call was successful

05/11/2014 2:45:03 PM api call was successful

05/11/2014 2:45:05 PM api call was successful

05/11/2014 2:45:07 PM api call was successful

05/11/2014 2:45:09 PM api call was successful

05/11/2014 2:45:11 PM api call was successful

05/11/2014 2:45:13 PM api call was successful

05/11/2014 2:45:15 PM api call was successful

05/11/2014 2:45:18 PM api call was successful

05/11/2014 2:45:20 PM api call was successful

05/11/2014 2:45:22 PM api call was successful

05/11/2014 2:45:24 PM api call was successful

05/11/2014 2:45:26 PM api call was successful

05/11/2014 2:45:28 PM api call was successful

05/11/2014 2:45:30 PM api call was successful

05/11/2014 2:45:33 PM api call was successful

05/11/2014 2:45:35 PM api call was successful

05/11/2014 2:45:37 PM api call was successful

Api response: "The number of calls allowed for this Method has been exceeded". GSAK will now wait for 1 minute and try again.

Retry requested by user

Api response: "The number of calls allowed for this Method has been exceeded". GSAK will now wait for 1 minute and try again.

Retry requested by user

Api response: "The number of calls allowed for this Method has been exceeded". GSAK will now wait for 1 minute and try again.

At this point I'm pretty well dead since about all that happens is waiting for the timeouts to expire. Something changed, and it seems like it is Groundspeak. Clyde has been in the hospital/Rehab since April 13 so not much changing in the GSAK world. The problems started showing up shortly after the aborted API update on April 27. Not only GSAK users are reporting problems but a GDAK user reported a problem and rcorfman reported a problem with his website using the API.

May 11, 2014

I agree that it appears to be a Groundspeak problem.

I log a good number of finds at once using GSAK, and get caught in the "The number of calls allowed for this Method has been exceeded" problem. It's annoying to have to sit in front of computer and "Retry" often. I should be able to walk away and let it do its thing. Also, when pulling into GSAK a large DB of caches, I get the same thing about every 900 caches. Very annoying. Don't know why Groundspeak would punish us like this.

8.3k · May 11, 2014

I agree that it appears to be a Groundspeak problem.

I log a good number of finds at once using GSAK, and get caught in the "The number of calls allowed for this Method has been exceeded" problem. It's annoying to have to sit in front of computer and "Retry" often. I should be able to walk away and let it do its thing. Also, when pulling into GSAK a large DB of caches, I get the same thing about every 900 caches. Very annoying. Don't know why Groundspeak would punish us like this.

I'm going to give GS the benefit and assume that there was a change to the API that had unintended consequences. We'll see what happens next week.

4.6k · May 12, 2014

This "error" is getting annoying. I logged 17 caches on Saturday evening with two TBs visiting each cache. I used GSAK 8.4.1.32 and got the "The number of calls allowed for this Method has been exceeded" message after about 10-12 caches. I can hardly believe that logging just 17 caches would trigger an API "overload message".

Logging 10 caches + 2 TB visits each went without a glitch on sundayevening.

On the other hand, a statuscheck on 18000 caches went smooth this morning with occasional messages and automatic resumes after waiting a few minutes.

7.8k · May 12, 2014

Not only is there a problem with the API, it's getting worse. At first, I was only experiencing the mentioned behaviour with one of two accounts I've been doing cache refreshes with using GSAK. Now my other account is starting to get the same thing.

Please get engineering to look into this. The problem is on the Groundspeak side.

7.4k · May 12, 2014

I notified engineering of this issue over the weekend. They are investigating.

7.8k · May 12, 2014

I notified engineering of this issue over the weekend. They are investigating.

Thanks Moun10Bike!

May 12, 2014

I notified engineering of this issue over the weekend. They are investigating.

:like:

May 12, 2014

I notified engineering of this issue over the weekend. They are investigating.

Thank you!!! I'm eagerly looking forward to their tweaking!

May 13, 2014

Driving me crazy too! Hope there is a resolution soon.

6k · May 13, 2014

There are several (if not many) threads on this issue. Maybe we need a specific forum topic to cluster them in until the problem is solved. And if the throttling is from insufficient bandwidth at the servers it could be some time.

May 13, 2014

Driving me crazy too! Hope there is a resolution soon.

same here - really frustating

Please do something soon - or should we send you food for the hamsters again? ;-)

May 13, 2014

It does appear that engineering did indeed get their hands on this situation over the weekend. It's gotten worse. I just finished logging 25 finds and it took 45 minutes! Never imagined the thought of getting Smiley's would give me a frown.

8.3k · May 13, 2014

So has engineering managed to prioritize the problem and do they have a guesstimate on when it will be fixed?

7.4k · May 13, 2014

The API issues appear to be related to memcache behavior that is specific to our production servers and is not occurring on our test servers. It would thus seem to be a configuration issue on production. The team is investigating, but has been stretched thin with various releases and other projects. I know that this issue is very frustrating to those who depend on it, and it has been aggravating to me as well as I try to keep my GSAK database up to date. However, in investigating we have determined that the issue actually only affects a tiny subset of our user base and there are work-arounds (waiting longer between attempts), so it is therefore considered moderately important as opposed to critically important.

7.8k · May 13, 2014

...we have determined that the issue actually only affects a tiny subset of our user base...

Darn, I guess I'm just one of the unlucky ones. One of my accounts' API access is nearly unusable, while the other is usable but slower than normal.

Oh well, at least they've identified where the problem lies. Here's hoping they can find a fix quickly for those of us in the tiny subset. Thanks for the update!

8.3k · May 14, 2014

The API issues appear to be related to memcache behavior that is specific to our production servers and is not occurring on our test servers. It would thus seem to be a configuration issue on production. The team is investigating, but has been stretched thin with various releases and other projects. I know that this issue is very frustrating to those who depend on it, and it has been aggravating to me as well as I try to keep my GSAK database up to date. However, in investigating we have determined that the issue actually only affects a tiny subset of our user base and there are work-arounds (waiting longer between attempts), so it is therefore considered moderately important as opposed to critically important.

Thanks for the reply. Does not sound encouraging for a quick fix, but maybe since it bugs you maybe you can keep the focus for the API guys. You got to get more of the API guys converted to GSAK users.

The only problem with the "workaround" is that as a GSAK user we do not have access to the internal timing for waiting between attempts. So the "workaround" is not a workaround but an excuse.

As for only a small set of users I seem to remember that comment when the Google Earth Viewer was removed because only a few used it.

Edited May 14, 2014 by jholly

5k · May 14, 2014

It does appear that engineering did indeed get their hands on this situation over the weekend. It's gotten worse. I just finished logging 25 finds and it took 45 minutes! Never imagined the thought of getting Smiley's would give me a frown.

Yes, things seems to have degraded. The api has been a very interactive experience for me since yesterday morning. I basically have to babysit it. 30 calls, 3 3 minute timeouts, then an error, which I can respond to, to continue what used to be a seamless process.

I'm trying to not be overly critical here, but we have been told that PQ and search development on the web site has been rolled back in an effort to develop the api for the third party partners to provide these services. Currently, I can't use my third party app, (GSAK), to get the status of the caches in my db because of the constant errors.

If the issue is that too many GSAK users are placing too many calls on the server, then get with Clyde. I'm sure that he can roll out an update that throttles things on his applications end.

5k · May 14, 2014

Wow!

I just read Moun10bike's response. I guess in the big scheme of things, millions of accounts that only log caches for a few days and then quit is more important than those that go out daily and find and hide caches, and have done so for years?

I'm sorry Jon, but you have told us in the past that the PQ and advanced search features were on the back burner in favor of offering the third party partners these features through the api. The fact that the api is now almost completely useless to me, makes this a critical issue, not a moderate one.

Please don't take my message personal, I realize that you are our very important conduit between us and those guys that can make a difference. While this issue may only affect a low percentage of Geocachers, it may be true that this low percentage are finding and logging the higher percentage of Geocaches.

May 14, 2014

Just to add another unhappy user of GSAK here. But now I know that I can only update 900 caches at a time since I thought it was 1000. But mine seems to want to wait 10 mins before it will work again. So the server is not letting me in.

May 14, 2014

Same problem happen to me. I wonder how long I can keep baby-sit

May 14, 2014

Same here. Run some API calls, wait 1 minute, wait 1 minute, wait 1 minute, reply to the GSAK error message. It seems that it always happens after 30 API calls. I've even tried pausing the GSAK macro for a few seconds after every few API calls and it still happens after 30 API calls. I understand you know what the problem is. Please fix it.

4.6k · May 14, 2014

However, in investigating we have determined that the issue actually only affects a tiny subset of our user base

I think you underestimate the number of people affected. The majority of users is not active on this forum so many more may have problems and never report them here. Then there are people using local forums (because of language barriers) where this problem is discussed, again, you don't see them here but rest assured people are complaining about the API on Belgian and Dutch forums too. Of course, there are threads on the GSAK forum also.

Doing a status check this morning (7 UTC) on 14000 caches made me hit the "retry" button 15-20 times even with GSAK waiting 3x1 minute by itself. This means that status checks and cache refreshes can no longer be done unattended.

May 14, 2014

And yet a disgruntled user. Please eliminate the error quickly.

I could make better use of my time than to wait for the next "Retry".

Edited May 14, 2014 by Cool-Mann

May 14, 2014

However, in investigating we have determined that the issue actually only affects a tiny subset of our user base

I think you underestimate the number of people affected. The majority of users is not active on this forum so many more may have problems and never report them here. Then there are people using local forums (because of language barriers) where this problem is discussed, again, you don't see them here but rest assured people are complaining about the API on Belgian and Dutch forums too. Of course, there are threads on the GSAK forum also.

Doing a status check this morning (7 UTC) on 14000 caches made me hit the "retry" button 15-20 times even with GSAK waiting 3x1 minute by itself. This means that status checks and cache refreshes can no longer be done unattended.

+1 ! I've been struggling with this problem aswell , we need to get this fixed urgently For the moment , i make my wait times in the macros longer and longer so it even seems the problem is getting worse !

2.3k · May 14, 2014

Add my name to the list of those seriously affected by this timeout problem. I used to be able to use the API (via GSAK) to refresh the data on my unfound caches database in less than 20 minutes and not have to hover over the computer responding to error messages. It now takes an hour and a half or more to refresh the same data, and requires that I babysit the entire process to respond to timeout messages.

I agree with the others, this does not affect "a tiny subset of our user base", and there are no workarounds that avoid having to sit at the PC and monitor the entire long process.

Groundspeak, according to their own proclamations, is putting their development resources into the API, as opposed to pocket queries and Web-based access to information. Where are those resources when we really need them?

--Larry

2k · May 14, 2014

One more member of the "tiny subset" checking in.

This long-time member will take a fix to the API over any new function you are working to roll out.

Maybe fixing the configuration error isn't "critically" important...but it's pretty important to any GSAK user using the API.

May 14, 2014

One more member of the "tiny subset" checking in.

This long-time member will take a fix to the API over any new function you are working to roll out.

Maybe fixing the configuration error isn't "critically" important...but it's pretty important to any GSAK user using the API.

Maybe fixing the configuration error isn't "critically" important...but it's pretty important to any GSAK user using the API.

Not all affected users use GSAK...

May 14, 2014

Normally I see no profit in reporting problems that have already been reported by many before me. But now that is said that the number of problems /reports is also an argument for getting a better functioning API, I add my vote. It's a really annoying problem.

May 14, 2014

Same here! We are going to holiday next week and I wanted to quickly prepare caches for several countries. What was planned to take just few hours is now processing into days! Seriously, I have better stuff to do than hanging around in front of my laptop. :sad:

7.8k · May 14, 2014

Well, it's definitely getting progressively worse. In my last post, I said that only one of two accounts was basically unusable. Now the other one is too. For the last few days, it had been doing the 3x one-minute waits, but didn't pop up the "Abort/Retry/Fail"-type dialog and would at least continue on automatically after doing the waits. Now it's getting that error dialog too, which means babysitting.

I'm curious how it was determined that only a "tiny subset" of the user base is affected? Based on the number of reports received? Only one of many servers has the problem? It's sounding more and more like it's a pretty big "tiny".

I also thought yesterday about what others have posted regarding the push toward API use, but I didn't say anything myself. I think I will now.

Just to remind everyone, this was posted in October of 2012:

Update of GPX schema is no longer in the planning. It's a fairly "old school" way of delivering cache data. We are instead focused on improving the API to deliver data in more customized formats, and an overhaul of the search functionality is a major step toward that.

It has been mentioned a few times since then that development would focus on the API as the primary method of cache-info delivery. With that push from GSHQ's side, I think it's understandable that the users will expect the API to work, and to be supported when it isn't working. Therefore, prioritizing a malfunctioning API as "moderately important" doesn't look very good when taken in the context of the above. It sounds something like "Don't use the old method, use this new one instead, but if it doesn't work properly, we don't really care".

Sorry, but that's just how it looks from this side. If there isn't enough manpower to support what's already in place, then Jeremy and management need to sit down and figure out what needs to be done to get that manpower. Clearly, the current level is inadequate based on the length of time some problems fester. If it means a modest increase in membership fees, I'll happily pay it to get a functioning website and API.

4.6k · May 14, 2014

If it means a modest increase in membership fees, I'll happily pay it to get a functioning website and API.

Membership fees are already increased, at least for us EU members (US$41 at today's rate). :mad:

5.7k · May 14, 2014

I'm wondering what Moun10Bike may have meant by "a tiny subset of our user base", because I am not seeing the time-outs (or whatever they are) when pulling down GSAK rectangles. All are running to completion in their usual chunks of 30 at a time without any abnormal hesitation. On RARE occasions, I have in recent times seen a 'Stored search error' or similar, but not often.

May 14, 2014

.. 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...

May 14, 2014

The API issues appear to be related to memcache behavior that is specific to our production servers and is not occurring on our test servers. It would thus seem to be a configuration issue on production. The team is investigating, but has been stretched thin with various releases and other projects. I know that this issue is very frustrating to those who depend on it, and it has been aggravating to me as well as I try to keep my GSAK database up to date. However, in investigating we have determined that the issue actually only affects a tiny subset of our user base and there are work-arounds (waiting longer between attempts), so it is therefore considered moderately important as opposed to critically important.

This differently is not a moderate problem for me. I have been a premium member for 7 years and when it starts to take me an hour to log only 48 caches via the GSAK publish log function, something that I should be able to do in about 5 minutes, then it might be time to start thinking about making a change in my membership and wives membership. The API is broken and needs to be fixed.

Edited May 14, 2014 by Lt.Ranger.Bob

May 14, 2014

The API issues appear to be related to memcache behavior that is specific to our production servers and is not occurring on our test servers. It would thus seem to be a configuration issue on production. The team is investigating, but has been stretched thin with various releases and other projects. I know that this issue is very frustrating to those who depend on it, and it has been aggravating to me as well as I try to keep my GSAK database up to date. However, in investigating we have determined that the issue actually only affects a tiny subset of our user base and there are work-arounds (waiting longer between attempts), so it is therefore considered moderately important as opposed to critically important.

Moderator:

Thank you for listening and responding. You're the only conduit we have to affect change.

Is the issue not enough resources to fix the problem? I to would be willing to pay more for a product that actually works, than for one that doesn't. As long as that increase comes after the solution has been implemented, or at least embarked upon, rather than just being a political promise.

Is the issue one of priority? The API issue affects a broader spectrum of users than is excused for. Even if that is debated, and probably will be, those who fit into the opinion of a "tiny subset" would be those performing a sizable percentage of activity on GC.com.

Please don't give up on us Moderator!

Community:

The idea of "work-arounds" confuses me. "Waiting longer between attempts" as a work-around is precisely the reason we need a solution. We don't need more of the same. Has anyone been able to "work-around" this problem in some other way? Is there a different way to convince the "hamsters" that a fix is required? Maybe a bigger wheel? :laughing:

7.4k · May 14, 2014

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!

2.3k · May 15, 2014

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!

Works for me, as long as those devs fix the glitch before celebrating with that Maker's Mark. I can only imagine what this Web site might look like otherwise. :lol:

--Larry

May 15, 2014

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!

Seriously!!??? They're "working feverishly on the issue"? THANK YOU!!! You're not just teasing are you? <_<

If the engineers do indeed fix this, forget about Maker's Mark, I'll bring by a bottle of Single Malt for everyone. Then we'll have a real good time at this year's Block Party.

5.7k · May 15, 2014

.. 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.

API time out & subsequent wait time

Recommended Posts

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment