EssentialsX
Caching /balancetop on load and every x minutes.
Currently /balancetop will only cache when someone types the command, which is not very user-friendly since the user has to wait till it's loaded.
It would be better if /balancetop will be directly cached on load and update every, let's say, 15 minutes.
Especially on servers with lots and lots of users it normally will take a while to load /balancetop after typing, in my case it took 8 minutes to load /balancetop (500k users), when it's cached on load it will only take once 8 minutes instead of the 8 minutes everytime.
After the server has launched and someone tried to /baltop, it should message the sender Balancetop is currently loading. When the /baltop is updating it should send them the previous baltop.
Just like to note that from a cursory glance of the code, I believe it should be caching for 2 minutes already.
I disagree with this on the basis that it completely undermines Essentials' lazy loading by regularly force loading every single user's data into memory, which would end up making EssentialsX use a lot more memory.
However, we could add a message to say that the list is loading, as this would have little impact on the server.
We could also just add an option to force it to be cached initially on startup.
We could, but this cache would still expire and the list would get generated again.
To build on this, I tried to run the command recently and it just never finished, didn't output anything, I was online a good 4-5 hours. Can you not cache it like what happens with usermap.csv, have a baltop.csv.
It's cached in memory.
Can someone suggest a more user friendly approach / functionality? If so, we can prob come up with a way to make it happen if it's reasonable.
@FrozenBeard That doesn't make sense in numerous cases, because we're then ignoring the fact that balances can be volatile.
If you have so many users that /baltop never finishes, you should probably start pruning your userdata.
If you have so many users that /baltop never finishes, you should probably start pruning your userdata.
Reports baltop does not work, Solution, Delete your players data. Mate you need to stop being so hostile to me, I saw this bug and It reminded me I tried to use it the other day and it just never worked.
@drtshock I'd suggest adding an option to automatically regenerate the cache once the expiry time has been met. That way, we can just regularly keep the list up to date, and we can use the old list until a new list has been generated.
@FrozenBeard I'm making a suggestion based on what you said. You need a lot of userdata files for the command to never finish if the amount of userdata files is the cause, and the chances are, old player data is sitting there and won't be used. You could implement some kind of backup-and-restore system for inactive players if you wanted, I suppose, but I doubt anyone has enough active players on a single server to warrant keeping that many userdata files around.
@md678685 I have a few other solutions luckily available that are better than deleting user data.
- I have a statisics plugin that records player bal when they log in, so we have a proper MySQL user table to query.
- Theres an awesome plugin called Plan on Spigot, he somehow manages to create a baltop of all essentials data and display it in a web UI, he manages to scan the Essentails data perfectly fine. Maybe you could see how he does it? His code is open source (Sorry is this is advertising, Im not advertising this plugin this is just to give an example of working baltop code) https://github.com/Rsl1122/Plan-PlayerAnalytics If thats how he does it, I haven't looked into it, I don't know Java.
I think having the option to regularly automatically update the cache is the best solution.
@FrozenBeard I wasn't implying that deleting userdata was a solution, only a suggestion of general maintenance for large servers, which helps minimise the impact of situations like this where iterating over the entire user map is necessary.
@darbyjack This issue is about regularly refreshing baltop's cache so that it is always available, rather than having to wait until the command is run to cache it.
Apologies on that, I've added this to the 3.x milestone and I will work on it.