| Pages: [1] 2 :: one page |
|
|
| Author |
Thread Statistics | Show CCP posts - 1 post(s) |
TheNecromancer
The Royal Order
   |
Posted - 2008.06.06 17:32:00 -
[1]
any1 having problems right now ?
|
Immersive
Immersive Technology Solutions
|
Posted - 2008.06.06 21:17:00 -
[2]
my coffee machine broke...
(more details pls?)
|
Tonto Auri
Vhero' Multipurpose Corp
|
Posted - 2008.06.07 05:49:00 -
[3]
New way to have a forum visitors census?
--
Thanks CCP for cu |
TheNecromancer
The Royal Order
|
Posted - 2008.06.07 05:56:00 -
[4]
getting problems like Wallet exchausted and allready returned this and that.
Never has these problems bebore as I only read the data at the time I am allowed.
and the must fun is that I dont always get this problem
it just seems to come and go.
|
Tonto Auri
Vhero' Multipurpose Corp
|
Posted - 2008.06.07 06:15:00 -
[5]
Sounds not serious.
It is known problem that API cache are in once-blocked mode.
Try to increase delay between requests.
--
Thanks CCP for cu |
TheNecromancer
The Royal Order
|
Posted - 2008.06.07 10:05:00 -
[6]
Increase time ?
each time read data, there is a node telling you
the next time you get retrieve data. I use this node
so how can I read before I am allowed ?
if so. ccp is giving me the wrong datetime back :(
|
Shann Wu
|
Posted - 2008.06.07 10:09:00 -
[7]
Edited by: Shann Wu on 07/06/2008 10:10:24
keep in mind that the cacheUntil value is in UTC.
Also, timers are not accurate to the millisecond.
allow up to five minutes on top of your cacheUntil time to ensure the cache resets.
alternatively, you could find the cacheUntil offset by comparing it to the serverTime.
|
TheNecromancer
The Royal Order
|
Posted - 2008.06.07 10:12:00 -
[8]
My calc on next time is based on the ./eveapi/currentTime node and the
./eveapi/cachedUntil node
my math is
TimeSpan TSTimeLeft = cachedUntilTimer.Subtract(currentTime);
DateTime NextUpdateDateTime = DateTime.Now.AddTicks(TSTimeLeft.Ticks);
so program gets new data at NextUpdateDateTime
is this not correct ?
I have been using this approach for a long time
|
TheNecromancer
The Royal Order
|
Posted - 2008.06.07 10:16:00 -
[9]
allow up to five minutes on top of your cacheUntil time to ensure the cache resets.)
ok will try that
|
TheNecromancer
The Royal Order
|
Posted - 2008.06.07 11:07:00 -
[10]
did not help with the 5min extra time to the cacheuntil time :(
am I really the only one getting this problem ?
|
|
|
Immersive
Immersive Technology Solutions
|
Posted - 2008.06.07 12:09:00 -
[11]
Edited by: Immersive on 07/06/2008 12:12:24
// pseudo-C#
DateTime cacheUntil = <XML File Handler>.getCacheUntil();
DateTime serverTime = <XML File Handler>.getServerTime();
// this shouldn't matter if you're using the offset timespan,
// but just to be safe...
cacheUntil = DateTime.SpecifyKind( cacheUntil, <datetimekind>.Utc );
serverTime = DateTime.SpecifyKind( serverTime, <datetimekind>.Utc );
TimeSpan cacheOffset = cacheUntil.Subtract( serverTime ).AddMinutes( 5 );
DateTime cacheUntilLocal = DateTime.Now.Add( cacheOffset );
------------------------
It's coming...
|
TheNecromancer
The Royal Order
|
Posted - 2008.06.07 12:12:00 -
[12]
I have done the +5 min but are still getting this error,
the funny part is that I get date from multi chars and not all
are getting this error.
|
Immersive
Immersive Technology Solutions
|
Posted - 2008.06.07 12:13:00 -
[13]
Which page are you requesting?
------------------------
It's coming...
|
TheNecromancer
The Royal Order
|
Posted - 2008.06.07 12:16:00 -
[14]
I get data from all the apis
but it seems to be only related to char transaction and char journals
the others api are read fine
|
Immersive
Immersive Technology Solutions
|
Posted - 2008.06.07 12:27:00 -
[15]
I'm not at home at the moment, but I'll send you my email in-game when i get there if you'd like me to have a look at your code.
------------------------
It's coming...
|
Ausser
Cybertech Industrials Agency
|
Posted - 2008.06.07 12:35:00 -
[16]
I'm using a simpler calculation, but it works.
My code is: "Dim cacheReady = cachedUntill < My.Computer.Clock.GmtTime".
My cache management looks like this:
There is a serverCacheState table, with columns for cachedUntil,
serviceID and key. You allready know cachedUntill. serviceID maps
to a specific api call, for example "/char/WalletJournal.xml.aspx".
The important part of the table is key. Because there may be
multiple independant cache states per call (service), it is neccecary
to select the correct one by the key value.
The content of key is service dependant. Some examples:
- For WalletJournal and WalletTransactions i'm using accountID, which specifies a wallet account of a char/corp in one value. The value of accountID is provided by the AccountBalance api call, which maps charID/corpID+accountKey <-> accountID
- For /char/CharacterSheet i'm using characterID.
- For /corp/AssetList, /corp/Killlog, etc i'm using corporationID.
- For /char/AssetList, /char/Killlog, etc i'm using characterID.
- For global tables like AllianceList i'm using key=0, because there are no distinct cache states per service. It is sufficient to have one cacheState per service for those.
So key together with serviceID builds the unique key of the table. Both must be
used together to choose the correct cache state record when checking if to
start a new call to the api or not, and if not, how long to wait.
Errors like "Wallet exhaused ..." and "Allready returned one week of data..." could be an
indication the wrong cache state (and by this, the wrong times tamps) were used.
Espacially the Wallet* calls need care. A corp will have multiple wallet accounts, each with its own cache state. In earlier designs i've used serviceID together with charID/corpID and accountKey to get the correct cache state. This had implied a three column unique key. Using serviceID together with accountID simplifies it to a two column design.
You should also update the cache state on api error results too. If a response
contains a cachedUntil element, update cache state, no matter if it was
an error or if it was successfull.
Did that helped to trace back where the problem is? If yes, which one was it? If not, please give us some more details - it should be possible to find the problem. 
|
Immersive
Immersive Technology Solutions
|
Posted - 2008.06.07 12:41:00 -
[17]
Edited by: Immersive on 07/06/2008 12:42:06
 Originally by: Ausser
I'm using a simpler calculation, but it works.
My code is: "Dim cacheReady = cachedUntill < My.Computer.Clock.GmtTime".
...
Amen!
although I use "Dim cacheReady = (Date.Compare(Date.Utcnow, cacheUntil) >= 0)"
------------------------
It's coming...
|
TheNecromancer
The Royal Order
|
Posted - 2008.06.07 12:43:00 -
[18]
well
my program have runned for a very long time
with my appoach, why problems now ?
I mean
if my calc is somehow wrong it should have shown a long time ago
:(
|
Immersive
Immersive Technology Solutions
|
Posted - 2008.06.07 12:50:00 -
[19]
Edited by: Immersive on 07/06/2008 12:50:43
Eve-Dev is down at the moment, so I can't check this.
There was a report of a couple of the APIs returning bad cacheUntils if they were returning an errored state.
Something along the lines of cacheUntil offset only being 5 minutes, even though the actual offset was supposed to be, for example, 30 minutes.
To check for this, you'll need to make sure that your using whichever cacheUntil would take the longest. (Or simply "ORDER BY CacheUntil DESC" in your SQL call)
Without a more in-depth analysis of your code path, I've run out of ideas.
------------------------
It's coming...
|
Ausser
Cybertech Industrials Agency
|
Posted - 2008.06.07 13:02:00 -
[20]
Another source of the problem could hide arround the POST/GET code.
The api generates the timestamps on the fly while constructing
the xml and streaming it to the caller. So currentTime gets
generated first. There may be some time untill all records
of the result are returned from backend and serialized to the
connection. Then the cachedUntill gets generated.
I dont know if the value of cachedUntill is used by the api
to set its cache timers, or if there is another value used,
which gets generated after all connections to the caller were
closed. So i would check the code if it really closes all open
streams after writing POST arguments (if you use POST at all) and
reading the response from the server.
For debugging purposes it's a good idea to keep local gmt timestamps
which are captured before and after the http GET/POST request. I'm
storing these together with cachedBefore and currentTime in my cache
state table.
However, i dont think this is the problem. If you add 5 minutes to
your timers and it's still broken, the problem will hide somewhere
else.
Could you give us some timestamps? A few sets of beforeRequest,
afterRequest, currentTime, cachedUntil, together with call name, cache
reference key(*) and error code (if any) could help to find the
problem. For failed requests, the timers and keys(*) of the previous
requests of the call would also help.
*) NOT the api key! - just the key you identify the correct cache
state record in your code.
|
|
|
TheNecromancer
The Royal Order
|
Posted - 2008.06.07 13:05:00 -
[21]
here is my function that I use to get data from ccp
public static XmlDocument GetDataFromEveApi(string Url, string PostInfo)
{
WebRequest reg = WebRequest.Create(Url);
reg.ContentType = "application/x-www-form-urlencoded";
reg.Method = "POST";
byte[] b = Encoding.UTF8.GetBytes(PostInfo);
reg.ContentLength = b.Length;
Stream s = reg.GetRequestStream();
s.Write(b, 0, b.Length);
s.Close();
WebResponse res = reg.GetResponse();
Encoding encode = System.Text.Encoding.GetEncoding("utf-8");
StreamReader sr = new StreamReader(res.GetResponseStream(), encode);
string StrData = sr.ReadToEnd();
sr.Close();
res.Close();
XmlDocument oXml = new XmlDocument();
oXml.LoadXml(StrData);
return oXml;
}
|
TheNecromancer
The Royal Order
|
Posted - 2008.06.07 13:22:00 -
[22]
Edited by: TheNecromancer on 07/06/2008 13:27:13
Edited by: TheNecromancer on 07/06/2008 13:25:47
hmm
just took a visual dump of my data..been a while
since I looked there
its for the char wallettransction
<currentTime>2008-06-07 13:19:45</currentTime>
<cachedUntil>2008-06-07 13:34:45</cachedUntil>
was the cache time only 15min on transactions ?
I remember it to be like 45min or so
|
Immersive
Immersive Technology Solutions
|
Posted - 2008.06.07 14:14:00 -
[23]
Originally by: TheNecromancer
// Code snipped...
reg.ContentType = "application/x-www-form-urlencoded";
reg.Method = "POST";
// Code snipped...
XmlDocument oXml = new XmlDocument();
oXml.LoadXml(StrData);
return oXml;
}
I assume the ContentType is for the request, if it's for the response, "text/plain" is fine.
Personally, I prefer to use GET and just merge the authentication paramaters into the URI. Save having to deal with POST headers
Originally by: Immersive's Api Adaptor
URI source = New URI( SERVICE_LOCATION & API_AUTHENTICATION );
Net.WebClient reg = New Net.WebClient();
// MemoryStream stores the file in ram with standard Stream interface
IO.Stream datastream = New IO.MemoryStream( reg.DownloadData( source ) );
// Now I use XmlReader, but could probably run it straight to XmlDocument
XmlReader xml = New XmlReader( datastream )
// parse xml ...
Just my preference. I also have the option of saving the web response to a file and opening a stream to that instead, with only two extra lines of code.
Originally by: TheNecromancer
...
[ /char/wallettransction.xml.aspx ]
<currentTime>2008-06-07 13:19:45</currentTime>
<cachedUntil>2008-06-07 13:34:45</cachedUntil>
was the cache time only 15min on transactions ?
I remember it to be like 45min or so
It appears that the cacheUntil offset is 15 minutes for valid responses, and an hour for <error code"101"> wallet exhausted... </error> responses.
(Also, it'd be nice if the 'code' BB tag was layout-friendly, CCP)
------------------------
It's coming...
|
Ausser
Cybertech Industrials Agency
|
Posted - 2008.06.07 15:25:00 -
[24]
The request code looks ok. I would just add a try/finally
to close alle streams/readers/response in the finally
block. response.StatusCode = Net.HttpStatusCode.OK check
is missing too. This should not be a problem.
Another Approach
You mentioned the 'Allready returned one week ...' error
together with wallet related calls. This one does not sound
like a cache timer problem. How do you handle multipart
results? In normal operation i dont get this error, because
i stop calling when one of these is true:
- The api returned less records than the maximum chunk size.
- The age of the last record is more than seven days, relative to currentTime.
The related code fragment looks simple like this:
Quote:
If MinChunkSize IsNot Nothing Then
If result.Content.GetContentCount < MinChunkSize Then
' done - reason: returned less than maximum chunk size
Return True
End If
End If
If MaxAge IsNot Nothing Then
If result.currentTime - result.Content.GetLastTime > MaxAge Then
' done - reason: returned more than max age
Return True
End If
End If
If you use the error result to detect end of chunk, then
you allways get the cachedUntill from the error result.
I'm never getting error results since i stop before it
would occour. So i allways get cachedUntill from regular
results.
Could this be the significant difference? It would also
indicate some problem within api and cache handling.
|
Macdeth
Ephemeral Misgivings
|
Posted - 2008.06.08 00:36:00 -
[25]
Short answer, after some research because I've been getting a rather large quantity of API errors from my automated processes for the last two days: CCP broke the way their API server stores beforeRefID / beforeKillID on pages that are not beforeRefID=0.
For example fetching killlogs, beforeKillID=0 works fine...
<eveapi version="2">
<currentTime>2008-06-08 00:15:30</currentTime>
<result>
<rowset name="kills" key="killID" columns="killID,solarSystemID,killTime,moonID">
<row killID="2474353" solarSystemID="30000145" killTime="2008-06-08 00:15:00" moonID="0">
...
<row killID="2468680" solarSystemID="30002440" killTime="2008-06-07 16:50:00" moonID="0">
</rowset>
</result>
<cachedUntil>2008-06-08 01:15:32</cachedUntil>
</eveapi>
beforeKillID=2468680
<eveapi version="2">
<currentTime>2008-06-08 00:16:03</currentTime>
<result>
<rowset name="kills" key="killID" columns="killID,solarSystemID,killTime,moonID">
<row killID="2468410" solarSystemID="30002440" killTime="2008-06-07 16:26:00" moonID="0">
...
<row killID="2464675" solarSystemID="30002438" killTime="2008-06-07 08:05:00" moonID="0">
</rowset>
</result>
<cachedUntil>2008-06-08 01:15:32</cachedUntil>
</eveapi>
beforeKillID=2464675
<eveapi version="2">
<currentTime>2008-06-08 00:22:06</currentTime>
<error code="120">
Expected beforeKillID [2468680] but supplied [2464675]: kills previously loaded.
</error>
<cachedUntil>2008-06-08 01:15:32</cachedUntil>
</eveapi>
CCP have always had some problems where if you request the data too quickly, it thinks you didn't request the previous page yet. I've previously slowed the rate of my requests and even added longer delays with 'try again' clauses on the error condition. But if I wait a few minutes and request 2464675 again, I get the same error (the timestamp above is actually the second one, after waiting seven minutes while debugging and typing this).
So, waiting didn't work, let's request beforeKillID=2468680 again:
<eveapi version="2">
<currentTime>2008-06-08 00:22:19</currentTime>
<result>
<rowset name="kills" key="killID" columns="killID,solarSystemID,killTime,moonID">
<row killID="2468410" solarSystemID="30002440" killTime="2008-06-07 16:26:00" moonID="0">
...
<row killID="2464675" solarSystemID="30002438" killTime="2008-06-07 08:05:00" moonID="0">
</rowset>
</result>
<cachedUntil>2008-06-08 01:15:32</cachedUntil>
</eveapi>
Okay, it gave it to me a second time, never seen that before.
Now let's go request beforeKillID=2464675 again
<eveapi version="2">
<currentTime>2008-06-08 00:22:40</currentTime>
−
<error code="120">
Expected beforeKillID [2468680] but supplied [2464675]: kills previously loaded.
</error>
<cachedUntil>2008-06-08 01:15:32</cachedUntil>
</eveapi>
Oh dear!
One more time for good measure with beforeKillID 2464675?
<eveapi version="2">
<currentTime>2008-06-08 00:28:58</currentTime>
<error code="120">
Expected beforeKillID [2468680] but supplied [2464675]: kills previously loaded.
</error>
<cachedUntil>2008-06-08 01:15:32</cachedUntil>
</eveapi>
So, CCP broke it, and CCP need to fix it.
|
Macdeth
Ephemeral Misgivings
|
Posted - 2008.06.08 02:32:00 -
[26]
Just following up to say that several API keys are also giving me the following badly formatted API error (no code=### in <error> ) in response to /corp/killLog, while working fine on things like /corp/StarbaseList ...
<eveapi version="2">
<currentTime>2008-06-08 02:25:58</currentTime>
<error>
A general error has occured, please try again later.
</error>
<cachedUntil>2008-06-08 03:25:58</cachedUntil>
</eveapi>
Most of these corporations have had kills previously, although it's possible that none of them are in recent memory. I'll bug report this, too, naturally.
|
Jaarlax
Ratty Corp PLC
Confederation of Independent Corporations
|
Posted - 2008.06.08 08:30:00 -
[27]
my apis are working ok, but i run them manualy so don't tend to get the timer errors.
but the past couple of days the data returned is old, i just ran it and tho the current time is correct the data in it is 10 hours old!
till now it's allways been accurate
|
Tonto Auri
Vhero' Multipurpose Corp
|
Posted - 2008.06.08 22:58:00 -
[28]
http://games.chruker.dk/eve_online/test_eve_api.php
This link might be outdated, but can give you a good idea of what to watch in your debugging sessions.
--
Thanks CCP for cu |
TheNecromancer
The Royal Order
|
Posted - 2008.06.09 14:52:00 -
[29]
no matter what I do
I cant get new data after the 15min time delay on the char or corp wallets :(
|
Siona Windweaver
|
Posted - 2008.06.10 23:33:00 -
[30]
My API key gives me "Invalid User ID / API Key" error after todays patch. I also cant get a new API key.
This started right after servers came back online after todays patch. I'm guessing API servers still down?
|
|
|
|
|
| |
|
| Pages: [1] 2 :: one page |
| First page | Previous page | Next page | Last page |