TickThreading - concurrent entity/tile entity ticks and other optimisations

  • The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord

nallar

New Member
Jul 29, 2019
270
0
0
Added some more profiling with the "/profile" command, see "/profile usage".

Looks good, I checked this fix with a backup copy of my server and it seems resolved, or at least it hasn't crashed after ~3 hours.
I will need to wait for a CC fix or workaround before running it on the live server again, as Bad Things happen when Computers/Turtles don't start up properly.
With the current build I can't replicate the issue with turtles/computers - can you check all logs for anything odd? :(

I might have fixed it accidentally in anything after build 587, or it's just not happening here.
 

TruculentMC

New Member
Jul 29, 2019
130
0
0
Added some more profiling with the "/profile" command, see "/profile usage".


With the current build I can't replicate the issue with turtles/computers - can you check all logs for anything odd? :(

I might have fixed it accidentally in anything after build 587, or it's just not happening here.

Hmm, I checked in all the logs, and don't see anything. I do remember seeing something in the console about ComputerCraft but it doesn't seem to have been written to a log (which is strange), and the IC2 API debug spam scrolled it out of the buffer in screen before I thought to save it. I should be able to easily reproduce it in build #560 & snag the exception as I kept that install backed up. Also I will double check it in the latest as well to see if I can reproduce. I may not have time until this weekend though.
 
  • Like
Reactions: nallar

MomoNasty

New Member
Jul 29, 2019
74
0
0
hey nallar tickthreading was working for me before on dwolf20v4 but for some reason i get this error now when trying to patch on dwolf20v5. http://pastebin.com/kWmw71uS. Btw i have set all my files permissions to 755 in that directory. I have tried this as root user and the user the server directory is under but get this severe message each time.

I have used both build 475 as well as the newest stable-ish build. Thanks in advance :)
 

nallar

New Member
Jul 29, 2019
270
0
0
hey nallar tickthreading was working for me before on dwolf20v4 but for some reason i get this error now when trying to patch on dwolf20v5. http://pastebin.com/kWmw71uS. Btw i have set all my files permissions to 755 in that directory. I have tried this as root user and the user the server directory is under but get this severe message each time.

I have used both build 475 as well as the newest stable-ish build. Thanks in advance :)
You probably still have a program running with that file open.

Run `lsof | grep modularforcefieldsystem` to check what has it open
 

MomoNasty

New Member
Jul 29, 2019
74
0
0
running `lsof | grep modularforcefieldsystem` doesnt show up anything ;/, tryed closing the MCMA backend and then patching still no cigar :(
 

nallar

New Member
Jul 29, 2019
270
0
0
running `lsof | grep modularforcefieldsystem` doesnt show up anything ;/, tryed closing the MCMA backend and then patching still no cigar :(
I've made some changes in the latest build to how temporary files are handled, could you try using it?

It may be buggy in other ways though :(
 

TruculentMC

New Member
Jul 29, 2019
130
0
0
Nallar - 629 seems to be working quite well for us, running stable with 4-6 players for a few hours now. I do have one thing from the server logs to report, which is caused by carrying a Barrel around with the Portal Gun:


2013-01-26 14:57:22 [SEVERE] [TickThreading] Inconsistent state, a tile entity is in the wrong TickRegion
entity: class factorization.common.TileEntityBarrel at x,y,z:-172,57,379
Has hashcode: 1507318
Region: rX: -10, rZ: -10, hashCode: -655370
2

It doesn't seem to affect the Barrel or it's contents, at least that I could tell anyways. It does seem to cause some inconsistencies when picking up and placing barrels down with the Portal Gun, they don't always drop in the expected position. I didn't check with other entities but it's probably worth investigating - might cause some more severe issues & I didn't want to crash our live server. :)

(P.S. I still want to replicate that CC issue in the older build, will try this afternoon, but it doesn't seem to be happening in #629 anymore.)
 

nallar

New Member
Jul 29, 2019
270
0
0
That log is probably expected when moving a tile entity with a portal gun, as it changes its location. It isn't really safe for mods to move tile entities, unless the tile entity being moved supports it. They should probably create new tile entities on movement instead, and just use the same nbt tag data to load it.

By "they don't always drop in the expected position", do you mean that it is in a close but not correct location, or way off where it should be? If it's near to where it should be, it's probably just portalgun being derpy - it normally does that.
 

TruculentMC

New Member
Jul 29, 2019
130
0
0
Not just being derpy, I was able to repeatedly get a barrel to appear 2-3 chunks away from where I dropped it, but that could be just PortalGun though. I'd expect a few blocks away to be normal, but chunks? seem a bit off. To repro, pick up a barrel, fly 6-8 chunks away and let go some blocks above the ground.
 

TruculentMC

New Member
Jul 29, 2019
130
0
0
Few more things from the log today. I checked the tube at these coords and I'm not seeing anything out of the ordinary, I wasn't on the server when it occurred so I don't know what might have caused it or how to repro... I'll keep an eye on it though.

01-26 17:40:50 [SEVERE] [TickThreading] Exception during tile entity tick
ticking: class com.eloraam.redpower.machine.TileTube at x,y,z:-751,91,259
Tick region: rX: -46, rZ: 16, hashCode: 1048530:
java.util.ConcurrentModificationException
at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:953)
at java.util.LinkedList$ListItr.next(LinkedList.java:886)
at com.eloraam.redpower.machine.TileTube.sendItemUpdate(TileTube.java:444)
at com.eloraam.redpower.machine.TileTube.g(TileTube.java:172)
at me.nallar.tickthreading.minecraft.tickregion.TileEntityTickRegion.doTick(TileEntityTickRegion.java:84)
at me.nallar.tickthreading.minecraft.tickregion.TickRegion.run(TickRegion.java:88)
at me.nallar.tickthreading.minecraft.ThreadManager$2.run(ThreadManager.java:88)
at me.nallar.tickthreading.minecraft.ThreadManager$1.run(ThreadManager.java:39)
at me.nallar.tickthreading.minecraft.ThreadManager$ServerWorkThread.run(ThreadManager.java:149)
01-26 17:45:50 [SEVERE] [TickThreading] Exception during tile entity tick
ticking: class com.eloraam.redpower.machine.TileTube at x,y,z:-751,91,259
Tick region: rX: -46, rZ: 16, hashCode: 1048530:
java.util.ConcurrentModificationException
at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:953)
at java.util.LinkedList$ListItr.next(LinkedList.java:886)
at com.eloraam.redpower.machine.TileTube.sendItemUpdate(TileTube.java:444)
at com.eloraam.redpower.machine.TileTube.g(TileTube.java:172)
at me.nallar.tickthreading.minecraft.tickregion.TileEntityTickRegion.doTick(TileEntityTickRegion.java:84)
at me.nallar.tickthreading.minecraft.tickregion.TickRegion.run(TickRegion.java:88)
at me.nallar.tickthreading.minecraft.ThreadManager$2.run(ThreadManager.java:88)
at me.nallar.tickthreading.minecraft.ThreadManager$1.run(ThreadManager.java:39)
at me.nallar.tickthreading.minecraft.ThreadManager$ServerWorkThread.run(ThreadManager.java:149)



I see this one many times in the server log, but I think this is possibly a known IC2 bug with foam cables, and not a problem with TickThreading.

2013-01-26 18:30:32 [WARNING] [IC2] addContinuousTickCallback with world = null, callback = ic2.core.block.wiring.TileEntityCable$1@79a566f9
2013-01-26 18:30:32 [INFO] [STDERR] java.lang.Exception: Stack trace
2013-01-26 18:30:32 [INFO] [STDERR] at java.lang.Thread.dumpStack(Thread.java:1342)
2013-01-26 18:30:32 [INFO] [STDERR] at ic2.core.IC2.addContinuousTickCallback(IC2.java:1908)
2013-01-26 18:30:32 [INFO] [STDERR] at ic2.core.block.wiring.TileEntityCable.changeFoam(TileEntityCable.java:518)
2013-01-26 18:30:32 [INFO] [STDERR] at ic2.core.block.wiring.TileEntityCable.a(TileEntityCable.java:82)
2013-01-26 18:30:32 [INFO] [STDERR] at any.c(TileEntity.java:150)
2013-01-26 18:30:32 [INFO] [STDERR] at aam.a(AnvilChunkLoader.java:418)
2013-01-26 18:30:32 [INFO] [STDERR] at aam.a(AnvilChunkLoader.java:103)
2013-01-26 18:30:32 [INFO] [STDERR] at aam.a(AnvilChunkLoader.java:74)
2013-01-26 18:30:32 [INFO] [STDERR] at im.f(ChunkProviderServer.java:119)
2013-01-26 18:30:32 [INFO] [STDERR] at im.c(ChunkProviderServer.java:152)
2013-01-26 18:30:32 [INFO] [STDERR] at im.d(ChunkProviderServer.java:108)
2013-01-26 18:30:32 [INFO] [STDERR] at yc.e(World.java:524)
2013-01-26 18:30:32 [INFO] [STDERR] at yc.a(World.java:407)
2013-01-26 18:30:32 [INFO] [STDERR] at yc.m(World.java:815)
2013-01-26 18:30:32 [INFO] [STDERR] at yc.h(World.java:801)
2013-01-26 18:30:32 [INFO] [STDERR] at ic2.core.block.wiring.TileEntityElectricBlock.g(TileEntityElectricBlock.java:198)
2013-01-26 18:30:32 [INFO] [STDERR] at me.nallar.tickthreading.minecraft.tickregion.TileEntityTickRegion.doTick(TileEntityTickRegion.java:84)
2013-01-26 18:30:32 [INFO] [STDERR] at me.nallar.tickthreading.minecraft.tickregion.TickRegion.run(TickRegion.java:88)
2013-01-26 18:30:32 [INFO] [STDERR] at me.nallar.tickthreading.minecraft.ThreadManager$2.run(ThreadManager.java:88)
2013-01-26 18:30:32 [INFO] [STDERR] at me.nallar.tickthreading.minecraft.ThreadManager$1.run(ThreadManager.java:39)
2013-01-26 18:30:32 [INFO] [STDERR] at me.nallar.tickthreading.minecraft.ThreadManager$ServerWorkThread.run(ThreadManager.java:149)
 

TruculentMC

New Member
Jul 29, 2019
130
0
0
I'm able to reproduce the CC startup program issue in #269 by zoning to/from Nether, it seems something about loading or unloading worlds maybe?
1) Place Turtle in Nether, create startup program.
2) Zone to Overworld, wait 1-2 mins.
3) Zone back to Nether, Turtle won't be running startup program anymore.

Turtle is a Melee Turtle and the startup program is very simply:
Code:
while true do
turtle.attack()
sleep(.05)
end
 

DZCreeper

New Member
Jul 29, 2019
1,469
0
1
I am very sorry nallar. I went to look at the changes for the recent builds. I was presented with admin style options, such as promote build, wipe out workspace, configure, and delete project. I thought there must be some sort of mistake, maybe its only my local client. So I changed build 662 to Testing - Unstable, and to my shock it stayed permanent across a page refresh. You might want to fix that, as I wasn't even logged in, and other people might be able to do the same.

Edit: I changed it back to None, and it appears to have worked.

Edit 2: I can also start new builds, haven't and won't dare test things like wipe project.
 

TheSandwichMakr

New Member
Jul 29, 2019
582
0
0
I am very sorry nallar. I went to look at the changes for the recent builds. I was presented with admin style options, such as promote build, wipe out workspace, configure, and delete project. I thought there must be some sort of mistake, maybe its only my local client. So I changed build 662 to Testing - Unstable, and to my shock it stayed permanent across a page refresh. You might want to fix that, as I wasn't even logged in, and other people might be able to do the same.

Edit: I changed it back to None, and it appears to have worked.
It's not just you, it also gives me all those options.