| Pages: [1] :: one page |
| Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Azazel Mordred
Cloak of Shadows
   |
Posted - 2008.06.20 06:18:00 -
[1]
Hi
I know there has been a fair amount of discussion regarding caching lately, so I thought I'd just throw this in with the rest of it.
I'm currently experiencing some really annoying caching issues with WalletTransactions and WalletJournal.
Consider this: I successfully made a request for market transactions, currentTime was reported as being 2008-06-20 05:05:11 GMT, and cachedUntil was reportedly 2008-06-20 05:19:03 GMT. Prior to this, my last request to WalletTransactions was at 2008-06-19 21:54:24 GMT (gleaned from the API access log; so I'm not sure what the expiry time on that might have been as my local cache was subsequently overwritten by the new successful request).
So, this new successful request had a cache time of around 14 minutes.
At 2008-06-20 05:27:44 GMT, I made another request, since cachedUntil clearly expired nearly 9 minutes prior. The API then returned error 101 Wallet exhausted, suggesting I retry after 2008-06-20 06:27:44.
At the moment, I'm obeying the new cache retry time, and things generally work fine after that. Also, all my cache requests are delayed by at least 5 minutes after cachedUntil (so if cachedUntil says 05:20, I will only retry after 05:25). I am also 100% positive there are currently no bugs in my caching or cache expiry checking.
I am wondering though, is anyone else making regular requests to the wallet functions, and do you experience similar issues? None of the other API requests (assets, orders, industry, kills, etc) I'm calling suffer from this problem, so I'm left with the impression that there's a bug in the API's caching somewhere, specific to the wallets. Should I be waiting longer than the 8+ minutes in my example above?
No other applications or services are making API requests with my full access key, so that is luckily a non-issue in this case.
|
Azazel Mordred
Cloak of Shadows
|
Posted - 2008.06.20 06:58:00 -
[2]
As a follow-up using the above example:
Tested making another WalletTransactions request, around 6 minutes after the suggested retry time, at 06:33:13. The request was successful, returning updated data since my initial 05:05:11 request, and the new cachedUntil reported as 06:35:35, which is clearly a ridiculous cache time of just over 2 minutes.
Fair enough, I thought I'd wait an additional 10 minutes beyond that this time, and made another request at 06:46:28. Unsurprisingly, it responded with error 101 again, suggesting I retry after 07:46:13.
Right now, it seems to me that the caching on the API's side for wallet functions is rather broken, and cachedUntil is currently meaningless.
The only way I can see of working around this right now, is to completely ignore cachedUntil, and use my own cache timeouts of a couple of hours after a successful request, which is obviously far less than ideal.
|
Amida Ta
German Mining and Manufacture Corp.
|
Posted - 2008.06.20 08:42:00 -
[3]
And you are sure your caching has no problem with summer/wintertime. Didn't use much, but did not have any problems lately...
|
Azazel Mordred
Cloak of Shadows
|
Posted - 2008.06.20 09:54:00 -
[4]
I do not believe DST or other timezone oddities are at play here, since I do not use DST. Regardless of my time, the times in the API's XML are quite clear, and as per my example, my access and cachedUntil times follow reasonably in GMT, no other time zones are involved in my example requests.
|
Dragonaire
|
Posted - 2008.06.20 14:58:00 -
[5]
I've been having same problem off and on since just before the patch too. What I've finally started doing to keep my logging from filling up is set my cache until time to an hour for these API calls.
I know it's not any kind of wrong timezone issue since the clock on computer doing the pulling is set to UTC and set via NTP  which is the same as I've been using since Dec. when I start playing around with API for a project. What it seems to be doing is send a cache until time of 15 minutes ahead like it does for AccountBalance and IndustryJobs.
I adding a bunch of extra logging for a while to track down what was going on.
So it's not just you having the issue 
|
Matalino
Ki Tech Industries
|
Posted - 2008.06.20 16:39:00 -
[6]
Tested this myself and confirmed that the cachedUntil time is set to 15 minutes after currentTime when you make a successful call to those API's.
If you attempt to access the API within an hour of that successful call, you will receive a "Wallet exhausted" error along with a new one hour cachedUntil time.
I have filed a bug report on this. (#59153) Hopefully it gets resolved soon. In the mean time I suppose there is little we can do about it: either manually adjust our caching so that we call it every hour, or simply let our code figure it out from the "Wallet exhausted" errors.
|
Azazel Mordred
Cloak of Shadows
|
Posted - 2008.06.20 21:05:00 -
[7]
That's great, thanks for the confirms .
I'd rather just leave my code as-is for now, since hopefully it'll be resolved when they deploy the new API updates and stuff, and I really don't want to go down the road of "special exceptions" for specific requests.
|
Matalino
Ki Tech Industries
|
Posted - 2008.06.20 21:44:00 -
[8]
 Originally by: Azazel Mordred
I'd rather just leave my code as-is for now, since hopefully it'll be resolved when they deploy the new API updates and stuff, and I really don't want to go down the road of "special exceptions" for specific requests.
Just as a thought, you might want to consider using fixed timers anyways.
If you are constantly pounding the wallet API everytime the cache cycle comes up, you will only ever be able to use the one application.
Any other attempts to access the wallet will be blocked because the wallet is constantly tied up by your application.
|
Dragonaire
|
Posted - 2008.06.21 16:25:00 -
[9]
I'm pulling everything and storing it in a DB myself so I can pound on it from there all I want which I'm guessing is what most people do. Then you just have all the apps use DB. I do leave a couple things out when I'm doing the pulls like the killmails so I don't interfere with our killboard which is hosted on another server and managed by someone else in corp.
|
Isidien Madcap
GoonFleet
GoonSwarm
|
Posted - 2008.06.22 15:05:00 -
[10]
You can also use something like the proxy I wrote a while back at http://oldforums.eveonline.com/?a=topic&threadID=668372 and avoid having to deal with this (and have your app work well with multiple apps that want the same info).
----
Isidien |
BigWhale
Three WiseMen Association
|
Posted - 2008.06.22 19:12:00 -
[11]
I can confirm this too... I noticed it couple of days ago.
--
R, U & Y are letters, not words... |
Azazel Mordred
Cloak of Shadows
|
Posted - 2008.06.23 05:40:00 -
[12]
Isidien Madcap - that's a great idea, I shall certainly implement support for it .
|
BigWhale
Gallente
Three WiseMen Association
|
Posted - 2008.06.28 05:22:00 -
[13]
Any more news on this?
--
R, U & Y are letters, not words... |
Azazel Mordred
Minmatar
Cloak of Shadows
|
Posted - 2008.07.02 13:13:00 -
[14]
Issue still exists after the upgrades.
|
Dragonaire
|
Posted - 2008.07.24 07:23:00 -
[15]
Just an update on what I've found by looking at my log files. the cache until time seems to be set to 10-15 minutes after first journal or transaction hit. So if you get journal for wallet 1000 it gives you a time 15 minutes in future. If you then get journal for wallet 1001 it will have same time as returned for wallet 1000. The Transaction stuff seems to follow same pattern. My questions for CCP are 'Are all the wallets being pulled at same time now or are they still being pulled when you request them?' If they aren't being done together then what's up with using same cache until time  from the first one accessed for all of a type like this? Also are you change the cache time to 15 minutes for these APIs if so we shouldn't be getting error messages when we try to get them in less than an hour like happens while obeying the cache until time we get now. Hopefully this gets sorted soon or I get an answer and can make some changes on my side. Know I've read in another thread some where that you were changing caching code but that was a few weeks ago now how about an update on how it's going.
|
Matalino
Gallente
Ki Tech Industries
|
Posted - 2008.07.24 16:41:00 -
[16]
Edited by: Matalino on 24/07/2008 16:47:07
Originally by: BigWhale
Any more news on this?
BTW - I got a response to my bug report: Fixed in: WAR 1.1
So I am guessing the next semi-major patch might fix this.
PS - The bug report response also indicated that they had logged a new defect in their system because of the bug report. So it appears that the bug report system might actually work for reporting bugs. 
|
Dragonaire
|
Posted - 2008.07.24 19:29:00 -
[17]
Thanks for the update I was wondering if they'd ever got back to you about it anymore.
|
| |
|
| Pages: [1] :: one page |
| First page | Previous page | Next page | Last page |