java.io.UTFDataFormatException: encoded string too long: 65538 bytes

[lightning02]

**Server Log: http://www.mediafire.com/download/0xfdwx0tha7aj48/latest.log

**FML Log(s): http://pastebin.com/vwc6scuR

**Explanation of issue: I noticed that the server have some problem keeping up a large area located in a rf tools dimension, this area consist in about 8 Platform 50x50 covered with mekanism stuff, a bit of liquid transfer node from extra utilities, and few igneous extruder from TE, 4 tesseracts and 6 energy capacitor from galacticraft (kinda useless) some flan's mod mecha to decorate, a BetterRecords music implant, and 3 webdisplays screen and 4 chunk loader from chickenchunks, the area on the map looks kinda like this;

Well, the problem is the console spam of this error "java.io.UTFDataFormatException: encoded string too long: 65538 bytes", but I can't barely believe that this says "chunks there are too heavy for thermos" But I have to admit that when I removed the 4 chunk loaders and went off the RFtools dimension the error spam stopped.. When I came back in the dimension the server had trouble.. (the server has 32gb of ram and a xeon cpu :/ [I don't remember the cores and the frequency], well, people get timed out and sometime also get this weird rendering error (at java: no source) http://pastebin.com/c0bEnmT6 By the way, the last rendering error was avoided entering the area from another direction, loading chunks each one slowly... Once the area was loaded entirely again the "ava.io.UTFDataFormatException: encoded string too long: 65538 byte" error returned in the console spam. Is there something that can be done? :/ Any suggestion?

**How to recreate this issue: not advisable to recreate, kinda hard, and just to build a complex like that with many platforms full fo stuffs would take literally days

**Mods Installed: http://pastebin.com/PaAtMEUJ

**Plugins Installed: worldedit

**Thermos Version: Build 55

**Forge Version:1614

[spannerman79]

Did you try this exact same setup with a vanilla forge server instance?

I got this feeling that you have reached the limit of RFTools.

As you have stated its impossible to re-create this issue easily and quickly so its up to you to try this exact same setup on a vanilla forge instance.

[lightning02]

I can try to make the world where this complex has been made run on the vanilla-forge server instead of Thermos and see if I get the error if is this you're sayng, by the way, I have the suspect that any building complex that is "too heavy" would results in this error, at least for thermos.. but still, is just a suspect

[ghost]

@lightning02 Are you using BungeeCord?

EDIT: You will want to tell the user making so many Solar Evaporation structures to tone it down, reason being, those multiblock structures are horrible for causing multiple orphaned Tile Entities in the same coordinates.

[lightning02]

@iKaneki-Ken If you mean BungeeCord the plugin/proxy, then no, as I stated in the beginning I've only worldedit and no more, btw I've set connection-throttle to -1 in bukkit.yml to allow people to log in in the server (otherwise they got dc since the modpack is heavy)

[lightning02]

@spannerman79 Well, shame to me, I did not made a backup of the world recently... After I managed to stop the console spam after manually removing and repositioning the chunkloaders (and set them with a fewer chunk-action-range), well, then everyone was getting Timed Out error when tryng to log-in... it was like the server was ticking or couldn't keep up anymore, for unknow reason. This situation prevented me to destroy all the chunkloaders once and for all or even disable the dimension.. The longest time I had after log-in was 4-5 seconds, and with alot of lag, then I got timed-out. I don't know what happened and why, seems like that all overloaded for no reason at all (expecially because that complex was there since 1 or 2 weeks.. this problem popped-up suddenly just yesterday). So, I had no possibility to test the world in forge-server completely, but I tryed anyway, I noticed that the vanilla forge server was sayng in the console that it was lagging badly, even if I had no possibility to log-in because of the timed-out. In the client log I've seen this all the time by the way; [Netty Client IO #2/ERROR] [FML]: NetworkDispatcher exception io.netty.handler.timeout.ReadTimeoutException

At the end I had to bring up an old backup of the server world, when everything was working. What is really weird is that almost nobody logged in the server in the last week, so no real changes were made in the world that would justify this issue to pop-up this way with no reason at all...

I resolved for now, but I'm afraid this problem would come back someday... and I have no clue how to face it

[spannerman79]

I resolved for now, but I'm afraid this problem would come back someday... and I have no clue how to face it

We as always to ensure that it is in fact a Thermos issue run a copy of the world with the same mods and mod configs on a vanilla forge server instance. If the same or similar issue happens then its forge related.

[ghost]

@lightning02 That honestly sounds like a buildup of NBT data. Because chunks that are being loaded by one person need to be downloaded by all players. I actually had the same issue with Extra Bees.

[sameer]

Minecraft limits the amount of data that can be held. That amount of information in an NBT stream is ridiculous, as such the system attempts to prevent you from saving it.

This is not caused by Thermos and is rather a limitation imposed by all of Minecraft.

[lightning02]

@Robotia ridiculously low you mean, right? :/ is there nothing that can be done about this? some workaround?

[sameer]

Sorry for the confusion, I meant ridiculously high. :confused: This cannot really be changed, as I am not sure how it would affect the saving of data server-side.

This is also a duplicate of a related, closed issue: https://github.com/CyberdyneCC/Thermos/issues/215