failure in acquiring the write lock

[Jacobus Geluk]

Hi, getting this error while loading the geonames dataset at some point, what does this mean? I mean how can this be caused if there's no other traffic to the cluster than just this big upload and some smaller ones (like loading ontologies and setting namespaces)?

ERROR 2015-11-30 13:46:29,982 [SPEC-Server-1-13] com.complexible.stardog.pack.replication.ReplicationCoordinatorTransaction:<init>(70): There was a failure in acquiring the write lock for the transaction a14447a7-37b8-4c66-8a63-e720eac22f22

java.lang.IllegalMonitorStateException: You do not own the lock: /locks/transaction/RW

at org.apache.curator.framework.recipes.locks.InterProcessMutex.release(InterProcessMutex.java:128) ~[stardog-pack-replication-dbms-4.0.jar:?]

at com.complexible.common.curator.framework.locks.InterProcessSemaphoreReadWriteLock.getLease(InterProcessSemaphoreReadWriteLock.java:186) ~[stardog-pack-replication-dbms-4.0.jar:?]

at com.complexible.common.curator.framework.locks.InterProcessSemaphoreReadWriteLock.access$400(InterProcessSemaphoreReadWriteLock.java:31) ~[stardog-pack-replication-dbms-4.0.jar:?]

at com.complexible.common.curator.framework.locks.InterProcessSemaphoreReadWriteLock$ReadLock.acquire(InterProcessSemaphoreReadWriteLock.java:86) ~[stardog-pack-replication-dbms-4.0.jar:?]

at com.complexible.stardog.pack.replication.ReplicationCoordinatorTransaction.<init>(ReplicationCoordinatorTransaction.java:63) [stardog-pack-replication-dbms-4.0.jar:?]

at com.complexible.stardog.pack.replication.ReplicationConnectableConnection.join(ReplicationConnectableConnection.java:183) [stardog-pack-replication-dbms-4.0.jar:?]

at com.complexible.stardog.db.ConnectableConnectionCollection.join(ConnectableConnectionCollection.java:76) [stardog-4.0.jar:?]

at com.complexible.stardog.db.DatabaseConnectionImpl.begin(DatabaseConnectionImpl.java:293) [stardog-4.0.jar:?]

at com.complexible.stardog.db.DatabaseConnectionImpl.begin(DatabaseConnectionImpl.java:272) [stardog-4.0.jar:?]

at com.complexible.stardog.db.DatabaseImpl$DBConnectionWrapper.begin(DatabaseImpl.java:1324) [stardog-4.0.jar:?]

at com.complexible.stardog.db.DelegatingDatabaseConnection.begin(DelegatingDatabaseConnection.java:258) [stardog-4.0.jar:?]

at com.complexible.stardog.StardogKernel$KernelDbConnection.begin(StardogKernel.java:2717) [stardog-4.0.jar:?]

at com.complexible.stardog.db.DelegatingDatabaseConnection.begin(DelegatingDatabaseConnection.java:258) [stardog-4.0.jar:?]

at com.complexible.stardog.StardogKernel$NotifyingDatabaseConnection.begin(StardogKernel.java:2913) [stardog-4.0.jar:?]

at com.complexible.stardog.db.DelegatingDatabaseConnection.begin(DelegatingDatabaseConnection.java:258) [stardog-4.0.jar:?]

at com.complexible.stardog.pack.replication.ReplicatedKernelImpl$1.begin(ReplicatedKernelImpl.java:1546) [stardog-pack-replication-dbms-4.0.jar:?]

at com.complexible.stardog.protocols.server.SPECServerFunction.beginTx(SPECServerFunction.java:354) [stardog-protocols-spec-server-4.0.jar:?]

at com.complexible.stardog.protocols.server.SPECServerFunction.handleMessage(SPECServerFunction.java:158) [stardog-protocols-spec-server-4.0.jar:?]

at com.complexible.common.protocols.server.rpc.ServerHandler.handleMessage(ServerHandler.java:324) [stardog-protocols-api-server-4.0.jar:?]

at com.complexible.common.protocols.server.rpc.ServerHandler.channelRead(ServerHandler.java:207) [stardog-protocols-api-server-4.0.jar:?]

at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:308) [netty-all-4.0.32.Final.jar:4.0.32.Final]

at io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:32) [netty-all-4.0.32.Final.jar:4.0.32.Final]

at io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:299) [netty-all-4.0.32.Final.jar:4.0.32.Final]

at io.netty.util.concurrent.DefaultEventExecutor.run(DefaultEventExecutor.java:36) [netty-all-4.0.32.Final.jar:4.0.32.Final]

at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112) [netty-all-4.0.32.Final.jar:4.0.32.Final]

at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137) [netty-all-4.0.32.Final.jar:4.0.32.Final]

at java.lang.Thread.run(Thread.java:745) [?:1.8.0_51]

[Fernando Hernandez]

Hi,

On Mon, Nov 30, 2015 at 2:34 PM, Jacobus Geluk <jacobu...@gmail.com> wrote:

Hi, getting this error while loading the geonames dataset at some point, what does this mean? I mean how can this be caused if there's no other traffic to the cluster than just this big upload and some smaller ones (like loading ontologies and setting namespaces)?

It seems like the error message might be misleading, but Stardog Cluster will acquire a write lock during a transaction and it won't release it until it's done writing. If you were doing a large upload while trying to do some other small ones, it is expected that the smaller ones would time out on lock acquisition if the large upload isn't done within the timeout. You can increase the acquire timeout to prevent this, but Stardog will still wait until the large upload is done before processing the other small writes.

You can use the property `pack.node.timeouts.lock.write` (which takes a `Duration` - see [1]). The default is 30 minutes but you can adjust it depending on your needs.

[1] http://docs.stardog.com/#_stardog_configuration 

Cheers,

Fernando

 

--
-- --
You received this message because you are subscribed to the C&P "Stardog" group.
To post to this group, send email to sta...@clarkparsia.com
To unsubscribe from this group, send email to
stardog+u...@clarkparsia.com
For more options, visit this group at
http://groups.google.com/a/clarkparsia.com/group/stardog?hl=en

[Jacobus Geluk]

But what kind of lock is that then? The whole database?

[Michael Grove]

On Tue, Dec 1, 2015 at 2:52 PM, Jacobus Geluk <jacobu...@gmail.com> wrote:

But what kind of lock is that then? The whole database?

Yes.  Only one transaction can be active at a time, same as the single node.  The write lock timeout that Fernando mentioned controls how long subsequent commits will wait before aborting.

Cheers,

Mike

 

--