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

UUID Code: Massive Performance Risk / Bug #108

Open
aikar opened this issue Aug 20, 2015 · 0 comments
Open

UUID Code: Massive Performance Risk / Bug #108

aikar opened this issue Aug 20, 2015 · 0 comments

Comments

@aikar
Copy link

aikar commented Aug 20, 2015

Re: https://github.com/bekvon/Residence/blob/master/src/com/bekvon/bukkit/residence/Residence.java#L810-L825

getOfflinePlayers() is an extremely dangerous operation. I understand this is needed for the initial conversion, but this code should only be in a separate method that is only called during that initial conversion.

To get a UUID for an offline player, there are some other libraries out there you can use that calls the mojang API (or cacheing proxy API's) that will be faster and safer than iterating all offline players which on an old server is pretty much guaranteed to crash the server / time everyone out.

For example I have 84k player files on my oldest server... That would be devastating.

What's scary is this method is called on Residence object creation. So if you have say 1k residences, that startup is pretty much doomed.

Or if you change owner of a res to another offline player, again server hang.

Additionally, you should not use Residence.getServ().getPlayer() - this is the wrong API. You're looking for getPlayerExact().
getPlayer has different behavior than you are expecting. It does not do an exact name lookup and can return a different player than you are expecting.

Finally, why is Residence.getServ() a thing? You can replace all with Bukkit.getServer()

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

1 participant