Jump to content

API time out & subsequent wait time


Sailaboat

Recommended Posts

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.

Link to comment

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

Link to comment

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 by Corfman Clan
Link to comment

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.

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

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.

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

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.

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

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.

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

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.

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

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 by DanPan
Link to comment

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 by Maingray
Link to comment

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.

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

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.

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

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

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.

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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

Link to comment

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 by jholly
Link to comment

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.

Link to comment

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.

Link to comment

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

Link to comment
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.

Link to comment
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 !

Link to comment

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

Link to comment

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

Link to comment

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.

Link to comment

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! :o Seriously, I have better stuff to do than hanging around in front of my laptop. :sad:

Link to comment

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.

Link to comment

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.

Link to comment

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 by Lt.Ranger.Bob
Link to comment

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:

Link to comment

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

Link to comment

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.

Link to comment
.. 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.
Link to comment

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