StardogException: There was a fatal failure during preparation of 34b0be89-a397-4576-84f5-055efb8cc9

[Tze-John Tang]

I am using Stardog 3.0.  When pushing a specific set of tuples in RDF/JSON format, I am getting the StardogException regarding a failure to prepare the RDF index.  This is when committing the addition of the graph.  I am going to troubleshoot this further, but I was wondering if anyone else had any suggestions?  The stack trace looks like:

Caused by: com.complexible.stardog.StardogException: There was a fatal failure during preparation of 34b0be89-a397-4576-84f5-055efb8cc98b RDF index prepare failed

        at com.complexible.stardog.protocols.client.SPECClientUtil.toStardogException(SPECClientUtil.java:80) ~[stardog-protocols-spec-client-3.0.jar:na]

        at com.complexible.stardog.protocols.client.SPECClientUtil.toStardogException(SPECClientUtil.java:32) ~[stardog-protocols-spec-client-3.0.jar:na]

        at com.complexible.stardog.api.impl.SPECConnection._commit(SPECConnection.java:260) ~[stardog-api-3.0.jar:na]

        at com.complexible.stardog.api.impl.AbstractConnection.commit(AbstractConnection.java:195) ~[stardog-api-3.0.jar:na]

        at com.complexible.stardog.api.impl.DelegatingConnection.commit(DelegatingConnection.java:111) ~[stardog-api-3.0.jar:na]

        at abbvie.gprd.rdf.service.loaders.tuples.TuplesLoader.load(TuplesLoader.java:116) ~[TuplesLoader.class:na]

        ... 35 common frames omitted

Caused by: com.complexible.common.protocols.client.ClientException: There was a fatal failure during preparation of 34b0be89-a397-4576-84f5-055efb8cc98b RDF index prepare failed

        at com.complexible.common.protocols.client.rpc.DefaultRPCClient.get(DefaultRPCClient.java:344) ~[stardog-protocols-api-client-3.0.jar:na]

        at com.complexible.common.protocols.client.rpc.DefaultRPCClient.execute(DefaultRPCClient.java:321) ~[stardog-protocols-api-client-3.0.jar:na]

        at com.complexible.stardog.protocols.snarl.client.SNARLClientImpl.commit(SNARLClientImpl.java:425) ~[stardog-protocols-snarl-client-3.0.jar:na]

        at com.complexible.stardog.protocols.snarl.client.SNARLClientImpl.commit(SNARLClientImpl.java:70) ~[stardog-protocols-snarl-client-3.0.jar:na]

        at com.complexible.stardog.api.impl.SPECConnection._commit(SPECConnection.java:255) ~[stardog-api-3.0.jar:na]

        ... 38 common frames omitted

Caused by: java.lang.Exception: There was a fatal failure during preparation of 34b0be89-a397-4576-84f5-055efb8cc98b RDF index prepare failed

        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[na:1.7.0_60]

        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) ~[na:1.7.0_60]

        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[na:1.7.0_60]

        at java.lang.reflect.Constructor.newInstance(Constructor.java:526) ~[na:1.7.0_60]

        at com.complexible.barc.DefaultThrowableCodec.decode(DefaultThrowableCodec.java:89) ~[stardog-protocols-barc-shared-3.0.jar:na]

        at com.complexible.barc.BigPacketCodec.toException(BigPacketCodec.java:393) ~[stardog-protocols-barc-shared-3.0.jar:na]

        at com.complexible.barc.BigPacketCodec.decode(BigPacketCodec.java:360) ~[stardog-protocols-barc-shared-3.0.jar:na]

        at com.complexible.barc.BigPacketDecoder.channelRead(BigPacketDecoder.java:75) ~[stardog-protocols-barc-shared-3.0.jar:na]

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

        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:294) ~[netty-all-4.0.25.Final.jar:4.0.25.Final]

        at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103) ~[netty-all-4.0.25.Final.jar:4.0.25.Final]

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

        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:294) ~[netty-all-4.0.25.Final.jar:4.0.25.Final]

        at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:182) ~[netty-all-4.0.25.Final.jar:4.0.25.Final]

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

        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:294) ~[netty-all-4.0.25.Final.jar:4.0.25.Final]

        at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:846) ~[netty-all-4.0.25.Final.jar:4.0.25.Final]

        at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:130) ~[netty-all-4.0.25.Final.jar:4.0.25.Final]

        at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511) ~[netty-all-4.0.25.Final.jar:4.0.25.Final]

        at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468) ~[netty-all-4.0.25.Final.jar:4.0.25.Final]

        at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382) ~[netty-all-4.0.25.Final.jar:4.0.25.Final]

        at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354) ~[netty-all-4.0.25.Final.jar:4.0.25.Final]

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

        ... 1 common frames omitted

