dynmap 🚀 - Dynmap Causing Mob and Chunk Issues

There is also a Spigot issue that suggests that Dynmap is responsible:
https://hub.spigotmc.org/jira/browse/SPIGOT-1746

Black-Hole on 18 Mar 2016

I've replicated this on my own Spigot Bukkit server with Dynmap and a few other plugins installed. I don't have many mobs around, so I don't experience that part of it, but carts randomly get stuck only in certain (and periodically changing) chunks, and occasional dropped items both can't be picked up and stay for longer than 5 minutes.

KermMartian on 18 Mar 2016

👍1

Yes the issue extends to all entities, not just mobs. If you drop an item in one of the chunks it will continually fall and rubber band back up to where you dropped it until you pick it up again. If players are in Minecarts when the cart gets stuck in the chunk then they can't get out of the cart without teleporting.

DemonWav on 18 Mar 2016

Can confirm, happens on all of my servers using dynmap plugin.
Arrows randomly stuck in the air, mobs freezing and staying there even after they're killed.

FHRNet on 19 Mar 2016

This kept happening on my server too. I had to unload the plugin because it was making it pretty unusable sometimes.

Here is a picture of a dead chunk with all the mobs frozen: http://i.imgur.com/w6OO4Br.png
Another example here of a ghast spawning inside a dead chunk: http://i.imgur.com/BALotMZ.png

It is always the same chunks that do it. One corner of my cow farm was constantly freezing. It is unrelated to the issue Black-Hole linked to, that issue also affects my server but it isn't as serious as this one was (and that issue continued even after unloading dynmap, while this one did not). This issue also does go along chunk boundaries, unlike the similar sounding spigot issue. Not sure what is going on, but dynmap is definitely making some chunks freeze.
I don't think there are any errors logged anywhere, I didn't see any.

jacob1 on 20 Mar 2016

Pinging @mikeprimm just in case to get his attention.

mibby on 20 Mar 2016

Happens on our server too, hoping that there will be a new build of dynmap soon

dsfeagle on 20 Mar 2016

Pretty sure this is from a bad PR I accepted a few weeks back - https://github.com/webbukkit/dynmap/pull/1851 - will roll it back, and we'll see how,we do.

mikeprimm on 20 Mar 2016

As soon as it is rolled back, I'll be readily available to test it. :)

mibby on 20 Mar 2016

OK - give this build a spin - http://dynmap.us/builds/dynmap/dynmap-2.3-SNAPSHOT.jar

mikeprimm on 20 Mar 2016

@mikeprimm did you change the logic in 1.9? I've been using the no double removeEntities for months without issue.

Why would dynmap ever need to call that method twice?

Also, the symptoms of the bug line up more with the opposite - that they were removed when they shouldn't of been and no longer tick.

aikar on 21 Mar 2016

Nope - code is the same code for all Bukkit versions. The problem with not removing them, IIRC, was that the chunk would be saved with the transient entities (mobs, arrows, things that never get 'stored' in chunks), and they'd be essentially orphaned with the chunk was later thawed (which sounds a whole lot like what is being described by these reports). If it IS 1.9 specific, it implies an API behavior change in Spigot/CB - that logic is unchanged for a couple of years now - but, as almost no mods use the load/unload chunk APIs, we;re the ones that will get pointed at...

mikeprimm on 21 Mar 2016

