Skip to content
This repository has been archived by the owner on Mar 9, 2020. It is now read-only.

Troubleshooting Tips

Jump to bottom
Michael Cummings edited this page Aug 15, 2014 · 3 revisions

Troubleshooting Tips

Below are some ideas on how to solve some common issues that come up with on the Eve Forums from Yapeal users.

Installation

Make sure to read README.md, INSTALL.md, and CONFIG.md and follow all the steps. It's worth going through them again a couple of times to make sure you aren't missing something. It can help sometimes if you can have someone else read the instructions for you while you do the steps. Often while do this you'll find something you missed before.

APIs

If you are having problems with any of the account, char, or corp section APIs double check that the keyID you are using has the correct APIs enable with CCP. Using the wrong key, not having the correct APIs enabled, or using wrong vCode from a bad copy and paste are common errors. Expired keys can also happen so make sure to check that as well. In your application its best use the interface CCP provides to help the users create keys with the proper requirements and return them directly to your application. Check CCP docs on how to do this.

Make sure your KeyIDs etc are added to the utilRegisteredKey DB table and isActive is set to 1.

API Section Not Working

Since Yapeal does NOT have any direct per section controls any more the only times you should see this is on a per KeyID basis and the suggestions from above should find the problem.

Single API Not Working

Once again the more general checks above should be done. Also insure the activeAPIMask is correct in the utilRegisteredKey DB table. Normally this should be the same as the accessMask in accountAPIKeyInfo table exception if you are using it to deactivate an API on a per keyID basis. Other thing to check if the same API seems to not work for all your keyIDs is that isActive=1 in the utilEveApi table. Normally it should be set to 1 even if the API doesn't exist yet but there are rare times when an API is added to Yapeal but is NOT set active. One case when this has been done is that the API has been add by CCP on the test server and into Yapeal but its NOT yet available on the main API servers. Normally there should be an update pushed out for Yapeal when the API goes life on the main server.

Checking Log Files

If none of the above seems to help then it's probably time to look at the log files to see if there is some addition information that can help find what is going on. First if you find a log/error.log file you have probably found a major bug in Yapeal or something is very wrong with the installation or configuration and you'll have to get fixed before anything else have a chance to work. If it seems to be a bug in Yapeal please make sure to open an issue on GitHub and include the log file.

On now to the log/yapeal.log file. Depending on your config/yaeal.yaml log settings Yapeal can generate a lot of log messages. First thing you'll probably want to do is a simple search with whatever editor you decide to open it with for any 'yapeal.ERROR' and 'yapeal.NOTICE' entries. Normally there should NOT be any but if something is going wrong they start showing up and should help lead you to where Yapeal decides that something is wrong. The nice thing about the way the logging works it also captures what lead up to the error or notice plus what happened afterwards. To make things just a little easier to understand I will be showing an example of a typical API call.

[2014-08-14 18:12:11] yapeal.INFO: Starting autoMagic for Eve/ConquerableStationList [] []
[2014-08-14 18:12:11] yapeal.DEBUG: Checking if cache expired on table eveConquerableStationList for ownerID = 0 [] []
[2014-08-14 18:12:11] yapeal.DEBUG: SELECT "expires" FROM "yapeal"."utilCachedUntil" WHERE "apiName" = 'ConquerableStationList' AND "sectionName" = 'Eve' AND "ownerID" = 0 [] []
[2014-08-14 18:12:11] yapeal.DEBUG: Expired UtilCachedUntil record found [] []
[2014-08-14 18:12:11] yapeal.INFO: SELECT GET_LOCK('4e405ce4ed84eccfab53eb83753c1a6a',5) [] []
[2014-08-14 18:12:11] yapeal.DEBUG: Started filesystem retrieve for eve/ConquerableStationList [] []
[2014-08-14 18:12:11] yapeal.DEBUG: Deleting expired cache file D:/repos/github/yapeal/master/cache/eve/ConquerableStationList4e405ce4ed84eccfab53eb83753c1a6a.xml [] []
[2014-08-14 18:12:11] yapeal.DEBUG: Started network retrieve for eve/ConquerableStationList [] []
[2014-08-14 18:12:12] yapeal.DEBUG: Started XSD validating [] []
[2014-08-14 18:12:12] yapeal.INFO: DELETE FROM "yapeal"."eveConquerableStationList" [] []
[2014-08-14 18:12:12] yapeal.INFO: Have 1001 row(s) to upsert into eveConquerableStationList table [] []
[2014-08-14 18:12:12] yapeal.INFO: INSERT INTO "yapeal"."eveConquerableStationList" ("stationID","stationName","solarSystemID","stationTypeID","corporationID","corporationName") VALUES (?,?,?,?,?,?),... ON DUPLICATE KEY UPDATE "stationID"=VALUES("stationID"),"stationName"=VALUES("stationName"),"solarSystemID"=VALUES("solarSystemID"),"stationTypeID"=VALUES("stationTypeID"),"corporationID"=VALUES("corporationID"),"corporationName"=VALUES("corporationName") [] []
[2014-08-14 18:12:12] yapeal.DEBUG: 61000854,4-EP12 VIII - 4-EP12 Inches for Mittens,30004553,21645,667531913,GoonWaffe,61000855,X-4WZD II - Outpost Ticonderoga,30003744,21645,1089744282,Organized-Chaos,61000856,AF0-V5 X - NO MORE YOLO,30002107,21646,98008728,Northern Associates Holdings,61 [] []
[2014-08-14 18:12:12] yapeal.INFO: Have 31 row(s) to upsert into eveConquerableStationList table [] []
[2014-08-14 18:12:12] yapeal.INFO: INSERT INTO "yapeal"."eveConquerableStationList" ("stationID","stationName","solarSystemID","stationTypeID","corporationID","corporationName") VALUES (?,?,?,?,?,?),... ON DUPLICATE KEY UPDATE "stationID"=VALUES("stationID"),"stationName"=VALUES("stationName"),"solarSystemID"=VALUES("solarSystemID"),"stationTypeID"=VALUES("stationTypeID"),"corporationID"=VALUES("corporationID"),"corporationName"=VALUES("corporationName") [] []
[2014-08-14 18:12:12] yapeal.DEBUG: 61000888,Q7-FZ8 VI - Cant Hurf At Mittani,30000785,21645,98017963,Unforeseen Consequences.,61000889,QKTR-L V - Blacksmith - HARD,30002431,21644,98066511,Fair People,61000890,8P9-BM VIII - Roys Chicken Chokin' Ranch,30003750,21646,1003546738,Kongsberg Vaap [] []