[Tze-John Tang]

It looks the there is some issue in my triple store... the following are some errors from the server log.  Persisting is an issue, querying is not at this moment.  What should be my next steps to rectify this?

[SEVERE com.complexible.tx.api.impl.DefaultTransaction.computePrepareResult - Jun 15, 2015 05:26:15.695] There was a fatal failure during preparation of 8aff5afd-d331-46fa-a49a-6aad66cc924e

com.complexible.tx.api.ResourceTransactionException: RDF index prepare failed

        at com.complexible.stardog.db.index.ConnectableIndexRWConnectionImpl$IndexResourceTransaction.prepare(ConnectableIndexRWConnectionImpl.java:442)

        at com.complexible.tx.api.BaseResourceTransaction.prepare(BaseResourceTransaction.java:198)

        at com.complexible.tx.api.impl.DefaultTransaction.computePrepareResult(DefaultTransaction.java:469)

        at com.complexible.tx.api.impl.DefaultTransaction.runPreparePhase(DefaultTransaction.java:432)

        at com.complexible.tx.api.impl.DefaultTransaction.commit(DefaultTransaction.java:325)

        at com.complexible.stardog.db.DatabaseConnectionImpl.commit(DatabaseConnectionImpl.java:345)

        at com.complexible.stardog.db.DatabaseImpl$DBConnectionWrapper.commit(DatabaseImpl.java:1285)

        at com.complexible.stardog.db.DelegatingDatabaseConnection.commit(DelegatingDatabaseConnection.java:269)

        at com.complexible.stardog.StardogKernel$KernelDbConnection.commit(StardogKernel.java:2564)

        at com.complexible.stardog.db.DelegatingDatabaseConnection.commit(DelegatingDatabaseConnection.java:269)

        at com.complexible.stardog.StardogKernel$NotifyingDatabaseConnection.commit(StardogKernel.java:2873)

        at com.complexible.stardog.protocols.server.SPECServerFunction.commitTx(SPECServerFunction.java:369)

        at com.complexible.stardog.protocols.server.SPECServerFunction.handleMessage(SPECServerFunction.java:153)

        at com.complexible.common.protocols.server.rpc.ServerHandler.handleMessage(ServerHandler.java:264)

        at com.complexible.common.protocols.server.rpc.ServerHandler.channelRead(ServerHandler.java:147)

        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:308)

        at io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:32)

        at io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:299)

        at io.netty.util.concurrent.DefaultEventExecutor.run(DefaultEventExecutor.java:36)

        at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)

        at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)

        at java.lang.Thread.run(Thread.java:745)

Caused by: com.complexible.stardog.index.IndexException: Inconsistent index size for OSP; expected=22293658, got= 22293256

        at com.complexible.stardog.index.AbstractIndexData.verifySizes(AbstractIndexData.java:246)

        at com.complexible.stardog.index.AbstractIndexData.createIndexes(AbstractIndexData.java:230)

        at com.complexible.stardog.index.AggregateIndexData.<init>(AggregateIndexData.java:47)

        at com.complexible.stardog.index.SingletonIndexData.updateDifferential(SingletonIndexData.java:102)

        at com.complexible.stardog.index.SingletonIndexData.update(SingletonIndexData.java:90)

        at com.complexible.stardog.index.IndexWriterDataMapImpl.applyChanges(IndexWriterDataMapImpl.java:217)

        at com.complexible.stardog.index.IndexWriterImpl.prepare(IndexWriterImpl.java:185)

        at com.complexible.stardog.index.impl.DelegatingIndexWriter.prepare(DelegatingIndexWriter.java:134)

        at com.complexible.stardog.db.index.ConnectableIndexRWConnectionImpl$IndexResourceTransaction.prepare(ConnectableIndexRWConnectionImpl.java:437)

        ... 21 more

[SEVERE com.complexible.stardog.db.DatabaseConnectionImpl.commit - Jun 15, 2015 05:26:15.696] There was an error committing the transaction, all changes were rolled back successfully