This is something of interest: from the 1.9 Spigot code for CraftWorld.java:

    public boolean unloadChunk(int x, int z, boolean save, boolean safe) {
        org.spigotmc.AsyncCatcher.catchOp( "chunk unload"); // Spigot
        if (isChunkInUse(x, z)) {
            return false;
        }

Versus previous versions:

    public boolean unloadChunk(int x, int z, boolean save, boolean safe) {
        org.spigotmc.AsyncCatcher.catchOp( "chunk unload"); // Spigot
        if (safe && isChunkInUse(x, z)) {
            return false;
        }

There are further changes, but since our use of this call is to unload chunks we've loaded without saving them (and with safe=false, since we know we loaded it, and nothing that has happened to it is meaningful, and since the isChunkInUse() API has been broken for years due to the player's in-use radius being 256 blocks (16 chunks) versus the actual 160 block (or less - 10 chunks). If we use 'safe=true', chunks have always been leaked in these edge areas due to this.

This might be the actual problem, if the issue is 1.9-specific.

mikeprimm on 21 Mar 2016

so does that snapshot.jar fix it? :P

dsfeagle on 21 Mar 2016

I don't believe it does @dsfeagle.

DemonWav on 21 Mar 2016

This has not fixed it on my server, running the newest .jar that @mikeprimm provided.

gganno on 21 Mar 2016

Do we know if this is 1.9 specific, or no? If anyone has any non 1.9 data, please chime in!

mikeprimm on 21 Mar 2016

This did not occur in 1.8.x for us with a very similar set of plugins, including DynMap.

KermMartian on 21 Mar 2016

👍1

OK - I'm going to build a patched Spigot 1.9 jar, with the "if (safe && isChunkInUse(x, z)) {" change I mentioned above, if anyone is brave/foolish enough to give it a try....

mikeprimm on 21 Mar 2016

What are the risks in running the build with "if (safe && isChunkInUse(x, z)) {"? Sorry not really a programmer

gganno on 21 Mar 2016

The "safe" was patched out only a few days ago. Frozen entities happens with or without it.
With 1.8.x this happened only when the following commit was added. It was reverted very soon:
https://hub.spigotmc.org/stash/projects/SPIGOT/repos/craftbukkit/commits/4ac23479e5e3ca24c4a656efbbde2490aa551923

Black-Hole on 22 Mar 2016

Is there anything we as server administrators (that have coding know-how) can do to help resolve this issue?

KermMartian on 23 Mar 2016

👍1

If someone can produce a minimum and repeatable scenario that I can see and investigate, that'd be a big help. Do the frozen entities persist after a restart (something you could do with a test world, and then send me so that I can download and look at it)? Or, is there a specific set of actions I can do with a test world to see what you guys see?

mikeprimm on 23 Mar 2016

Frozen entities do not persist after reboot. Sometimes leaving a chunk,
waiting a bit for it to be unloaded by spigot and returning fixes the
problem for non-spawn chunks. I think the problem can be triggered by
invoking a full-render.
On Mar 23, 2016 12:20 PM, "mikeprimm" [email protected] wrote:

If someone can produce a minimum and repeatable scenario that I can see
and investigate, that'd be a big help. Do the frozen entities persist after
a restart (something you could do with a test world, and then send me so
that I can download and look at it)? Or, is there a specific set of actions
I can do with a test world to see what you guys see?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/webbukkit/dynmap/issues/1916#issuecomment-200449237

snarfattack on 23 Mar 2016

The chunks that display this behavior change even as the server is up and players walk around. I replicate the issue when DynMap performs renders. It definitely is not related to chunks that are far enough away from players that DynMap should be loading and unloading them itself (perhaps DynMap is unloading chunks that are in fact loaded normally after rendering them?).

KermMartian on 23 Mar 2016

👍1

If someone can produce a minimum and repeatable scenario that I can see and investigate, that'd be a big help. Do the frozen entities persist after a restart (something you could do with a test world, and then send me so that I can download and look at it)? Or, is there a specific set of actions I can do with a test world to see what you guys see?

I did a lot of tests around that issue and there are few things I noticed. The most obvious one is that I ran the server for 5hours without any problem with dynmap while nobody was online except me once in a while going around for like 10 secondes and logout. Then we decided to test further and stayed online for like 10mins. As soon as my friend went into a minecart at a very specific spot on the server, the cart stopped moving and I used F3 to locate the chunk and went to the next one to test another cart... worked perfectly until it has reached the chunk from the oposite direction. Once the glitch occurs, all the entities on the server stop moving/working/looting ( can be coord 15 000, 15 000 or 0, 0 it doesn't matter). I reboot the server with /stop and reopen it and all is fixed till someone rides that chunk on a cart again.

That was our best way to "force"(replicate) the bug. If you want to see it happen, I could whitelist you on my server tonight and run the test, I know my players won't mind, they are dying for Dynmap :P

shibii1111 on 23 Mar 2016

I cant do anything else than confirm this.

Furnaces/Hoppers/everything that is triggering get frozen.
Leaving area deactivating chunk dont help... But logging out and in again reset the issue, and things seems normal.

But after one experience with this. If two players go to that area, and both teleport away, it wont help if just one of them log out, both has to do it.

This issue persist with render both on and render pause mode.

Issue _DO NOT_ dissapear when disabling Dynmap from server. *** <- Just checked that out, with disabling dynmap.jar file completly.

That was much about the testing I've done. Alone with 1-2 users on spigotserver updated as today.

Might be outdated worldborder plugin, generation issue? Map chunk's slightly corrupted? Might still be a spigot issue?

Anyways thanks for a really great plugin-mod, mikeprimm! Hope you live long, so the players wont go blind. :)

EDIT: It seems that the player has to log out in the chunk, and load the furnaces etc that way. Might be something with the player.teleport issue that was talked about? wrong locations compared to actual values? Tested this and it is confirmed.

Rudomeister on 24 Mar 2016

My problem is, you shoot an arrow (I tested it with Spectral arrows) and they will stop in the middle of their path, and stay floating in the air until I restart the server. I tested it on a server with just DynMap plugin and this happened. As soon as I removed DynMap those things stopped happening.
I think it was between 2 chunks.

Spigot version:
This server is running CraftBukkit version git-Spigot-90839e6-ace06bd (MC: 1.9) (Implementing API version 1.9-R0.1-SNAPSHOT)
Dynmap:
Latest from bukkit.org; 2.3

FHRNet on 24 Mar 2016

Fixed with Paper commit: https://github.com/PaperMC/Paper/commit/8d0fbc5c1daee9ff6ff8e344fe4af5021d7d3a77

I got no complains about frozen chunks since that patch the last two days. Before that it was quite regularly.

Black-Hole on 24 Mar 2016

@Black-Hole people have been having issues well before my unload queue patch, as well as issues on spigot which does not have my patch at all.

Now, it is possible that the behavior change of my patch changed something in dynmap to avoid the issue.

I did make effort to keep NMS/Binary compat with dynmap since I saw it touched the unload queue itself.

aikar on 24 Mar 2016

I still need to crawl into this - the short answer right now is that the Dynmap code is the same binary with the same logic as 'for a long time', works on 1.8.x, and has this problem on 1.9 - ergo, there is a behavior change in the 1.9 APIs that we need to understand. The best candidate I've found so far - I don't KNOW that its an issue, THE issue, or just plain old not relevant - are some of the differences in how loadChunk/unloadChunk are coded for 1.8.8 vs 1.9. In 1.9, loadChunk is:

 public boolean loadChunk(int x, int z, boolean generate) {
         chunkLoadCount++;
         if (generate) {
             // Use the default variant of loadChunk when generate == true.
             return world.getChunkProviderServer().getChunkAt(x, z) != null;
         }

         world.getChunkProviderServer().unloadQueue.remove(x, z);
         net.minecraft.server.Chunk chunk = world.getChunkProviderServer().chunks.get(LongHash.toLong(x, z));

         if (chunk == null) {
             chunk = world.getChunkProviderServer().getOrLoadChunkAt(x, z);
         }
         return chunk != null;
     }

While in 1.8.8, it is:

     public boolean loadChunk(int x, int z, boolean generate) {
         chunkLoadCount++;
         if (generate) {
             // Use the default variant of loadChunk when generate == true.
             return world.chunkProviderServer.getChunkAt(x, z) != null;
         }

         world.chunkProviderServer.unloadQueue.remove(x, z);
         net.minecraft.server.Chunk chunk = world.chunkProviderServer.chunks.get(LongHash.toLong(x, z));

         if (chunk == null) {
             chunk = world.chunkProviderServer.loadChunk(x, z);

             chunkLoadPostProcess(chunk, x, z);
         }
         return chunk != null;
     }

The part that catches my attention is the lack of the chunkLoadPostProcess() on the 'if (chunk == null) {' path in 1.9, versus its unconditional presence on 1.8.8. My concern (once again, not sure if it is an issue, as I haven't had time to really look at this) is that loadChunk/unloadChunk have never had a proper 'use count' style consideration - but, with the neighbor use count logic that has come along in 1.8.x, we've gotten in to some concerns there: if those neighbor counts get out of whack (due to being incremented when they shouldn't be, or not decremented when they should be, or whatever), I could see some potential for 'zombie' chunks (that were supposed to be unloaded, were not, but were otherwise removed from tick processing and such - and that don't get re-added when they should, since they are still loaded). Everyone logging off, for most folks, can result in world unloads - which I could see fixing something like that - so it is suspicious.

mikeprimm on 24 Mar 2016

@mikeprimm getOrLoadChunkAt has the post process stuff I believe

aikar on 24 Mar 2016

any updates? really itching to use dynmap again

dsfeagle on 26 Mar 2016

Same here! I've been occasionally running a fullrender at night, then disabling DynMap again, but my players really want to see the live map. Thanks in advance!

KermMartian on 26 Mar 2016

👍1

Just FYI, I had this bug happen to me, after running it for the first time on a brand new server (I had placed ~50 blocks), with a minimal plugin stack. Force-removing entities/killing mobs with LagReducer kind-of fixes the problem, but it only lasts about 130 seconds.

Qrbaker on 28 Mar 2016

OK - was able to produce problem. Confirmed that the condition that is affected by the 'if(isChunkInUse())' versus 'if (safe && isChunkInUse())' change from earlier does happen, and does seem to be relevant. I made a private build of tonights code, with that change, and was no longer able to produce the condition - that said, places where the problem previously happened appear to need to be loaded and then unloaded again before they are 'fixed' (probably due to the entities being saved with the chunks without being removed first). Private build is http://dynmap.us/spigot-1.9-R0.1-SNAPSHOT.jar - chunks around spawn with the problem seem to be able to be fixed by making sure everyone is logged off before unloading and reloading the server,

mikeprimm on 28 Mar 2016

OK - was able to produce problem. Confirmed that the condition that is affected by the 'if(isChunkInUse())' versus 'if (safe && isChunkInUse())' change from earlier does happen, and does seem to be relevant. I made a private build of tonights code, with that change, and was no longer able to produce the condition - that said, places where the problem previously happened appear to need to be loaded and then unloaded again before they are 'fixed' (probably due to the entities being saved with the chunks without being removed first). Private build is http://dynmap.us/spigot-1.9-R0.1-SNAPSHOT.jar - chunks around spawn with the problem seem to be able to be fixed by making sure everyone is logged off before unloading and reloading the server,

is that me being still too new to the spigot/minecraft server scene or the plugin yml is invalid ?

[11:11:51

ERROR]: Could not load 'plugins\spigot-1.9-R0.1-SNAPSHOT.jar' in folde
r 'plugins'
org.bukkit.plugin.InvalidDescriptionException: Invalid plugin.yml
at org.bukkit.plugin.java.JavaPluginLoader.getPluginDescription(JavaPlug
inLoader.java:154) ~[spigot-1.9.jar:git-Spigot-2038f4a-15222c8]

shibii1111 on 28 Mar 2016

@mikeprimm that issue would be because you re-added the removeEntities call.

You're now calling .removeEntities a duplicate time, when .unloadChunk is being blocked due to being unsafe.

So its removing entities from world, stopping them from ticking, but then CraftBukkit is stopping the chunk from unloading due to being unsafe.

Really need to keep my PR in, as .unloadChunk already makes the call you're making.

By calling it twice, you register the entity/tileentity for unloading twice, as .removeEntities() does not clean up its list.

If you can point out where isChunkInUse is flawed, we can fix it.

Really should not be unloading chunks thats considered in use. Need to find out where the logic issue is that dynmap thinks its safe to unload, yet its not.

Note that chunk GC will get the chunk unloaded eventually (roughly 30s)

aikar on 28 Mar 2016

Issue there is that isInUse is NOT the same as isLoaded - the only reason we call unloadChunk is that the chunk was NOT loaded when we needed it (and unload is called later in the same tick - we don't yield the thread in between - it's load-readsnapshot-unload if we needed to do the load, just snapshot if we did not). As the problem happens with or without the PR (as demonstrated by the fact that the alpha release had it, and most folks reporting the issue are running that), that isn't causing anything (and it hasn't for many releases - it may be redundant, but is harmless in that fact, since removing already removed entities isn't going to break anything, but removing them and then having an unload that isn't allowed to NOT succeed fail is a problem). The fact that the current code BREAKS the contract - the 'safe' parameter is ignored, and the behavior associated with it is no longer present - is the cause of the issue I've seen. I COULD alternately change logic to check isInUse() and avoid the unload logic entirely in that event (given the driving case is that moving players make chunks be 'inUse' before they are, in fact, loaded), if we want to give that a try.

mikeprimm on 28 Mar 2016

@shibii1111 It's a build of Spigot I linked to, not a plugin....

mikeprimm on 28 Mar 2016

@shibii1111 It's a build of Spigot I linked to, not a plugin....

I am SO sorry xD I was at work and I rushed to upload that to my server and didn't notice... I feel so stupid right now o.o'

shibii1111 on 28 Mar 2016

😄1

OK - another go at a workaround build: this time for dynmap - http://dynmap.us/builds/dynmap/dynmap-2.3-SNAPSHOT.jar - try this with unpatched current Spigot build.

mikeprimm on 29 Mar 2016

We still are getting frozen chunks on our server with the new dynmap snapshot you posted.

snarfattack on 29 Mar 2016

This new dynmap snapshot seems to have resolved the problem on our Spigot 1.9 server. Will report back if we see it happen again.

ngtflyer on 29 Mar 2016

@mikeprimm can you reconsider the re-applying my PR now that the culprit has been more adequately identified.

aikar on 29 Mar 2016

@aikar The revert was already reverted:
https://github.com/webbukkit/dynmap/commits/master

Black-Hole on 29 Mar 2016

The freeze was instant on my server and I was using the beta builds you posted.

shibii1111 on 29 Mar 2016

Using the beta build posted the freezing mobs were still happening and a little were worse actually, and happened more outside of spawn chunks than it did before. Using the newest bukkit build from buildtools.

rcfreak0 on 29 Mar 2016

ah didnt notice the revert. ok cool.

aikar on 29 Mar 2016

@rcfreak0 : "beta build posted" - can you be more specific?

If referring the a dynmap build, please report the info from '/dynmap version' command

mikeprimm on 30 Mar 2016

@mikeprimm the dynmap jar you posted a few comments up is what I meant by the beta build.

rcfreak0 on 30 Mar 2016

I can't be sure, but I think the build you posted may have reduced the issues. However, they are definitely still there.

DemonWav on 30 Mar 2016

Just to add my experiences...

Last night we upgraded to the latest build of spigot and removed dynmap from the server - the aim to start from a theoretically clear point of view and build back.

The server worked well for a few hours however around 4 hours after restarting the problem has recurred. I therefore think that while dynmap could _potentially_ be making the problem happen more often, it's clearly a spigot problem first and foremost.

Is this raised with the Spigot team yet? I've not had a good look through their issue tracker yet.

MattPeddlesden on 30 Mar 2016

@mikeprimm In case this helps I'm using the dynmap build you posted 2 days ago. See attached image. All the mobs you see in the image are frozen/stuck.

Some thoughts that I don't know if they matter:

This is close to our spawn, which is on the right side of the stone tower you see.
I'm running it with updating paused.
The players on my server have commented that this doesn't happen as much other than here near the spawn.

Dynmap version: core=2.3-SNAPSHOT-2070, plugin=2.3-SNAPSHOT-1134
Server: git-Spigot-d20369f-7fc5cd8 (MC: 1.9) (Implementing API version 1.9-R0.1-SNAPSHOT)

fdfasdfasdgf

egro5 on 31 Mar 2016

@egroeg555 Were those frozen before you started using the new update, or did they come to be frozen after starting to use it? I saw some cases where the freeze required chunk unload and load by a player, and spawn doesn't do that by default. What seemed to work to unstick those was to log everyone off, then shutdown and restart the server.

mikeprimm on 31 Mar 2016

Just a quick update.
We have observed a reduction in the "hanging mob" issue on our server but the problem persists. Mostly just outside of spawn (which stays loaded all the time) and we seemed to have lots of it going on in the End while we were exploring and Dynmap was rendering the new chunks. See image for our version info. STOPping and restarting the MC server always resolves the problem for awhile but it returns.
2016-03-31_01 09 36

ngtflyer on 31 Mar 2016

@mikeprimm Personnaly, we started fresh far from the spawn after we had that issue and never had that issue around the new place. I used the build you posted here and it was instantly happening :S

2016-03-28_22 08 23

shibii1111 on 31 Mar 2016

@mikeprimm Well a couple might have been stuck beforehand, but most aggroed on to me, moved, and I saw them get stuck. I had just stopped the server (when nobody was online), dropped in a new spigot build and the dynmap build, and started it again a few hours before.

Let us know if there is anything else we can do to help investigate this. I do have some limited experience with Java, though not sure if I'd be any help in that area.

egro5 on 31 Mar 2016

The issue has been occurring for me as well.
Dynmap version: core=2.3-SNAPSHOT-2070, plugin=2.3-SNAPSHOT-1134
This server is running CraftBukkit version git-Spigot-2038f4a-44216f1 (MC: 1.9) (Implementing API version 1.9-R0.1-SNAPSHOT)

The mobs will take one hit of damage, but further hits will not affect them while they're frozen

At the spawn chunks, only a server restart will unfreeze the mobs. At other chunks, allowing them to unload by moving out of the activation radius will resolve the issue. If the mobs were going to die from the hit they got, they actually show the death particles as they're being unloaded.

mooinglemur on 31 Mar 2016

Quick update. We upgraded to the latest Spigot build this morning.
Problem still occurs near spawn. During some testing, I have also noticed that it is much more likely to happen on any map during the dynmap render process.

Paste from our console.

ngtflyer on 31 Mar 2016

Having same issues as stated before.
Mobs freezing after 1 hit and arrows just stuck in air.
Using versions you provided:
http://dynmap.us/builds/dynmap/dynmap-2.3-SNAPSHOT.jar
http://dynmap.us/spigot-1.9-R0.1-SNAPSHOT.jar

ThatGaskin on 1 Apr 2016

Any updates?

gganno on 4 Apr 2016

I took a video. https://www.youtube.com/watch?v=-eop6bRQ1xQ

dynmap-2.3-alpha-1.jar

Disabled dynmap and everything was normal afterward. I'm hopeful that there's an update soon. :)

Uskaanax on 7 Apr 2016

👍1

If it helps, the frozen entities seems to only appear at even numbered x and z chunk coordinates. All the odd-numbered chunks seem to be working well.

chuushi on 7 Apr 2016

Once again, I offer our help if there's anything we can do to move this forward.

KermMartian on 7 Apr 2016

I've posted my message first on the reddit topic, so I share this observation here too:

Hi there.
In addition to the troubles you've mentionned here, in the same situation I got something else.
In one of those Chunks, there are few "blocks" coordinates where it is impossible to place any blocks on that, unless using worldedit. And when the area is //set, the console print this: [Server thread/INFO]: [@: Source and destination are not identical]
(This message comes, normaly, from ./testforblocks in commandblocks)
But the is no commandblock, and the area is between one "frozen" chunk, and another which is non frozen.
Does anyone of you also encountered this ?

Zyth23 on 7 Apr 2016

Started new job this week, so time hasn't been there - will try to find time to look more at this over the weekend. Last time I tried, I was having problems producing the stuck chunks with the latest dev build of dynmap and fresh BuiltTools build of Spigot. Thing to focus on is what seems to bring about a stuck chunk - how it behaves once it happens is basically incidental: chunk isn't being 'ticked', so everything else that happens is kind of obvious and doesn't help us figure out the cause. The 'even x, even z' observation above is VERY interesting - if anyone else can validate that further, that'd be great.

mikeprimm on 8 Apr 2016

Congrats on the new job!

In the past I've seen both even and odd chunks, including ones right next to each other having the issue, so either it's a new development in the problem behaviour, or just a co-incidence.

Has anyone tested with the latest Spigot in the past few days? I've noticed they have made a few changes to ticking logic. I've been meaning to turn on dynmap again and see if it's made any improvement on our server.

snarfattack on 8 Apr 2016

The 'even x, even z' observation above is VERY interesting - if anyone else can validate that further, that'd be great

That would be visible in the video I made. I left the f3 info window up for some of it.

Uskaanax on 8 Apr 2016

Has anyone tested with the latest Spigot in the past few days? I've noticed they have made a few changes to ticking logic. I've been meaning to turn on dynmap again and see if it's made any improvement on our server.

It's as though my post was ignored...

Uskaanax on 8 Apr 2016

Yeah, the issue persists with newest builds. Tested it yesterday.
On Apr 8, 2016 5:07 AM, Uskaanax [email protected] wrote:
Has anyone tested with the latest Spigot in the past few days? I've noticed they have made a few changes to ticking logic. I've been meaning to turn on dynmap again and see if it's made any improvement on our server.

It's as though my post was ignored...

—You are receiving this because you are subscribed to this thread.Reply to this email directly or view it on GitHub

FHRNet on 8 Apr 2016

As the author of said "ticking change", I assure you it is unrelated to this. That fix has been an issue for years now.

aikar on 8 Apr 2016

I've produced an updated dev build (at same link as before) that, for 1.9, avoids the unloadChunk() API in favor of unloadChunkRequest() - not as efficient, but I'm just not trusting the unloadChunk() API right now. http://dynmap.us/builds/dynmap/dynmap-2.3-SNAPSHOT.jar

mikeprimm on 8 Apr 2016

@mikeprimm nice I was going to ask you to do that anyways :)

