Pages: [1] :: one page |
|
Author |
Thread Statistics | Show CCP posts - 2 post(s) |
June Ting
Valkyries of Night Of Sound Mind
84
|
Posted - 2014.07.10 15:48:00 -
[1] - Quote
When I make calls to /corp/Locations.xml.aspx and /corp/StarbaseDetail.xml.aspx with a properly permissioned corp API key, approximately 4 out of every 1000 calls executed to those endpoints fail with error code 221 ('Illegal page request! Please verify the access granted by the key you are using!'). The errors are sporadic, and do not have any correlation with any specific arguments passed to the calls. I am using an API key that I control and have not touched the permissions for, so I am confident I have permission with that key.
Furthermore, these errors are set to be cacheable for a full day rather than being transient with <1h allowed before retry according to the response, causing my POS management application to grind to a halt for an entire day unless I manually blow away my cache like a bad citizen and reissue the query before the 1 day expiration is up. If I do that, the call immediately succeeds and returns the correct result.
I am using the EVELink library, which I also am a maintainer of -- the library does properly utilize caching, and respects the expiry/cache lengths returned by the EVE API.
I believe there may be an intermittent fault between the API servers and the datastore maintaining information on API key permissions. The easy fix that would make my life infinitely easier is simply to make the Error Code 221 condition only be cacheable for 15 minutes rather than for an entire day, and should require no additional debugging.
However, a 0.4% error rate is still non-ideal. I fight for the freedom of my people. |
|
CCP FoxFour
C C P C C P Alliance
3367
|
Posted - 2014.07.10 17:02:00 -
[2] - Quote
Hey thanks for the information. We had a report of this from Steve on the CSM. From what we can tell nothing relating to this has changed on the API front. Any chance you know when this started? Any more information you can offer would be greatly appreciated. I am still away on vacation but will pass this thread on to others. CCP FoxFour // Game Designer // @regnerba
|
|
Ydnari
Estrale Frontiers Project Wildfire
341
|
Posted - 2014.07.10 17:12:00 -
[3] - Quote
I reported this months ago and it's continuing to be a problem, seems to have got worse recently. On mobile so tricky to find my previous post.
Affects many endpoints not just the ones OP mentioned. my teapot is ready |
Jeronica
Tackled In Belt xXPlease Pandemic Citizens Reloaded Alliance.Xx
344
|
Posted - 2014.07.10 19:46:00 -
[4] - Quote
I'll add some code to get better diagnostic data as well on my site. I've had a few instances where it would error, and then my site automatically stops pulling the API for 24h (because the error cache time was 24h). It's happened to quite a few of my users. EVE-Mogul: https://www.eve-mogul.com CEO/Programmer Trade Profit Tracking Service |
June Ting
Valkyries of Night Of Sound Mind
85
|
Posted - 2014.07.10 21:49:00 -
[5] - Quote
Ydnari wrote:I reported this months ago and it's continuing to be a problem, seems to have got worse recently. On mobile so tricky to find my previous post.
Affects many endpoints not just the ones OP mentioned. Yes - I'm not saying it's limited to those endpoints, but those endpoints get called 10-20+ times per run of my app whereas I only hit the other endpoints once, so the chance of a failure on those endpoints cumulatively over time is much higher than on other endpoints that I call less often.
I do not know when it started, but it's been happening for the entire two weeks I've been working on this application, which is the first application I've written against the API that needs to repeatedly poll to fetch info on dozens of objects anchored in space (and thus increased the chance of seeing the error). I fight for the freedom of my people. |
Dragonaire
Here there be Dragons
55
|
Posted - 2014.07.11 01:18:00 -
[6] - Quote
June Ting - I long ago in Yapeal learned to ignore the cacheUntil times on the API because 90% of them make no sense especially on the errors. I just retry in 5 mins and usually things will have cleared up and can continue normally. I use the currentTime and just add the known cache times as well because of the many times in the past when there's been problems.
Just from watching my logs in the past I've guessed that the problem is a single front end server losses connection or something but resets itself within a few minutes. It might even be cause by normal maintenance work and someone just getting stuff out of sync but it's something that been a problem off and on with APIs for years. Finds camping stations from the inside much easier. Designer of Yapeal-á for Eve API. Check out the Yapeal PHP Library thread for more information. |
qu1ckkkk
The Warp Core Stabilizers Tactical Narcotics Team
6
|
Posted - 2014.07.11 04:34:00 -
[7] - Quote
Dragonaire wrote:June Ting - I long ago in Yapeal learned to ignore the cacheUntil times on the API because 90% of them make no sense especially on the errors.
Can't say this is a good idea but hey :D In SeAT there is some grace logic that will retry again for a few times and eventually 'give up' and ban the broken call.
I can concur with the OP though that the 221 error occurs very sporadically. It is especially bad on the endpoints listed above however I have experienced this on other calls too for which nothing has changed on the keys as well. As far as debugging goes, the only thing that really helped has been the 'try again later', which is why people would probably resort to things like ignoring the explicit requirement for cachedUntil. Simple Corporation Management: http://eve-seat.github.io/seat/ |
|
CCP FoxFour
C C P C C P Alliance
3372
|
Posted - 2014.07.11 07:45:00 -
[8] - Quote
If there are specific pages or cache timers that make no sense please let me know. I will attempt to fix them. I have fixed a few already. CCP FoxFour // Game Designer // @regnerba
|
|
June Ting
Valkyries of Night Of Sound Mind
85
|
Posted - 2014.07.11 14:01:00 -
[9] - Quote
If you make the Error 221 not cache for 24h and instead only cache for somewhere between 5 and 15 minutes, that would solve the problem in the OP. I fight for the freedom of my people. |
Squizz Caphinator
Happy Endings.
169
|
Posted - 2014.07.11 14:25:00 -
[10] - Quote
This happens with KillLog requests on zKB as well as character requests on SkillQ.
On zkb, In the last hour, zKB has experienced 157 requests that resulted in a 221. Subsequent calls with the same API will work.
And this happens on SkillQ all the time. A perfectly valid API request results in a 221 error code.
I cannot provide any details on how to reproduce the problem as it seems quite random. Various projects I enjoy putting my free time into: http://zkillboard.com | http://evewho.com | http://eve-kill.net | http://evechatter.com | http://skillq.net |
|
Lors Dornick
Kallisti Industries Solar Assault Fleet
1110
|
Posted - 2014.07.11 14:34:00 -
[11] - Quote
CCP FoxFour wrote:Hey thanks for the information. We had a report of this from Steve on the CSM. Good to hear that Stevie is doing the job we hoped many of us hoped he'd do when voting for him ;) CCP Greyscale: As to starbases, we agree it's pretty terrible, but we don't want to delay the entire release just for this one factor.
|
June Ting
Valkyries of Night Of Sound Mind
85
|
Posted - 2014.07.11 16:54:00 -
[12] - Quote
Lors Dornick wrote:CCP FoxFour wrote:Hey thanks for the information. We had a report of this from Steve on the CSM. Good to hear that Stevie is doing the job we hoped many of us hoped he'd do when voting for him ;) Actually, IIRC FoxFour made an error in attribution and this problem was reported by Ali Aras. :) I fight for the freedom of my people. |
Ydnari
Estrale Frontiers Project Wildfire
341
|
Posted - 2014.07.11 18:17:00 -
[13] - Quote
June Ting wrote:If you make the Error 221 not cache for 24h and instead only cache for somewhere between 5 and 15 minutes, that would solve the problem in the OP. It would certainly greatly improve the situation in lieu of a fix to the underlying problem. my teapot is ready |
|
|
|
Pages: [1] :: one page |
First page | Previous page | Next page | Last page |