Error in CraftBukkit

Caps are on purpose, because this bug REALLY needs fixing.

Issue

After a certain CraftBukkit build everyone started to get spammed with chunk unload events. Developers wondering WHY this was happening, but they couldn't fix this. It was basically calling the unload event for all chunks on every 'afk' world every tick. This causes massive lag for some events, especially those that have to look into a map for each chunk to check if this unload has to be cancelled.

Result

A lot of lag. In all of the plugins I monitored using NoLaggExamine the unload event handling process time took around 90 ms PER PLUGIN total over 500 ticks. TrainCarts, NoLagg, Spout and other plugins that rely on the unload event severely suffer from this issue.

But why?

I traced it down to the following method calls (in the same order):
#1. server configuration manager flushes all player managers
#2. Player manager forces the entire world to unload if it has no players
#3. Chunk provider queues all chunks for unloading
#4. Chunk provider fires the unload event almost the same tick

So what is happening?

A new feature got added to clear all empty worlds of all loaded chunks once the players leave. Though, they didn't think of plugins possibly cancelling these events. This causes the same chunks to be cancelled over and over 20 times per second. Having around 5 empty worlds loaded, this can bring the entire server to a slow but noticeable lock.

PLEASE FIX THIS, IF YOU HAVE CRAFTBUKKIT LOCALLY

Thank you.

http://pastie.org/3536496

https://bukkit.atlassian.net/browse/BUKKIT-1060

 

:O

 

Agreed

 

leaky.bukkit.org ?

 

Don Redhorse I feel that it doesn't get enough attention there, and it needs fixing ASAP. Not something to end up below 'add message when this happens'.

 

well if you don't tag all the developers and mods here it wont make a difference... you could try IRC...

 

There is an unbelievable amount of time spent on Leaky, and a comparatively small amount of time spent on the forums. Posting it in leaky will get immediate attention (even if they don't respond, it gets seen).

 

Removed all caps man's title. Against TOS, no matter how justified you feel in using it.

 

Don Redhorse I'll write a ticket too then, just hope this gets resolved soon enough. (before they start pushing an official RB if they hadn't already)

 

probably best, I do agree though that the feedback time on leaky is a little bit slow.. and IMHO if somebody looks at it it should have least be made a change in the classification and not sit there unanswered without any knowledge if it was even looked at for days.

because this will lead to people not using leaky as they will think it is being processed correctly..

 

+1 vote in JIRA. Still no comment or assignment, btw

 

The response to an issue is normally the fix. As far as this particular issue goes, you should program plugins with the chunk unload every tick in mind. Cache the results, use a better hash, something. Really, if you get an insane number of unloads EVERY tick, that means you should most likely let the server unload that chunk. What do you expect the server to do when it has a chunk it wants to unload? It's not a magical genie.

 

Just posted fix for review on CraftBukkit-Bleeding - hope it helps.

 

Uh-oh.

 

No, not at all. You don't want that chunk to unload for a reason. For example, you want redstone to stay alive. Or, in the case of TrainCarts, I need to keep the chunks loaded. Or maybe another reason. Point is, chunks will infinitely be queued for unloading and then cancelled, which leads to the actual chunks that can be unloaded to be never unloaded at all.

It is up to the developer to unload these chunks again, after they cancelled it. Of course, it is easier if CraftBukkit added some sort of 'weak' unload poll every now and then, but do keep a time-out of at least 20 seconds. Every chunk every tick is ridiculous.

 

I tend to disagree.. the response to an issue is the acknowledgement of it, perhaps asking further questions to clarify the issue, for example it could be an issue of a plugin, than you give the issue a level of importance and perhaps an assignment... the end will than be a fix..

http://bug-tracking-guidelines.com/

 

I was referring to what 'is', not what 'should'.

 

I know... unfortunately..

 

looks like it was just committed.

nice job, all around.

 

Ah nice, glad it is fixed now

I see they added a check so it will only boot all chunks when going from 'non-empty' to 'empty' players in a world. A good way to fix it IMO.