Better on the server to let it slowly unload them based on load (and not spam too many unloads at once)

aikar on 8 Apr 2016

Not actually true - if we load a chunk, and are done with it before ticking, there is no point in saving the chunk: which is why I have always used unloadChunk() with save=false : that just discards the chunk without requiring it to be saved. Doing a normal unload, even queued, is pointless overhead, since a chunk loaded for no other reason than a dynmap render cannot and should not result in a meaningful update of its state. If the chunk was in the process of being unloaded normally (it wasn't 'active', but was in the unload queue), then it was unloadChunkRequest() was used to restore it back into the unload queue (and assure normal saving of any pending changes). On Forge, I can go a step better and just load the NBT data asynchronously, avoiding the cost of 'activating' the chunk, and allowing me to just toss the structure loaded when I'm done - way cleaner, and less of a lag concern.

mikeprimm on 8 Apr 2016

@mikeprimm I have reason to believe that the chunks that were otherwise unloaded are ticking while they're loaded and being processed by dynmap (even before your most recent changed build). I ran over a large amount of ocean with frostwalker boots at night. The chunks should have been saved with frosted ice along the track where I ran, because the chunk should have long unloaded before daybreak, but the map now shows normal water in those spots.

There could be another explanation, but I thought I'd share my observations and thoughts. Thanks for taking a look :)

mooinglemur on 8 Apr 2016

@mooinglemur Cannot be the case - the normal "loadChunk" is synchronous: we do the load, snapshot the data, and do the unloadChunk() (also synchronous) without yielding, and its done on the server thread - not opportunity for ticking, which is also done on the server thread, and not during plugin task runs. Basically, if a chunk isn't already loaded, we load-copy-discard before anyone would have a chance to 'notice' - this will not be the case with unloadChunkRequest(), where the deactivation and unload of the chunk can be delayed due to the limit on number of chunk saves initiated per tick (used to be 100 - not sure what it is now), since the 'deactivating' of the chunk requires CPU work on the server thread before the chunk is ready to be NBT encoded and pushed on to the asynchronous unload queue. That limit will result in chunks we've loaded having the opportunity to 'tick', and otherwise change state requiring persistence update (besides changes like player movements that may result in the chunk being kept versus unloaded/discarded).

mikeprimm on 8 Apr 2016

I'll let you know how it goes. Thanks!

Uskaanax on 8 Apr 2016

I just installed it on our server, and will let you know how it goes as well.

KermMartian on 8 Apr 2016

👍1

I've been using the new build for like 7 hours now, and no signs of problems.

Fun thing: If you test an old dynmap build, fire some arrows so they freeze in the air, shutdown, put new build in, start and join the server, all the arrows are going to just drop to the ground.

FHRNet on 9 Apr 2016

😄1

We've been noticing users sporadically not showing up on the map in the web interface, even though they're not hidden and are shown in the right-hand sidebar. Other than that, our users haven't complained about stuck entities or drops. I definitely am in favor of figuring out how to make this now-functioning code use a more optimized path, though. Thanks for all your hard work!

KermMartian on 9 Apr 2016

I'm another who just started a new job this week so my server has been running pretty much on auto-pilot all week. (I love how stable it is). I'll update to this new version tonight and see how it goes over the weekend. I'd like to echo KermMartian in thanking you guys for your hard work. Dynmap is a big part of our server.

ngtflyer on 9 Apr 2016

After a day of usage I see no problems. Regarding a speed of render, I see those values when rendering:
"68 ms/tile, 32.5 ms per render" on a i5-2500 dedicated box, with 2GB of RAM assigned to the server and Crucial M500 240GB SSD.

FHRNet on 9 Apr 2016

Our server has had 24 hours uptime and no issues yet!

gganno on 9 Apr 2016

@mikeprimm I have a theory on the issue.
I am betting the chunk is getting unloaded, the entities get put into the worlds "Entity Unload Queue", but then after you unload the chunk, something else then loads the chunk back, and causes those entities to get re-activated, but not removed from the queue.

Ultimately I think this is CB's responsibility to handle, but should at least explain why we are seeing this.

aikar on 9 Apr 2016

@aikar That's an interesting one - wasn't actually aware of the entity unload queue (been kind of out of the CB modding loop for a while :) ), but the theory sounds like a good one. I'll try to give it a peek, too.

mikeprimm on 10 Apr 2016

We've been running for 3 days now. No more crashes, no frozen mobs. The only problem I've seen is some oddity in the map itself where it's not updating 100% of the tiles.

Uskaanax on 11 Apr 2016

@uakaanax
Do you have it set to update on player move? Otherwise it only updates for things like falling gravel/placed/removed blocks which may cause such patterns to occur

dsfeagle on 11 Apr 2016

lol, as it happens, just a few minutes after posting the above, I logged in to check that setting and found:

`10:40:19 ERROR: The server has stopped responding!
10:40:19 ERROR: Please report this to http://www.spigotmc.org/
10:40:19 ERROR: Be sure to include ALL relevant console errors and Minecraft crash reports
10:40:19 ERROR: Spigot version: git-Spigot-944aa20-8d16fc0 (MC: 1.9.2)

10:40:19 ERROR: Server thread dump (Look for plugins here before reporting to Spigot!):

10:40:20 ERROR: Current Thread: Server thread
10:40:20 ERROR: PID: 15 | Suspended: false | Native: false | State: RUNNABLE

10:40:20 ERROR: Entire Thread Dump:

10:51:25 ERROR: Current Thread: process reaper
10:51:25 ERROR: PID: 962 | Suspended: false | Native: false | State: RUNNABLE

10:51:25 ERROR: java.lang.UNIXProcess.waitForProcessExit(Native Method)

10:51:25 ERROR: Current Thread: Netty Epoll Server IO #3
10:51:25 ERROR: PID: 29 | Suspended: false | Native: false | State: RUNNABLE

10:51:25 ERROR: io.netty.channel.epoll.Native.epollWait(Native Method)

10:51:25 ERROR: Current Thread: Chunk I/O Executor Thread-1
10:51:25 ERROR: PID: 53 | Suspended: false | Native: false | State: WAITING

10:51:25 ERROR: sun.misc.Unsafe.park(Native Method)

10:40:20 ERROR: Entire Thread Dump:

10:51:25 ERROR: Current Thread: process reaper
10:51:25 ERROR: PID: 962 | Suspended: false | Native: false | State: RUNNABLE

10:51:25 ERROR: java.lang.UNIXProcess.waitForProcessExit(Native Method)

10:51:25 ERROR: Current Thread: Netty Epoll Server IO #3
10:51:25 ERROR: PID: 29 | Suspended: false | Native: false | State: RUNNABLE

10:51:25 ERROR: io.netty.channel.epoll.Native.epollWait(Native Method)

10:51:25 ERROR: Current Thread: Chunk I/O Executor Thread-1
10:51:25 ERROR: PID: 53 | Suspended: false | Native: false | State: WAITING

10:51:25 ERROR: sun.misc.Unsafe.park(Native Method)

10:51:25 ERROR: Current Thread: Netty Epoll Server IO #2
10:51:25 ERROR: PID: 28 | Suspended: false | Native: false | State: RUNNABLE

10:51:25 ERROR: io.netty.channel.epoll.Native.epollWait(Native Method)

10:51:25 ERROR: Current Thread: Netty Epoll Server IO #1
10:51:25 ERROR: PID: 27 | Suspended: false | Native: false | State: RUNNABLE

10:51:25 ERROR: io.netty.channel.epoll.Native.epollWait(Native Method)

10:51:25 ERROR: Current Thread: pool-6-thread-3
10:51:25 ERROR: PID: 49 | Suspended: false | Native: false | State: TIMED_WAITING

10:51:25 ERROR: sun.misc.Unsafe.park(Native Method)

10:51:25 ERROR: Current Thread: File IO Thread
10:51:25 ERROR: PID: 47 | Suspended: false | Native: false | State: TIMED_WAITING

10:51:25 ERROR: java.lang.Thread.sleep(Native Method)

10:51:25 ERROR: Current Thread: pool-6-thread-2 Acceptor0 [email protected]:8123
10:51:25 ERROR: PID: 41 | Suspended: false | Native: true | State: RUNNABLE
10:51:25 ERROR: Thread is waiting on monitor(s):
10:51:25 ERROR: Locked on:sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:250)

10:51:25 ERROR: sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)

10:51:25 ERROR: Current Thread: pool-6-thread-1 Selector0
10:51:25 ERROR: PID: 40 | Suspended: false | Native: false | State: RUNNABLE
10:51:25 ERROR: Thread is waiting on monitor(s):
10:51:25 ERROR: Locked on:sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87)
10:51:25 ERROR: Locked on:sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87)
10:51:25 ERROR: Locked on:sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87)

10:51:25 ERROR: sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)

10:51:25 ERROR: Current Thread: HashSessionScavenger-0
10:51:25 ERROR: PID: 39 | Suspended: false | Native: false | State: TIMED_WAITING

10:51:25 ERROR: java.lang.Object.wait(Native Method)

10:51:25 ERROR: Current Thread: Dynmap Render Thread
10:51:25 ERROR: PID: 36 | Suspended: false | Native: false | State: WAITING

10:51:25 ERROR: sun.misc.Unsafe.park(Native Method)

10:51:25 ERROR: Current Thread: Dynmap Render Thread
10:51:25 ERROR: PID: 35 | Suspended: false | Native: false | State: TIMED_WAITING

10:51:25 ERROR: sun.misc.Unsafe.park(Native Method)

10:51:25 ERROR: Current Thread: Dynmap Render Thread
10:51:25 ERROR: PID: 34 | Suspended: false | Native: false | State: WAITING

10:51:25 ERROR: sun.misc.Unsafe.park(Native Method)

10:51:25 ERROR: Current Thread: Thread-10
10:51:25 ERROR: PID: 33 | Suspended: false | Native: false | State: WAITING

10:51:25 ERROR: sun.misc.Unsafe.park(Native Method)

10:51:25 ERROR: Current Thread: Abandoned connection cleanup thread
10:51:25 ERROR: PID: 31 | Suspended: false | Native: false | State: TIMED_WAITING

10:51:25 ERROR: java.lang.Object.wait(Native Method)

10:51:25 ERROR: Current Thread: Netty Epoll Server IO #0
10:51:25 ERROR: PID: 26 | Suspended: false | Native: false | State: RUNNABLE

10:51:25 ERROR: io.netty.channel.epoll.Native.epollWait(Native Method)

10:51:25 ERROR: Current Thread: Spigot Metrics Thread
10:51:25 ERROR: PID: 24 | Suspended: false | Native: false | State: TIMED_WAITING

10:51:25 ERROR: java.lang.Object.wait(Native Method)

10:51:25 ERROR: Current Thread: Spigot Watchdog Thread
10:51:25 ERROR: PID: 23 | Suspended: false | Native: false | State: RUNNABLE

10:51:25 ERROR: sun.management.ThreadImpl.dumpThreads0(Native Method)

10:51:25 ERROR: Current Thread: Java2D Disposer
10:51:25 ERROR: PID: 21 | Suspended: false | Native: false | State: WAITING

10:51:25 ERROR: java.lang.Object.wait(Native Method)

10:51:25 ERROR: Current Thread: Server console handler
10:51:25 ERROR: PID: 18 | Suspended: false | Native: true | State: RUNNABLE
10:51:25 ERROR: Thread is waiting on monitor(s):
10:51:25 ERROR: Locked on:java.io.BufferedInputStream.read(BufferedInputStream.java:254)
10:51:25 ERROR: Locked on:org.bukkit.craftbukkit.libs.jline.internal.NonBlockingInputStream.read(NonBlockingInputStream.java:169)
10:51:25 ERROR: Locked on:org.bukkit.craftbukkit.libs.jline.internal.InputStreamReader.read(InputStreamReader.java:261)
10:51:25 ERROR: Locked on:org.bukkit.craftbukkit.libs.jline.internal.InputStreamReader.read(InputStreamReader.java:198)

10:51:25 ERROR: java.io.FileInputStream.readBytes(Native Method)

10:51:25 ERROR: Current Thread: Thread-5
10:51:25 ERROR: PID: 19 | Suspended: false | Native: false | State: RUNNABLE
10:51:25 ERROR: Thread is waiting on monitor(s):
10:51:25 ERROR: Locked on:java.io.BufferedInputStream.read(BufferedInputStream.java:254)

10:51:25 ERROR: java.io.FileInputStream.readBytes(Native Method)

10:51:25 ERROR: Current Thread: DestroyJavaVM
10:51:25 ERROR: PID: 17 | Suspended: false | Native: false | State: RUNNABLE

10:51:25 ERROR: Current Thread: Server thread
10:51:25 ERROR: PID: 15 | Suspended: false | Native: false | State: RUNNABLE

10:51:25 ERROR: Current Thread: Server Infinisleeper
10:51:25 ERROR: PID: 16 | Suspended: false | Native: false | State: TIMED_WAITING

10:51:25 ERROR: java.lang.Thread.sleep(Native Method)

10:51:25 ERROR: Current Thread: NonBlockingInputStreamThread
10:51:25 ERROR: PID: 13 | Suspended: false | Native: false | State: WAITING

10:51:25 ERROR: java.lang.Object.wait(Native Method)

10:51:25 ERROR: Current Thread: Snooper Timer
10:51:25 ERROR: PID: 11 | Suspended: false | Native: false | State: TIMED_WAITING

10:51:25 ERROR: java.lang.Object.wait(Native Method)

10:51:25 ERROR: Current Thread: Signal Dispatcher
10:51:25 ERROR: PID: 4 | Suspended: false | Native: false | State: RUNNABLE

10:51:25 ERROR: Current Thread: Finalizer
10:51:25 ERROR: PID: 3 | Suspended: false | Native: false | State: WAITING

10:51:25 ERROR: java.lang.Object.wait(Native Method)

10:51:25 ERROR: Current Thread: Reference Handler
10:51:25 ERROR: PID: 2 | Suspended: false | Native: false | State: WAITING

10:51:25 ERROR: java.lang.Object.wait(Native Method)

org.bukkit.plugin.IllegalPluginAccessException: Plugin attempted to register task while disabled
at org.bukkit.craftbukkit.v1_9_R1.scheduler.CraftScheduler.validate(CraftScheduler.java:400) ~[spigot-1.9.2.jar:git-Spigot-944aa20-8d16fc0]
at org.bukkit.craftbukkit.v1_9_R1.scheduler.CraftScheduler.runTaskTimer(CraftScheduler.java:123) ~[spigot-1.9.2.jar:git-Spigot-944aa20-8d16fc0]
at org.bukkit.craftbukkit.v1_9_R1.scheduler.CraftScheduler.scheduleSyncRepeatingTask(CraftScheduler.java:119) ~[spigot-1.9.2.jar:git-Spigot-944aa20-8d16fc0]
at org.bukkit.craftbukkit.v1_9_R1.scheduler.CraftScheduler.scheduleSyncDelayedTask(CraftScheduler.java:102) ~[spigot-1.9.2.jar:git-Spigot-944aa20-8d16fc0]
at org.dynmap.bukkit.DynmapPlugin$BukkitServer.scheduleServerTask(DynmapPlugin.java:214) ~[?:?]
at org.dynmap.markers.impl.MarkerAPIImpl$DoFileWrites.run(MarkerAPIImpl.java:351) ~[?:?]
at org.bukkit.craftbukkit.v1_9_R1.scheduler.CraftTask.run(CraftTask.java:71) ~[spigot-1.9.2.jar:git-Spigot-944aa20-8d16fc0]
at org.bukkit.craftbukkit.v1_9_R1.scheduler.CraftScheduler.mainThreadHeartbeat(CraftScheduler.java:350) [spigot-1.9.2.jar:git-Spigot-944aa20-8d16fc0]
at net.minecraft.server.v1_9_R1.MinecraftServer.D(MinecraftServer.java:729) [spigot-1.9.2.jar:git-Spigot-944aa20-8d16fc0]
at net.minecraft.server.v1_9_R1.DedicatedServer.D(DedicatedServer.java:400) [spigot-1.9.2.jar:git-Spigot-944aa20-8d16fc0]
at net.minecraft.server.v1_9_R1.MinecraftServer.C(MinecraftServer.java:660) [spigot-1.9.2.jar:git-Spigot-944aa20-8d16fc0]
at net.minecraft.server.v1_9_R1.MinecraftServer.run(MinecraftServer.java:559) [spigot-1.9.2.jar:git-Spigot-944aa20-8d16fc0]
at java.lang.Thread.run(Thread.java:745) [?:1.7.0_95]
org.bukkit.plugin.IllegalPluginAccessException: Plugin attempted to register task while disabled
at org.bukkit.craftbukkit.v1_9_R1.scheduler.CraftScheduler.validate(CraftScheduler.java:400) ~[spigot-1.9.2.jar:git-Spigot-944aa20-8d16fc0]
at org.bukkit.craftbukkit.v1_9_R1.scheduler.CraftScheduler.runTaskTimer(CraftScheduler.java:123) ~[spigot-1.9.2.jar:git-Spigot-944aa20-8d16fc0]
at org.bukkit.craftbukkit.v1_9_R1.scheduler.CraftScheduler.scheduleSyncRepeatingTask(CraftScheduler.java:119) ~[spigot-1.9.2.jar:git-Spigot-944aa20-8d16fc0]
at org.bukkit.craftbukkit.v1_9_R1.scheduler.CraftScheduler.scheduleSyncDelayedTask(CraftScheduler.java:102) ~[spigot-1.9.2.jar:git-Spigot-944aa20-8d16fc0]
at org.dynmap.bukkit.DynmapPlugin$BukkitServer.scheduleServerTask(DynmapPlugin.java:214) ~[?:?]
at org.dynmap.InternalClientUpdateComponent$3.run(InternalClientUpdateComponent.java:95) ~[?:?]
at org.bukkit.craftbukkit.v1_9_R1.scheduler.CraftTask.run(CraftTask.java:71) ~[spigot-1.9.2.jar:git-Spigot-944aa20-8d16fc0]
at org.bukkit.craftbukkit.v1_9_R1.scheduler.CraftScheduler.mainThreadHeartbeat(CraftScheduler.java:350) [spigot-1.9.2.jar:git-Spigot-944aa20-8d16fc0]
at net.minecraft.server.v1_9_R1.MinecraftServer.D(MinecraftServer.java:729) [spigot-1.9.2.jar:git-Spigot-944aa20-8d16fc0]
at net.minecraft.server.v1_9_R1.DedicatedServer.D(DedicatedServer.java:400) [spigot-1.9.2.jar:git-Spigot-944aa20-8d16fc0]
at net.minecraft.server.v1_9_R1.MinecraftServer.C(MinecraftServer.java:660) [spigot-1.9.2.jar:git-Spigot-944aa20-8d16fc0]
at net.minecraft.server.v1_9_R1.MinecraftServer.run(MinecraftServer.java:559) [spigot-1.9.2.jar:git-Spigot-944aa20-8d16fc0]
at java.lang.Thread.run(Thread.java:745) [?:1.7.0_95]
`
I'm unsure if this is related to dynmap specifically.

