-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Logging Issue #63
Comments
When searching hawkeye for the user in question in-game the plugin reports no user of that name could be found. This is done with a generic /he search p:username Upon investigating the database a user is found in the hawk_players table with a player_id assigned, searching the hawkeye table for events logged with the users player_id the three events are logged. The events in question are actions 5,7,6 in that order. Based on the data accompanying them and the order actions are listed in the help command I beleive the actions themselves are command, leave, and join. Data included with 5 and 6 is the users IP, and 7 is world and position data. |
So what I've gathered from this is ONE user from your server cannot be queried for. Could you possibly provide this users username (In case it contains weird characters). Also, try to query for the users data rather then the username. See if it displays the users name in the search results. You could simply use /he search t:10s after having the user do something logged. This might be cased by the fact that usernames are case insensitive? |
Uh... Could you reference for me the post directly above yours where I said I went so far as to manually search the database for entries? The user in question was called: However, after making the initial bug report we found a second user with the same issue, their name was: kawaiiikitten Please also note searches were done in-game as the users were building via range based searches, the hawk tool, and by name specifically. |
Hmmm I'm beginning to think two ID's were assigned to the same user somehow. We begun utilizing that feature not that long ago. It resulted in player-ids being mixed a lot more rather then inline in the table. I don't see how an auto-increment value could possibly be duplicated but anything is possible i suppose. Defiantly check your user table to see if these keys are duplicated. |
I checked the DB prior, as I stated before. |
Please note: There are
generated for actions from these players. They can't be simply under the wrong ID because they don't ex This isn't totally accurate. Going through the DB again testing on a new user with similar circumstances (Same IP as a user previously joined.) and I discovered the two users have logs in it now, but not complete logs, there are still bits missing. I also noted the new user is affected by the same issue. It appears to be directly caused by a second user from the same IP connecting. I will be doing more testing to determine what information I can, but at the moment all I have with certainty is this:
Logs are not crossing-users, they simply aren't being generated/saved/loaded. |
Alright i believe i understand now xD. First off, we save data in a producer/consumer system. The consumer runs in intervals and will only consume entries that are ready to be consumed. The data is saved in batches, and uses a manual commit connection. That being said, if the consumer is being overloaded, it's possible you'll have dataloss. So check your logs for an "Overloaded!" error. I also recommend you post your configuration to see if you're logging anything extremely intensive (Such as water-flow). When you reload the server, HawkEye attempts to quickly dump all the data from the queue into the database to prevent dataloss. This is why you're finding that it's "force-loading" data. So defiantly check your logs for any warnings from HawkEye (The prefix is [HawkEye]). Posting your config should also help determine the issue at hand. The login/logout events shouldn't be the root of your problems considering they're very primitive. All the event does is throw the IP address of a user into the queue. I don't see how this could possibly mess up unless Bukkit wasn't calling the PlayerJoinEvent for whatever reason. This is why I'm beginning to think it's an issue with the consumer not being able to keep up with the producer. |
Any ideas on this issue? |
I can't seem to reproduce the issue. I'll try with lower versions of MySQL soon. |
This is what we are running currently |
I can't seem to reproduce this at all. Do you have any errors/warnings in your logs? Have you used the debugger in HawkEye? |
This issue should be fixed. The problem was people using the same playertable/worldtable for multiple instances which desynced the local caches. If your issue is still persistent, please open another ticket and/or reset your HawkEye tables. |
Howdy,
We are running version 1.7.2 on Spigot 1.9.4 and we are having a logging issue with a single specific player, according to the database we have 3 actions logged, which would be a join, leave, and a single command. Nothing past that is being logged. Hawk is working perfectly for everyone else. Any ideas what we might be dealing with here?
The text was updated successfully, but these errors were encountered: