When the server is empty then mod starts print log every tick.

screen: https://img.bymarcin.com/screenshot-2016-12-05_00-09-39.png
screen: https://img.bymarcin.com/screenshot-2016-12-05_00-08-46.png

IndustrialWires-1.1-3.jar

Yeah, I need to fix this ASAP. Only it isn't happening with my setup and I haven't got any idea on how to fix this...
@marcin212 could you post some pictures of the area mentioned in the log (dimension 30004, around -100/70/-200)? I asume that is a base in an RFTools dimension? Is it chunkloaded? If so, with what loader? What version of IC2 (EDIT) and what other mods (/EDIT) are you using?
@Aroma1997 what could cause this message to be printed? A TE that is part of the IC2 net but isn't loaded in world any more? EDIT2: Btw, what is the IC2 teams opinion on decompiling IC2? I remember seeing a fair amount of forum posts on the IC2 forum about decompiled code, but those were pretty old.

Ok, I have no idea what is going on. I tested about every configuration that I could think of (with regards to chunkborders, all in an RFTools dimension) and the only weird thing I noticed is that the connectors that aren't loaded run through the cycle "UNLOAD INVALIDATE LOAD" every few minutes. I know IC2 doesn't like TE's being removed from the net twice, I fixed that, but even before that fix I couldn't get that message to print even once.
@marcin212 I don't know whether that will help me at all, but it would be nice if you could send me a log with those errors using this build of IndustrialWires. I would suggest you start the server, let it spew out errors for a few seconds and the shut it down. There is a TINY chance that this build fixed the problem by preventing the TE from un-registering twice, if that is the case, I won't need a log.

@malte0811 It is RFTools dimension.

• screen at 100, 200: https://img.bymarcin.com/screenshot-2016-12-05_17-51-28.png
• 1 chunkloader from ic2 at -21,-300
• screen at -21, -300: https://img.bymarcin.com/screenshot-2016-12-05_17-53-43.png
• modlist http://hastebin.com/fihelusaqa.txt

Log cut down to the relevant parts: https://gist.github.com/malte0811/7a70cd5173971448ce439bf48535c0fb
I have found a potential cause for this (but no fix yet): Something seems to be replacing TE's with new instances without calling either invalidate or onChunkUnload first. ADDED is only printed to the log if a new TE ticks for the first time (or a TE that was properly removed (which would cause stuff to be logged) ticks again). In line 138 the TE at -78/70/-230 is added to the net. In lines 166/167 the TE tries to re-add itself, but fails. This indicates that a new TE was created at the same position without properly removing the old one. I guess that when the TE tries to remove itself from the net (l. 172 and 187), it is only removed half-way because the TE that was added to the net is different (according to hashCode and equals) from the one that is removed (even though the BlockPos is the same). This might cause the IC2 net to error (I am just guessing here, but it would make sense).
...and after writing this, I have an idea for a potential fix, I will post a link to a build with the potential fix and better debug messages (in case the fix does not work) soon (probably within the next 30 minutes).

@marcin212 https://www.dropbox.com/s/8lds6cdwhwmpp8y/IndustrialWires-1.1-3.jar?dl=0
Same as with the build I gave you yesterday: If the build doesn't fix the spam, I need a log. Otherwise please tell me that the new build fixed the spam.

log: https://dl.dropboxusercontent.com/u/25172450/bugs/u2/fml-server-latest.log

Ok, I thought about this and your explanation would make sense. The IC2 Enet holds 2 references to energy emitters. One as value in a HashMap with the key being the BlockPos and the other one directly in a HashSet. The message gets logged, when they are in the Set, but not in the map.
Unregistering a tile from the enet, where a different tile was loaded at that pos will cause that log spam.

log after 30min: https://dl.dropboxusercontent.com/u/25172450/bugs/u2/1/fml-server-latest.log

Yay, my fix (or rather workaround) seems to be working. I will release a version containing this workaround (without the general log spam) tomorrow, but I still want to figure out what caused this since the new log shows TE's being replaced without calling invalidate as well.

I put that workaround thing into IC2 as well, so that situation doesn't appear again. Thank you for pointing out, that it might be caused by a different tile being unloaded as the one previously being loaded.
Calling unload from a different tile is still fishy though and slowly, but surely, I think, it's a bug in the te states in vanilla.