Contract Violation

[Eelviny]

Don't know if this has been reported already, but using the latest version 2.2.2.398, this error is shown after every player login and logoff:

[00:53:09 INFO]: Eelviny lost connection: Disconnected
[00:53:09 WARN]: Exception in thread "Craft Scheduler Thread - 1175" 
[00:53:09 WARN]: org.apache.commons.lang.UnhandledException: Plugin CommunityBridge v2.2.2.398 generated an exception while executing task 681610
        at org.bukkit.craftbukkit.v1_7_R2.scheduler.CraftAsyncTask.run(CraftAsyncTask.java:56)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:724)
Caused by: de.cubeisland.engine.core.contract.ContractViolationError: Must be executed from main thread!
        at de.cubeisland.engine.core.contract.Contract.expect(Contract.java:35)
        at de.cubeisland.engine.core.bukkit.BukkitWorldManager.getWorld(BukkitWorldManager.java:95)
        at de.cubeisland.engine.vaultlink.service.CubePermissionService.getPlayerGroups(CubePermissionService.java:410)
        at org.communitybridge.permissionhandlers.PermissionHandlerVault.getGroups(PermissionHandlerVault.java:37)
        at org.communitybridge.main.PlayerGroupState.generate(PlayerGroupState.java:38)
        at org.communitybridge.main.WebApplication.synchronizeGroups(WebApplication.java:516)
        at org.communitybridge.main.WebApplication.synchronizePlayer(WebApplication.java:423)
        at org.communitybridge.main.WebApplication.access$000(WebApplication.java:30)
        at org.communitybridge.main.WebApplication$1.run(WebApplication.java:382)
        at org.bukkit.craftbukkit.v1_7_R2.scheduler.CraftTask.run(CraftTask.java:67)
        at org.bukkit.craftbukkit.v1_7_R2.scheduler.CraftAsyncTask.run(CraftAsyncTask.java:53)
        ... 3 more

[iain-davis]

That is surprising, I would have thought it would have complained about that before this.

I'll probably have to make the Vault api calls synchronous, might slow the player login process a bit.

[iain-davis]

To make sure I'm testing against the same stuff that generated the error, can you tell me the exact version of Vault and CubeEngine that generated the error?

[Eelviny]

Sorry - didn't see your message! Vault 1.2.31 CubeEngine is still in development - there is no version as such to tell you, but here's the tree: https://github.com/CubeEngineDev/CubeEngine/tree/5d870f89 https://docs.google.com/file/d/0B3TNkHJpuS42TXR5cTNCcTBLY3M/edit The main cubeengine jar is needed, along with the vaultlink, selector, conomy and roles modules (vaultlink currently only uses hard dependencies)

[pschichtel]

Just to sum up what I wrote in our issue: We internally enforce single threaded access to worlds to prevent threading issues from our side.

[iain-davis]

I'll either need to revise the permission handler for Vault or write one specific to Cube. It may be a while, there are other issues I have to take care of first...including UUID support.

I've a concern about writing a wrapper for something whose API might be changing, though. If Cube is alpha enough to not have releases, that sounds like a moving target to me. :)

[pschichtel]

Well that should not be necessary. But accessing anything world related in an async way is risky and can cause serious problems. That's the reason, why we internally prevent ourselves from accidentally doing so. The CubeEngine is getting more stable these days and "not having releases" is not actually true, our release are just not very often atm. The vault API is subject to change sooner or later though.