Uskaanax on 11 Apr 2016

Tried out the snapshot version with the latest spigot build last night. CPU use seems a bit high when rendering, but I didn't notice any issues with gameplay.

Tayrtahn on 13 Apr 2016

Quick update. We updated Spigot code and installed this latest snapshot and despite some busy nights, we have not experienced 'hanging entities' at all on our server since. We did regenerate our resource map and do a fullrender once worldborder had finished generating. We got a little bit of "checkerboard" effect in the render but those spots updated as people entered those chunks.
CPU and memory haven't really changed for us, but we have sort of a beast for a server. (It says Poweredge on it :)
Cheers and thanks for the hard work. It is much appreciated!

ngtflyer on 14 Apr 2016

The Spigot server has been running well since moving away from unloadChunk() API. I'd like to take a time to say thank you for the continuous updates and support!

I do hope there'll be a more optimal solution in the near future.

chuushi on 15 Apr 2016

Seems to have issues where dynmap will "freeze", and will just show black and won't announce render updates to the console until the server is reloaded or restarted. This happens after the server is reloaded when dynmap has froze:

I use MySQL for my tile storage, though, and I don't think this issue happens with file tree storage.
This is running your most recent build, linked above.

DemonWav on 16 Apr 2016

Maybe your MySQL server is overloaded and needs more memory. If you are on a dedicated server and installed MySQL without any tweaking, it has just 64M of memory available, which is not enough for even a small Minecraft server.
On Apr 16, 2016 8:08 AM, Kyle Wood [email protected] wrote:Seems to have issues where dynmap will "freeze", and will just show black and won't announce render updates to the console until the server is reloaded or restarted. This happens after the server is reloaded when dynmap has froze:

I use MySQL for my tile storage, though, and I don't think this issue happens with file tree storage.

—You are receiving this because you are subscribed to this thread.Reply to this email directly or view it on GitHub

FHRNet on 16 Apr 2016

For the time being I've moved back to file tree and it's working fine, no stuck chunks that I know of. I'll keep that in mind if I have to go back to MySQL at some point.

DemonWav on 17 Apr 2016

I installed latest and while mobs were no longer freezing, carts are still getting stuck on chunk borders.

joelday on 28 Apr 2016

Joelday, are these unmanned or have riders? I haven't seen that issue on our server and we have a couple of long rail lines. Would like to try to reproduce myself.
-B

ngtflyer on 28 Apr 2016

With riders.

joelday on 28 Apr 2016

Thanks. We are running current Dynmap and Spigot code, we'll give it a go this evening and see if we experience the same issue.

ngtflyer on 28 Apr 2016

Awesome. @mikeprimm I'd be happy to help with this (and other stuff), I just don't currently know the best way to set up an environment for actual running/testing with interactive debugging.

joelday on 28 Apr 2016

If you're referring to me, I could spin up another VM and copy our whole server to it, map another set of ports to it.. We haven't had any complaints about minecarts. What should I look for? Cart stops with the player in it at chunk borders or does it appear the cart stops and player continues? We have an issue with horses and minecarts where the player position isn't being sent to other clients but the horse or cart is still moving. Related?

