Skip to content
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

Closed
tristansgray opened this issue Jun 13, 2016 · 12 comments
Closed

Logging Issue #63

tristansgray opened this issue Jun 13, 2016 · 12 comments

Comments

@tristansgray
Copy link

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?

@babel5405
Copy link

  • Developer for Tgray's community.

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.

@bob7l
Copy link
Owner

bob7l commented Jun 14, 2016

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?

@babel5405
Copy link

babel5405 commented Jun 14, 2016

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:
WalkinUnDeadpool

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.

@bob7l
Copy link
Owner

bob7l commented Jun 16, 2016

Hmmm I'm beginning to think two ID's were assigned to the same user somehow.

https://github.com/bob7l/HawkReloaded/blob/master/src/uk/co/oliwali/HawkEye/database/DataManager.java#L135

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.

@babel5405
Copy link

I checked the DB prior, as I stated before.
So far as I could tell everything was functioning correctly on the DB, each user had an entry, and each had their own player_ID.

@babel5405
Copy link

babel5405 commented Jun 17, 2016

Please note: There are

NO LOGS AT ALL

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:

  • The first user from an IP logs correctly.
  • The additional users from an IP do not log at all immediately.
  • Logs may appear later from additional users, but they are not complete. (When using the hawkeye tool to check areas they were building chunks of missing data can be found.
  • Reloading the server appears to force-load some data (I got a join, leave, and command event, along with one drop action.) on an additional user on an IP, but does not appear to save/load all logs.

Logs are not crossing-users, they simply aren't being generated/saved/loaded.

@bob7l
Copy link
Owner

bob7l commented Jun 17, 2016

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.

@tristansgray
Copy link
Author

Any ideas on this issue?

@bob7l
Copy link
Owner

bob7l commented Jul 2, 2016

I can't seem to reproduce the issue. I'll try with lower versions of MySQL soon.

@tristansgray
Copy link
Author

This is what we are running currently
MariaDB Server 5.5.47-MariaDB

@bob7l
Copy link
Owner

bob7l commented Jul 2, 2016

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?

@bob7l
Copy link
Owner

bob7l commented Aug 8, 2016

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.

@bob7l bob7l closed this as completed Aug 8, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants