EVE Search - API Cache timers

All Channels

EVE Technology Lab

API Cache timers

» Click here to find additional results for this topic using Google

Monitor this thread via RSS [?]

Pages: [1] :: one page
Author	Thread Statistics \| Show CCP posts - 4 post(s)
Chibisuke Gallente Children of Avalon	Posted - 2010.11.02 21:47:00 - [1] Weren't the API Cache timers surposed to be fixed so they're reliable now? well SkillQueue API returns a cache timers of 10 Years... is that a misplaces april fool or something?
Catari Taga Centre Of Attention Middle of Nowhere	Posted - 2010.11.02 22:16:00 - [2] That's happening so often that my API code is automatically shortening every cachedUntil > 24h down to 1h. --
Vessper Indicium Technologies	Posted - 2010.11.02 22:27:00 - [3] Also noticed that the CharacterSheet API has had the cache time increased from 1h to 5h 57m. Intentional? EveHQ Character App
Catari Taga Centre Of Attention Middle of Nowhere	Posted - 2010.11.02 22:48:00 - [4] Originally by: Vessper Also noticed that the CharacterSheet API has had the cache time increased from 1h to 5h 57m. Intentional? the 57m thing happens on many API calls but not all. If it was all I'd say it's intentional so people can run 1h cron jobs regardless of local clock inaccuracy but since it's not on all it's probably just some server's clock is off in CCP's cluster. I did bug report the 6h thing. Also AccountStatus has bogus paidUntil values, Medals has no cache time at all anymore, StarbaseDetail has 2m20, it's all a bit funky atm. --
Matalok Dreddit Test Alliance Please Ignore	Posted - 2010.11.03 08:45:00 - [5] Originally by: Catari Taga I did bug report the 6h thing. Also AccountStatus has bogus paidUntil values, Medals has no cache time at all anymore, StarbaseDetail has 2m20, it's all a bit funky atm. Another fine patch for CCP. While i've not looked into any cached records yet, I can see that the number of cached entries is spiking over 10k, before the changes it stayed around 6.6k. Something isn't right somewhere.
Vessper Indicium Technologies	Posted - 2010.11.03 08:59:00 - [6] I've bug reported the CharacterSheet and SkillQueue cache time issues so hopefully someone will respond to those shortly. As it stands, it appears the SkillQueue API is useless at present as downloading a new copy just contains the same currentTime and cachedUntil values as the previous copy. I can't confirm if the actual row data changes as all my training is upwards of 20 days. EveHQ Character App
Catari Taga Centre Of Attention Middle of Nowhere	Posted - 2010.11.03 12:37:00 - [7] Originally by: Vessper As it stands, it appears the SkillQueue API is useless at present as downloading a new copy just contains the same currentTime and cachedUntil values as the previous copy. I can't confirm if the actual row data changes as all my training is upwards of 20 days. It updates correctly as the queue changes, including the currentTime value. --
Soletar	Posted - 2010.11.03 12:52:00 - [8] Edited by: Soletar on 03/11/2010 12:53:58 Confirmed. Eve Mon says over 87,000 hrs before it can update skill queue API again. I mean really CCP. Get off your *&^ and fix it already. I mean did no one at CCP actually watch a program run using the API before you released it. Whoever did Quality Assurance for the API release should be getting a pretty crappy performance review, or a pink slip.....

CCP Stillman	Posted - 2010.11.03 14:55:00 - [9] Originally by: Soletar Edited by: Soletar on 03/11/2010 12:53:58 Confirmed. Eve Mon says over 87,000 hrs before it can update skill queue API again. I mean really CCP. Get off your *&^ and fix it already. I mean did no one at CCP actually watch a program run using the API before you released it. Whoever did Quality Assurance for the API release should be getting a pretty crappy performance review, or a pink slip..... Hi, I'm the API QA person. Due to the way the different environments work between servers, this bug slipped due to the way the cachedUntil is calculated. We've already fixed the bugs in question internally. So please be patient while it makes it's way to TQ, which might not be long.


CCP Stillman	Posted - 2010.11.03 14:58:00 - [10] Also, thanks for all your bug reports. They all land on my desk, and I greatly appreciate it. If you find any other bugs, please do file a bug report :)

Chibisuke Gallente Children of Avalon	Posted - 2010.11.03 18:10:00 - [11] Originally by: CCP Stillman Also, thanks for all your bug reports. They all land on my desk, and I greatly appreciate it. If you find any other bugs, please do file a bug report :) Ok here's another one: AssetList.xml.aspx now returns cached data if requested multiple times (even from different source IPs), but the currentTime attribute is always set to NOW(). This makes it impossible to calculate accurate fuel ammount for silos and other pos structures for example. Please either always return uncached data, or fix the "currentTime" attribute, so specify the time the data is from. This is broken on other APIs too, but this is the one where it's most anoying.

CCP Stillman	Posted - 2010.11.03 18:56:00 - [12] Originally by: Chibisuke AssetList.xml.aspx now returns cached data if requested multiple times (even from different source IPs), but the currentTime attribute is always set to NOW(). That's entirely by design. A currentTime field that's not now, but potentially in the past, makes no sense. We don't timestamp when some data is cached. But nobody has requested that in the past, so it's not on our radar.

Chibisuke Gallente Children of Avalon	Posted - 2010.11.03 21:28:00 - [13] Then please see it as a request from me now. ;)
Wollari Phoenix Industries Black Star Alliance	Posted - 2010.11.03 23:14:00 - [14] Edited by: Wollari on 03/11/2010 23:16:25 Originally by: CCP Stillman We don't timestamp when some data is cached. But nobody has requested that in the past, so it's not on our radar. Of course you do. Sovereignty -> dataTime: What's that for a timestamp if not the time from when the data has been collected. "The request" for that kind of datafield is included in my long list of feature requests and topics. Even if you could calculate the estimated dataTime with cachedUntil - cacheTimer ... The dataTime Field would be nice for all APIs like you already do in the sovereignty API.
Catari Taga Centre Of Attention Middle of Nowhere	Posted - 2010.11.03 23:26:00 - [15] Originally by: Wollari Edited by: Wollari on 03/11/2010 23:16:25 Originally by: CCP Stillman We don't timestamp when some data is cached. But nobody has requested that in the past, so it's not on our radar. Of course you do. Sovereignty -> dataTime: What's that for a timestamp if not the time from when the data has been collected. "The request" for that kind of datafield is included in my long list of feature requests and topics. Even if you could calculate the estimated dataTime with cachedUntil - cacheTimer ... The dataTime Field would be nice for all APIs like you already do in the sovereignty API. Jumps and Kills API have it, too, but there it is always identical to currentTime and thus meaningless. And +1 for the request. --
Dragonaire Caldari Corax. SOUL CARTEL	Posted - 2010.11.04 04:02:00 - [16] Add my name to the list, We've really needed a timestamp for a while on most of the APIs but with the new caching its a lot clear now how badly it's needed.
Dorian Ramius	Posted - 2010.11.05 17:25:00 - [17] The API method /eve/CertificateTree.xml.aspx returns a cachedUntil field that is the same as the currentTime field, which makes it harder to use and I BR'd it, but an ISD responded saying it was working as designed and an application should not query it that often which is very true (in fact, I only query it during the intial program init -- and then I try to cache the file), however, it doesn't fit with how the method /eve/SkillTree.xml.aspx returns a cachedUntil time CURRENT_SERVER_TIME + 10 years.

CCP Stillman	Posted - 2010.11.05 20:04:00 - [18] Originally by: Dorian Ramius Edited by: Dorian Ramius on 05/11/2010 19:32:58 The API method /eve/CertificateTree.xml.aspx returns a cachedUntil field that is the same as the currentTime field, which makes it harder to use. I BR'd it, but an ISD responded saying it was working as designed and an application should not query it that often which is very true (in fact, I only query it during the intial program init -- and then I try to cache the file), however, it doesn't fit with how the method /eve/SkillTree.xml.aspx returns a cachedUntil time CURRENT_SERVER_TIME + 10 years. I agree. That's inconsistent. I'll bring it up with PrismX on Monday.

Matthew Caldari BloodStar Technologies	Posted - 2010.11.08 12:32:00 - [19] Originally by: CCP Stillman That's entirely by design. A currentTime field that's not now, but potentially in the past, makes no sense. We don't timestamp when some data is cached. But nobody has requested that in the past, so it's not on our radar. Nobody has requested it in the past because it generally wasn't a problem with the old super-harsh caching style. Old Caching First Request: currentTime returns NOW(), data pulled from server, therefore currentTime matches the time of the data. Subsequent Request: Cache rejects subsequent requests, no data returned, therefore currentTime doesn't matter. Therefore, currentTime could be used as a proxy timestamp for the data,and forecast-forward assumptions could be made from it. New Caching First Request: currentTime returns NOW(), data pulled from server, therefore currentTime matches the time of the data. Subsequent Request: Cache returns data cached as a result of First Request. currentTime returns NOW(), therefore currentTime does not match the time at which the data was pulled. Therefore, there is now no way to determine how old the data you are pulling actually is. Which poses significant problems for any application trying to forecast forward from a known point, which is especially likely with things like AssetList which have very long cache periods. ------- There is no magic Wand of Fixing, and it is not powered by forum whines.
Chibisuke Gallente Children of Avalon	Posted - 2010.11.11 09:42:00 - [20] BR:103117 Notification API still broken when trying to access it from multiple applications. Only one can get the data, the other ones get error 526
Vessper Indicium Technologies	Posted - 2010.11.11 10:00:00 - [21] Aren't the CharacterSheet and SkillQueue cache times supposed to be the same? From what I can tell, the CharacterSheet API is now 15 minutes and the SkillQueue is 57 minutes. Can't we have them both on 15 minute cache times? EveHQ Character App
Catari Taga Centre Of Attention Middle of Nowhere	Posted - 2010.11.11 12:57:00 - [22] Originally by: Vessper Aren't the CharacterSheet and SkillQueue cache times supposed to be the same? From what I can tell, the CharacterSheet API is now 15 minutes and the SkillQueue is 57 minutes. Can't we have them both on 15 minute cache times? Yeah, SkillInTraining is also on a 57 minutes timer at the moment. It used to be the other way around, CharacterSheet used to be 1 hour and the others 15 minutes. --

Pages: [1] :: one page
First page \| Previous page \| Next page \| Last page

COPYRIGHT NOTICE
EVE Online, the EVE logo, EVE and all associated logos and designs are the intellectual property of CCP hf. All artwork, screenshots, characters, vehicles, storylines, world facts or other recognizable features of the intellectual property relating to these trademarks are likewise the intellectual property of CCP hf. EVE Online and the EVE logo are the registered trademarks of CCP hf. All rights are reserved worldwide. All other trademarks are the property of their respective owners. CCP hf. has granted permission to EVE-Search.com to use EVE Online and all associated logos and designs for promotional and information purposes on its website but does not endorse, and is not in any way affiliated with, EVE-Search.com. CCP is in no way responsible for the content on or functioning of this website, nor can it be liable for any damage arising from the use of this website.