ngtflyer on 28 Apr 2016

@ngtfltyer No, the player position not updating isn't related. We have this issue (with boats as well) without Dynmap installed.

ghost on 28 Apr 2016

SioWolf, Yeah I've known that to be a Bukkit/Spigot bug for a long time.

ngtflyer on 28 Apr 2016

With the upgrade to 1.9.4, suddenly every chunk that gets loaded never gets unloaded from the /tps accounting. We have (apparently) 14,000+ chunks loaded with 3 players online after just about 4 hours of uptime. Has anyone else experienced this? I haven't tried disabling DynMap and restarting yet to see if it fixes the issue; if I do, I'll report the results.

KermMartian on 11 May 2016

After two hours without DynMap, the loaded chunk count has climbed from ~1K to ~6K with around 5 online players. So false alarm, not DynMap's fault, presumably.

KermMartian on 11 May 2016

I can also confirm the chunk unload issue is not Dynmap specific.

gganno on 11 May 2016

Just do what I did guys and rollback your minecraft version to 1.9.2 for the time being. I think it has something to do with the following post on spigot.

https://www.spigotmc.org/threads/spigot-craftbukkit-bungeecord-1-9-4.146517/

adrianpinnock on 11 May 2016

We updated the Spigot code to the latest version as of last night and the chunk unload problem has been greatly improved if not totally resolved for us. Coming home to a server with 22,000 chunks and nearly 35,000 tiles loaded running at 12TPS is no fun!