com.complexible.tx.api.HeuristicRollbackException: There was a fatal failure during preparation of 8aff5afd-d331-46fa-a49a-6aad66cc924e RDF index prepare failed

        at com.complexible.tx.api.impl.DefaultTransaction.doRollback(DefaultTransaction.java:614)

        at com.complexible.tx.api.impl.DefaultTransaction.runPreparePhase(DefaultTransaction.java:435)

        at com.complexible.tx.api.impl.DefaultTransaction.commit(DefaultTransaction.java:325)

        at com.complexible.stardog.db.DatabaseConnectionImpl.commit(DatabaseConnectionImpl.java:345)

        at com.complexible.stardog.db.DatabaseImpl$DBConnectionWrapper.commit(DatabaseImpl.java:1285)

        at com.complexible.stardog.db.DelegatingDatabaseConnection.commit(DelegatingDatabaseConnection.java:269)

        at com.complexible.stardog.StardogKernel$KernelDbConnection.commit(StardogKernel.java:2564)

        at com.complexible.stardog.db.DelegatingDatabaseConn

-tj

[Tze-John Tang]

The first exception on the server, which mentions the index inconsistency is:

[WARNING com.complexible.stardog.index.AbstractIndexData.updateInPlace - Jun 12, 2015 10:00:33.319] Error updating index

com.complexible.stardog.index.IndexException: Inconsistent index size for OSP; expected=22283725, got= 22283407

        at com.complexible.stardog.index.AbstractIndexData.verifySizes(AbstractIndexData.java:246)

        at com.complexible.stardog.index.AbstractIndexData.updateInPlace(AbstractIndexData.java:311)

        at com.complexible.stardog.index.AbstractIndexData.update(AbstractIndexData.java:255)

        at com.complexible.stardog.index.AggregateIndexData.update(AggregateIndexData.java:229)

        at com.complexible.stardog.index.IndexWriterDataMapImpl.applyChanges(IndexWriterDataMapImpl.java:217)

        at com.complexible.stardog.index.IndexWriterImpl.prepare(IndexWriterImpl.java:185)

        at com.complexible.stardog.index.impl.DelegatingIndexWriter.prepare(DelegatingIndexWriter.java:134)

        at com.complexible.stardog.db.index.ConnectableIndexRWConnectionImpl$IndexResourceTransaction.prepare(ConnectableIndexRWConnectionImpl.java:437)

        at com.complexible.tx.api.BaseResourceTransaction.prepare(BaseResourceTransaction.java:198)

        at com.complexible.tx.api.impl.DefaultTransaction.computePrepareResult(DefaultTransaction.java:469)

        at com.complexible.tx.api.impl.DefaultTransaction.runPreparePhase(DefaultTransaction.java:432)

        at com.complexible.tx.api.impl.DefaultTransaction.commit(DefaultTransaction.java:325)

        at com.complexible.stardog.db.DatabaseConnectionImpl.commit(DatabaseConnectionImpl.java:345)

        at com.complexible.stardog.db.DatabaseImpl$DBConnectionWrapper.commit(DatabaseImpl.java:1285)

        at com.complexible.stardog.db.DelegatingDatabaseConnection.commit(DelegatingDatabaseConnection.java:269)

        at com.complexible.stardog.StardogKernel$KernelDbConnection.commit(StardogKernel.java:2564)

        at com.complexible.stardog.db.DelegatingDatabaseConnection.commit(DelegatingDatabaseConnection.java:269)

        at com.complexible.stardog.StardogKernel$NotifyingDatabaseConnection.commit(StardogKernel.java:2873)

        at com.complexible.stardog.protocols.server.SPECServerFunction.commitTx(SPECServerFunction.java:369)

        at com.complexible.stardog.protocols.server.SPECServerFunction.handleMessage(SPECServerFunction.java:153)

        at com.complexible.common.protocols.server.rpc.ServerHandler.handleMessage(ServerHandler.java:264)

        at com.complexible.common.protocols.server.rpc.ServerHandler.channelRead(ServerHandler.java:147)

        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:308)

        at io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:32)

        at io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:299)

        at io.netty.util.concurrent.DefaultEventExecutor.run(DefaultEventExecutor.java:36)

        at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)

        at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)

        at java.lang.Thread.run(Thread.java:745)

-tj

[Michael Grove]

On Mon, Jun 15, 2015 at 7:48 AM, Tze-John Tang <tzejoh...@gmail.com> wrote:

The first exception on the server, which mentions the index inconsistency is:

If you run repair [1] does that resolve the issue?

Cheers,

Mike

[1] http://docs.stardog.com/man/db-repair.html

 

--
-- --
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

[Tze-John Tang]

Mike,

If I take an existing backup (after the inconsistency), and restore it on another system. And test the repair there... is that a viable option?  The problem is that the instance has the issues is one where users are using it during the day.  The retrieval from the store is fine, so I am planning on leaving that up until after hours today.  But if I could test the repair elsewhere prior to that, that would also help in troubleshooting.

What do you think?

-tj

[Michael Grove]

On Mon, Jun 15, 2015 at 8:29 AM, Tze-John Tang <tzejoh...@gmail.com> wrote:

Mike,

If I take an existing backup (after the inconsistency), and restore it on another system. And test the repair there... is that a viable option?  The problem is that the instance has the issues is one where users are using it during the day.  The retrieval from the store is fine, so I am planning on leaving that up until after hours today.  But if I could test the repair elsewhere prior to that, that would also help in troubleshooting.

You shouldn't need to repair the backup, it's created from the SPO index, which given the error message, seems intact.

Did you have a hard shutdown on the server that could have caused the checksum issue?

Cheers,

Mike

[Tze-John Tang]

Mike,

There was no hard shutdown.  The server has been up and running since May 26th.

My question about the backup was whether I could try the repair on some other system by cloning the existing one.  This way I would not interrupt any users, depending on how long it takes to repair.

-tj

[Michael Grove]

On Mon, Jun 15, 2015 at 8:52 AM, Tze-John Tang <tzejoh...@gmail.com> wrote:

Mike,

There was no hard shutdown.  The server has been up and running since May 26th.

My question about the backup was whether I could try the repair on some other system by cloning the existing one.  This way I would not interrupt any users, depending on how long it takes to repair.

Yes, that should work fine.

Cheers,

Mike

[Tze-John Tang]

I took the latest backup and restored on a different server.  That instance does not exhibit the same issues as the current running instance. I could not replicate the index inconsistency issue after bringing it up.

-tj

[Tze-John Tang]

However, when I try to execute the repair on the restored from backup instance, I get the exception below.  I have seen no issues adding new triples though.. which is strange.

[stardog@aws00001d data]$ stardog-admin db repair kg2

Trying to repair kg2 database, this might take a while depending on database size.

[WARNING com.complexible.stardog.index.AbstractIndexData.updateInPlace - Jun 15, 2015 07:09:17.164] Error updating index

java.util.concurrent.ExecutionException: com.complexible.stardog.index.IndexException: Write error: 4088 != 8186

        at java.util.concurrent.FutureTask.report(FutureTask.java:122)

        at java.util.concurrent.FutureTask.get(FutureTask.java:188)

        at com.complexible.common.util.concurrent.ExecutionGroup$1.executeAndWait(ExecutionGroup.java:78)

        at com.complexible.stardog.index.AbstractIndexData.updateInPlace(AbstractIndexData.java:303)

        at com.complexible.stardog.index.AbstractIndexData.update(AbstractIndexData.java:255)

        at com.complexible.stardog.index.SingletonIndexData.updateDirect(SingletonIndexData.java:98)

        at com.complexible.stardog.index.SingletonIndexData.update(SingletonIndexData.java:93)

        at com.complexible.stardog.index.IndexWriterDataMapImpl.applyChanges(IndexWriterDataMapImpl.java:217)

        at com.complexible.stardog.index.disk.ConcurrentDiskIndexLoader.build(ConcurrentDiskIndexLoader.java:145)

        at com.complexible.stardog.index.disk.ConcurrentDiskIndexLoader.build(ConcurrentDiskIndexLoader.java:63)

        at com.complexible.stardog.index.io.IndexIO.repair(IndexIO.java:871)

        at com.complexible.stardog.StardogKernel.<init>(StardogKernel.java:408)

        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)

        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)

        at java.lang.reflect.Constructor.newInstance(Constructor.java:526)

        at com.google.inject.internal.DefaultConstructionProxyFactory$2.newInstance(DefaultConstructionProxyFactory.java:85)

        at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:85)

        at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:254)

        at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)

        at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1031)

        at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)

        at com.google.inject.Scopes$1$1.get(Scopes.java:65)

        at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40)

        at com.google.inject.internal.FactoryProxy.get(FactoryProxy.java:54)

        at com.google.inject.internal.InjectorImpl$4$1.call(InjectorImpl.java:978)

        at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1024)

        at com.google.inject.internal.InjectorImpl$4.get(InjectorImpl.java:974)

        at com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1013)

        at com.complexible.stardog.Stardog.initKernel(Stardog.java:198)

        at com.complexible.stardog.Stardog.<init>(Stardog.java:193)

        at com.complexible.stardog.Stardog.initialize(Stardog.java:262)

        at com.complexible.stardog.Stardog.initialize(Stardog.java:253)

        at com.complexible.stardog.Stardog.buildServer(Stardog.java:246)

        at com.complexible.stardog.cli.impl.Repair.call(Repair.java:49)

        at com.complexible.stardog.cli.impl.Repair.call(Repair.java:21)

        at com.complexible.stardog.cli.CLIBase.execute(CLIBase.java:54)

        at com.complexible.stardog.cli.admin.CLI.main(CLI.java:194)

Caused by: com.complexible.stardog.index.IndexException: Write error: 4088 != 8186

        at com.complexible.stardog.index.disk.btree.impl.BPlusTreeImpl$EmptyBulkUpdater.value(BPlusTreeImpl.java:690)

        at com.complexible.stardog.index.IndexUpdaters.update(IndexUpdaters.java:78)

        at com.complexible.stardog.index.AbstractIndexData$UpdateIndex.call(AbstractIndexData.java:379)

        at com.complexible.stardog.index.AbstractIndexData$UpdateIndex.call(AbstractIndexData.java:352)

        at java.util.concurrent.FutureTask.run(FutureTask.java:262)

        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:745)

Caused by: java.io.IOException: Write error: 4088 != 8186

        at com.complexible.common.io.disk.ChannelFile.write(ChannelFile.java:229)

        at com.complexible.common.io.impl.SinglePage$Writer.flush(SinglePage.java:227)

        at com.complexible.stardog.index.disk.compression.AbstractDataCompressor$2.flush(AbstractDataCompressor.java:273)

        at com.complexible.common.io.impl.PageObjectWriterImpl.flushPage(PageObjectWriterImpl.java:107)

        at com.complexible.common.io.impl.PageObjectWriterImpl.write(PageObjectWriterImpl.java:69)

        at com.complexible.stardog.index.disk.btree.impl.BPlusTreeImpl$EmptyBulkUpdater.value(BPlusTreeImpl.java:686)

        ... 7 more

Database kg2 is invalid and the repair failed: Problem while building index

[Evren Sirin]

Stardog uses the tmp directory while repairing a database and I think
the most probable explanation for this repair error is that the system
ran out of tmp disk space. The other possibility is some other
hardware issue that prevents Stardog from writing to tmp. You can
either increase the tmp disk space or set the system property
"-Djava.io.tmpdir=<dir>" to point to a different partition.

It is still strange that there was something to repair after you
restored from a backup since that should not contain any errors. Did
you try the repair command right after you ran the db restore command?
Is there anything in the log about the restore command?

Best,
Evren

[TJ Tang]

Even,

I ran the repair command just to see how long it would take. Since i could not replicate my index issue.  I don't think there was anything necessarily wrong with the db.  I'll try and see if I am running out of disk space.

-tj

--
-- --
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

To unsubscribe from this group and stop receiving emails from it, send an email to stardog+u...@clarkparsia.com.

[Tze-John Tang]

For the record, I was unable to repair the index on the instance that was having the issues.  I ended up dropping the db and restoring from the latest backup, and it is ok so far.  The error I was getting when repairing was:

[stardog@aws00001p ~]$ stardog-admin db repair kg

Database kg is invalid and the repair failed: Inconsistent index size for OSP; expected=22293658, got= 22293256

[WARNING com.complexible.stardog.StardogKernel.readOrCreate - Jun 16, 2015 03:56:29.655] Database kg is invalid and the repair failed: Inconsistent index size for OSP; expected=22293658, got= 22293256

[SEVERE com.complexible.stardog.StardogKernel.initDatabases - Jun 16, 2015 03:56:29.655] Database kg will not be available because there was an error initializing the database: Inconsistent index size for OSP; expected=22293658, got= 22293256

-tj

On Monday, June 15, 2015 at 9:03:51 PM UTC-5, Tze-John Tang wrote:

Even,

I ran the repair command just to see how long it would take. Since i could not replicate my index issue.  I don't think there was anything necessarily wrong with the db.  I'll try and see if I am running out of disk space.

-tj

On Mon, Jun 15, 2015, 15:35 Evren Sirin <ev...@complexible.com> wrote:

Stardog uses the tmp directory while repairing a database and I think
the most probable explanation for this repair error is that the system
ran out of tmp disk space. The other possibility is some other
hardware issue that prevents Stardog from writing to tmp. You can
either increase the tmp disk space or set the system property
"-Djava.io.tmpdir=<dir>" to point to a different partition.

It is still strange that there was something to repair after you
restored from a backup since that should not contain any errors. Did
you try the repair command right after you ran the db restore command?
Is there anything in the log about the restore command?

Best,
Evren

--
-- --
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+unsubscribe@clarkparsia.com

For more options, visit this group at
http://groups.google.com/a/clarkparsia.com/group/stardog?hl=en

To unsubscribe from this group and stop receiving emails from it, send an email to stardog+unsubscribe@clarkparsia.com.