Using the default logging level of 300(WARNING) in your config/yapeal.yaml file you wouldn't see any like this normally so to show you one I've set my logging level to 100(DEBUG) on my local test system. I'll go over the example line by line.

  1. The first line tells you which API the following messages are for. In the example its eve/ConquerableStationList.
  2. Next it let's us know it's going t be checking the utilCachedUntil database table to see if the date-time for this API has past or NOT.
  3. It next show the actual SQL query that is going to be used. In the case of really long query strings this can be truncated.
  4. It found a record for the API but it has expired. It would also consider not finding a record to be expired but with a little different message.
  5. Now Yapeal will get a lock in the Database for this API. Since this API doesn't have a 'owner' It'll only need to get this single lock to work with the API. In the case of an API in the account, char, or corp sections it would get a lock for each keyID, characterID, or corporationID as need. This means that more than one Yapeal can be running at the same time and even working on the same API but the database will insure no two are working on the same API for the same key/char/corp combination at any one time.
  6. After receiving the lock Yapela next start going through the configured retrievers starting with the filesystem one.
  7. In this example the cache file is also expired so Yapeal deletes it. In normal operation the file is expected to have expired if the cachedUntil table has but for cases like in testing new APIs where the cachedUntil date-time doesn't get update etc this allows Yapeal to recover without having to get the data from the Eve API servers again lowering network load for everybody.
  8. Yapeal next uses the network retriever to get the XML from the Eve API server for the API.
  9. Next no matter the source of the XML data it is checked by Yapeal with a XSD schema to insure it's a valid. The only times you might see this check fail is if there has been a change to the XML format. There is also cases where the XSD is incorrect do to limited testing. Any failures here should be reported as an issue on GitHub.
  10. Some APIs like this one clear the database table with a delete. Others may only clear the data for a single character or corporation. This would mostly be done where the old data being mixed with the current data would NOT be wanted. For this example if a Conquerable Station was removed from Eve we really don't care who owned it last since it no long exists. Other APIs like WalletTransactions would not delete anything because the history is important.
  11. Yapeal lets us know how many row it's going to try to upsert next.
  12. The SQL used for the prepare statement is shown. Note that this maybe truncated in the values part for multiple rows so the rest of the SQL can be shown.
  13. Depending on the API there will be one or more of the data rows( records) shown for reference. Note Yapeal does NOT worry about row or column boundaries but uses a set maximum length when truncating this. This mean you may see partial rows or even partial column values at the end.
  14. See below
  15. See below
  16. Some APIs like this one have more than 1001 rows of data to be added to the database. Yapeal in this case will break the rows up into multiple upserts to help insure none of them exceed typical database server settings and in the case of network database connections tries to make things a little nicer as well. All the upserts and deletes etc are wrapped into a single transaction to make sure they happen atomically. So for example if one of the upserts failed the delete would also be rolled back and the table is in the same state as before Yapeal tried updating it.
Clone this wiki locally