ngtflyer on 12 May 2016

Use Paper if you want the chunk issue to be fully resolved plus many other performance improvements.

Paper is an enhanced version of Spigot maintained by myself, Z750 and other well known devs that has much faster development than Spigot. Just please come to our IRC channel #paper instead of #spigot for support.

aikar on 12 May 2016

👎1

Faster development? But you guys aren't up to 1.9.4 yet. ;)
Might spin a VM up and give that a thorough test. Thanks for the suggestion.

ngtflyer on 12 May 2016

Faster development? But you guys aren't up to 1.9.4 yet. ;)

Uhhh, you must not be up to speed then. Been on 1.9.4 for nearly a day now.

zachbr on 12 May 2016

@Zbob750 you aren't either, paper is only on 1.9.2 according to their website.

gganno on 12 May 2016

👍1

The website may not be up-to-date given that it was released less than 24 hours ago.
I can assure you, being that I watched it get updated, merged the 1.9.4 branch into master, and am capable of actually checking the source, that it is on 1.9.4.

Edit: I have restructured the index page to remove the explicit version information, given how eager everyone is to pick a fight about something stupid instead of just check the source code. Enjoy.

zachbr on 12 May 2016

@ngtfltyer Spigot had days/weeks to prep for 1.9.4. We get nothing until Spigot releases. Z and I were busy the day of release, but for overall general development is what my comment referenced.

Big updates are always special.

aikar on 13 May 2016

We're always open to trying out anything that will improve the experience for our players. We'll spin a VM up and get in a good thorough test before a decision is made. Our server just celebrated it's 5th year anniversary and we have a pretty loyal player community. We need to check our set of plugins to make sure everything works as it should. We have a very good reputation when it comes to our stability, uptime and performance.
When time allows, we will get some testing done!
I'd like to push this thread back on track to dynmap, we are on a tangent here.

ngtflyer on 13 May 2016

Ultimately, this issue should be closed as it has been fixed for a long time, and anything new is a new issue.

aikar on 13 May 2016

👍1

@aikar said:

Use Paper if you want the chunk issue to be fully resolved plus many other performance improvements.

Paper is an enhanced version of Spigot maintained by myself, Z750 and other well known devs that has much faster development than Spigot. Just please come to our IRC channel #paper instead of #spigot for support.

Ultimately, this issue should be closed as it has been fixed for a long time, and anything new is a new issue.

Your post of 6 days ago, and all posts since then, do not relate to solving the problem in this thread and are generally not constructive. Everyone subscribed to this thread is looking for a new, or current build, from @mikeprimm and not seeking server alternatives. After having read the thread over again, I'm sure that you're trying to be helpful, and I know you'll get back on subject.

@mikeprimm: Congrats on the new job! Don't forget to update the official post (http://www.minecraftforum.net/forums/mapping-and-modding/minecraft-mods/1286593-dynmap-dynamic-web-based-maps-for-minecraft) with the latest build when you have an opportunity. I think there are a lot of people watching that thread more than this one.

Uskaanax on 18 May 2016

@uskananax because the issue is resolved and people asked a question which deserved an answer. Someone please close this

aikar on 20 May 2016

This issue has come back in the 1.10 update. Using the latest spigot build.

gganno on 10 Jun 2016

Still occuring, someone is explorating new chunks and the dynmap is probably the culprit again: http://i.qcfb.ca/201606092195407.png

@gganno Probably not related to 1.10 itself, but Dynmap again. I'm still on 1.9.2

EDIT: The player who kept exploring chunks disconnected, so I guess it cleared out the loaded chunks. Try this (if your player did explore new chunks)

TNTUP on 10 Jun 2016

I can confirm this issue has returned in 1.10. We are running Spigot 1.10 with current dynmap and have the issue near our spawn.
2016-06-09_21 45 22

ngtflyer on 10 Jun 2016

The fix mike put in was not very long term and only fixes it for 1.9.

Honestly, I think its better to just let the server handle it more naturally instead of forcing it, and Id suggest always using unloadRequest mike.

aikar on 10 Jun 2016

Well I just looked at the commit and see the very obvious problem

isBadUnload = Bukkit.getServer().getBukkitVersion().contains("1.9");

Probably this needs to be fixed to check for > 1.9, not == 1.9 (a string comparison isn't really suitable for either though :P)

jacob1 on 10 Jun 2016

I was looking at spigot commits and one from two days ago seems relevant, maybe it fixes the original chunk unloading issue? https://hub.spigotmc.org/stash/projects/SPIGOT/repos/craftbukkit/commits/1953f52da1ece0feb56dea20592c1b86616b31a5

Of course, the 1.9/1.10 workaround is working totally fine. I just thought that commit looked interesting.

jacob1 on 24 Jun 2016

@jacob1 no it does not. I can not figure out what dynmap is triggering, but its in the unloadChunk() logic.

I ran dynmap on my custom fork, which broke the 1.9 detection logic, and even with my patches to fix the CraftWorld logics, it still had issues.

So, I still have no solution for dynmap at this time but to keep away from .unloadChunk(x, z);

aikar on 24 Jun 2016

Btw, dynmaps 'fix' is perfectly fine to be permanent. the only change is that dynmap was trying to save some performance by avoiding saving chunks it thinks did not need saving.

aikar on 24 Jun 2016

Dynmap: Dynmap Causing Mob and Chunk Issues

All 126 comments

Related issues