New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v3.2.0 Fails to index large string property values #9331

Closed
amadfida opened this Issue May 12, 2017 · 15 comments

Comments

Projects
None yet
7 participants
@amadfida

amadfida commented May 12, 2017

Indexing property value length greater than 32766 are failing to get indexed. In addition it causing transactions to fail and there is no way to recover, as they seems to get retried on restart and fails over and over again.

Prior versions didn't enforce any limits or restrictions and this is causing migration problems.

Neo4j Version: 3.2.0
Operating System: Debian 8 "Jessie"
Driver: Neo4j 1.3.0 Java Bolt Driver

Steps to reproduce

Index node property that is greater than 32766 bytes. This worked in 3.1.3

Expected behavior

This essentially limits the node property length as if we can't index, we can't set the property value due to tx errors. Its expected that either entire value is indexed or truncated to fit the limit, without error.

Actual behavior

Following unrecoverable exceptions are thrown, and even restart seems to repeat the failed transactions.

Following is the exception when creating new node and setting property,

2017-05-11 23:44:05.738+0000 ERROR [o.n.k.i.DatabaseHealth] Database panic: Database has encountered some problem, please perform necessary action (tx recovery/restart) Failed to flush index updates
java.io.IOException: Failed to flush index updates
	at org.neo4j.kernel.impl.transaction.command.IndexBatchTransactionApplier.applyPendingLabelAndIndexUpdates(IndexBatchTransactionApplier.java:112)
	at org.neo4j.kernel.impl.transaction.command.IndexBatchTransactionApplier.close(IndexBatchTransactionApplier.java:121)
	at org.neo4j.kernel.impl.api.BatchTransactionApplierFacade.close(BatchTransactionApplierFacade.java:70)
	at org.neo4j.kernel.impl.storageengine.impl.recordstorage.RecordStorageEngine.apply(RecordStorageEngine.java:352)
	at org.neo4j.kernel.impl.api.TransactionRepresentationCommitProcess.applyToStore(TransactionRepresentationCommitProcess.java:78)
	at org.neo4j.kernel.impl.api.TransactionRepresentationCommitProcess.commit(TransactionRepresentationCommitProcess.java:51)
	at org.neo4j.kernel.impl.api.KernelTransactionImplementation.commit(KernelTransactionImplementation.java:588)
	at org.neo4j.kernel.impl.api.KernelTransactionImplementation.closeTransaction(KernelTransactionImplementation.java:459)
	at org.neo4j.kernel.api.KernelTransaction.close(KernelTransaction.java:138)
	at org.neo4j.bolt.v1.runtime.TransactionStateMachine$State.closeTransaction(TransactionStateMachine.java:352)
	at org.neo4j.bolt.v1.runtime.TransactionStateMachine$State$2.run(TransactionStateMachine.java:245)
	at org.neo4j.bolt.v1.runtime.TransactionStateMachine.run(TransactionStateMachine.java:74)
	at org.neo4j.bolt.v1.runtime.BoltStateMachine$State$2.run(BoltStateMachine.java:394)
	at org.neo4j.bolt.v1.runtime.BoltStateMachine.run(BoltStateMachine.java:193)
	at org.neo4j.bolt.v1.messaging.BoltMessageRouter.lambda$onRun$3(BoltMessageRouter.java:80)
	at org.neo4j.bolt.v1.runtime.concurrent.RunnableBoltWorker.execute(RunnableBoltWorker.java:130)
	at org.neo4j.bolt.v1.runtime.concurrent.RunnableBoltWorker.executeBatch(RunnableBoltWorker.java:123)
	at org.neo4j.bolt.v1.runtime.concurrent.RunnableBoltWorker.run(RunnableBoltWorker.java:96)
	at java.lang.Thread.run(Thread.java:745)
Caused by: java.util.concurrent.ExecutionException: java.lang.IllegalArgumentException: Document contains at least one immense term in field="string" (whose UTF8 encoding is longer than the max length 32766), all of which were skipped.  Please correct the analyzer to not produce such terms.  The prefix of the first immense term is: '[85, 112, 103, 114, 97, 100, 101, 32, 116, 111, 32, 116, 104, 101, 32, 108, 97, 116, 101, 115, 116, 32, 112, 97, 99, 107, 97, 103, 101, 115]...', original message: bytes can be at most 32766 in length; got 39285
	at org.neo4j.concurrent.WorkSync.checkFailure(WorkSync.java:135)
	at org.neo4j.concurrent.WorkSync.apply(WorkSync.java:91)
	at org.neo4j.kernel.impl.transaction.command.IndexBatchTransactionApplier.applyPendingLabelAndIndexUpdates(IndexBatchTransactionApplier.java:108)
	... 18 more
Caused by: java.lang.IllegalArgumentException: Document contains at least one immense term in field="string" (whose UTF8 encoding is longer than the max length 32766), all of which were skipped.  Please correct the analyzer to not produce such terms.  The prefix of the first immense term is: '[85, 112, 103, 114, 97, 100, 101, 32, 116, 111, 32, 116, 104, 101, 32, 108, 97, 116, 101, 115, 116, 32, 112, 97, 99, 107, 97, 103, 101, 115]...', original message: bytes can be at most 32766 in length; got 39285
	at org.apache.lucene.index.DefaultIndexingChain$PerField.invert(DefaultIndexingChain.java:692)
	at org.apache.lucene.index.DefaultIndexingChain.processField(DefaultIndexingChain.java:365)
	at org.apache.lucene.index.DefaultIndexingChain.processDocument(DefaultIndexingChain.java:321)
	at org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:234)
	at org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:450)
	at org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1477)
	at org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1256)
	at org.neo4j.kernel.api.impl.schema.writer.PartitionedIndexWriter.addDocument(PartitionedIndexWriter.java:58)
	at org.neo4j.kernel.api.impl.schema.LuceneIndexAccessor$LuceneIndexUpdater.add(LuceneIndexAccessor.java:194)
	at org.neo4j.kernel.api.impl.schema.LuceneIndexAccessor$LuceneIndexUpdater.process(LuceneIndexAccessor.java:155)
	at org.neo4j.kernel.impl.api.index.updater.UpdateCountingIndexUpdater.process(UpdateCountingIndexUpdater.java:47)
	at org.neo4j.kernel.impl.api.index.updater.DelegatingIndexUpdater.process(DelegatingIndexUpdater.java:41)
	at org.neo4j.kernel.impl.api.index.IndexingService.apply(IndexingService.java:448)
	at org.neo4j.kernel.impl.api.index.IndexingService.apply(IndexingService.java:429)
	at org.neo4j.kernel.impl.transaction.command.IndexUpdatesWork.apply(IndexUpdatesWork.java:64)
	at org.neo4j.kernel.impl.transaction.command.IndexUpdatesWork.apply(IndexUpdatesWork.java:43)
	at org.neo4j.concurrent.WorkSync.doSynchronizedWork(WorkSync.java:184)
	at org.neo4j.concurrent.WorkSync.tryDoWork(WorkSync.java:110)
	... 20 more
Caused by: org.apache.lucene.util.BytesRefHash$MaxBytesLengthExceededException: bytes can be at most 32766 in length; got 39285
	at org.apache.lucene.util.BytesRefHash.add(BytesRefHash.java:284)
	at org.apache.lucene.index.TermsHashPerField.add(TermsHashPerField.java:150)
	at org.apache.lucene.index.DefaultIndexingChain$PerField.invert(DefaultIndexingChain.java:682)
	... 37 more
2017-05-11 23:44:05.806+0000 ERROR [o.n.b.v.r.ErrorReporter] Client triggered an unexpected error [TransactionCommitFailed]: Could not apply the transaction to the store after written to log, reference 505fc722-8d9c-40ab-9cd2-10835ddcc087.
2017-05-11 23:44:05.806+0000 ERROR [o.n.b.v.r.ErrorReporter] Client triggered an unexpected error [TransactionCommitFailed]: Could not apply the transaction to the store after written to log, reference 505fc722-8d9c-40ab-9cd2-10835ddcc087. Could not apply the transaction to the store after written to log
org.neo4j.kernel.api.exceptions.TransactionFailureException: Could not apply the transaction to the store after written to log
	at org.neo4j.kernel.impl.api.TransactionRepresentationCommitProcess.applyToStore(TransactionRepresentationCommitProcess.java:82)
	at org.neo4j.kernel.impl.api.TransactionRepresentationCommitProcess.commit(TransactionRepresentationCommitProcess.java:51)
	at org.neo4j.kernel.impl.api.KernelTransactionImplementation.commit(KernelTransactionImplementation.java:588)
	at org.neo4j.kernel.impl.api.KernelTransactionImplementation.closeTransaction(KernelTransactionImplementation.java:459)
	at org.neo4j.kernel.api.KernelTransaction.close(KernelTransaction.java:138)
	at org.neo4j.bolt.v1.runtime.TransactionStateMachine$State.closeTransaction(TransactionStateMachine.java:352)
	at org.neo4j.bolt.v1.runtime.TransactionStateMachine$State$2.run(TransactionStateMachine.java:245)
	at org.neo4j.bolt.v1.runtime.TransactionStateMachine.run(TransactionStateMachine.java:74)
	at org.neo4j.bolt.v1.runtime.BoltStateMachine$State$2.run(BoltStateMachine.java:394)
	at org.neo4j.bolt.v1.runtime.BoltStateMachine.run(BoltStateMachine.java:193)
	at org.neo4j.bolt.v1.messaging.BoltMessageRouter.lambda$onRun$3(BoltMessageRouter.java:80)
	at org.neo4j.bolt.v1.runtime.concurrent.RunnableBoltWorker.execute(RunnableBoltWorker.java:130)
	at org.neo4j.bolt.v1.runtime.concurrent.RunnableBoltWorker.executeBatch(RunnableBoltWorker.java:123)
	at org.neo4j.bolt.v1.runtime.concurrent.RunnableBoltWorker.run(RunnableBoltWorker.java:96)
	at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: Failed to flush index updates
	at org.neo4j.kernel.impl.transaction.command.IndexBatchTransactionApplier.applyPendingLabelAndIndexUpdates(IndexBatchTransactionApplier.java:112)
	at org.neo4j.kernel.impl.transaction.command.IndexBatchTransactionApplier.close(IndexBatchTransactionApplier.java:121)
	at org.neo4j.kernel.impl.api.BatchTransactionApplierFacade.close(BatchTransactionApplierFacade.java:70)
	at org.neo4j.kernel.impl.storageengine.impl.recordstorage.RecordStorageEngine.apply(RecordStorageEngine.java:352)
	at org.neo4j.kernel.impl.api.TransactionRepresentationCommitProcess.applyToStore(TransactionRepresentationCommitProcess.java:78)
	... 14 more

On restart following errors are thrown

2017-05-12 06:20:34.928+0000 INFO [o.n.k.i.a.i.FailedIndexProxy] FailedIndexProxy#drop index on :Issue(solution) [provider: {key=lucene, version=1.0}] dropped due to:
java.lang.IllegalArgumentException: Property value bytes length: 146781 is longer then 32766, which is maximum supported length of indexed property value.
	at org.neo4j.kernel.impl.api.IndexValueLengthValidator.validate(IndexValueLengthValidator.java:44)
	at org.neo4j.kernel.impl.api.IndexSimpleValueValidator.validate(IndexSimpleValueValidator.java:42)
	at org.neo4j.kernel.impl.api.IndexValueValidator.validate(IndexValueValidator.java:36)
	at org.neo4j.kernel.impl.transaction.state.storeview.StoreViewNodeStoreScan.process(StoreViewNodeStoreScan.java:108)
	at org.neo4j.kernel.impl.transaction.state.storeview.NodeStoreScan.run(NodeStoreScan.java:74)
	at org.neo4j.kernel.impl.api.index.BatchingMultipleIndexPopulator$BatchingStoreScan.run(BatchingMultipleIndexPopulator.java:378)
	at org.neo4j.kernel.impl.api.index.IndexPopulationJob.indexAllNodes(IndexPopulationJob.java:137)
	at org.neo4j.kernel.impl.api.index.IndexPopulationJob.run(IndexPopulationJob.java:109)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
	at org.neo4j.helpers.NamedThreadFactory$2.run(NamedThreadFactory.java:109)	

@amadfida amadfida changed the title from v.3.2.0 Fails to index large string property values to v3.2.0 Fails to index large string property values May 12, 2017

@MishaDemianenko

This comment has been minimized.

Show comment
Hide comment
@MishaDemianenko

MishaDemianenko May 12, 2017

Contributor

@amadfida thx for reporting. Indexing of properties longer than 32k was impossible in any prior version as well - any value that was longer than 32k was silently ignored. Now we should properly validate value length before insertion even before any transaction log will be written. And looking into the first provided stacktrace it's already failing on index update phase which should be after that.
We will investigate and come back with a fix for that sneaky way as soon as possible.
While storing values that are longer than 32k will be as impossible as it was before.

Contributor

MishaDemianenko commented May 12, 2017

@amadfida thx for reporting. Indexing of properties longer than 32k was impossible in any prior version as well - any value that was longer than 32k was silently ignored. Now we should properly validate value length before insertion even before any transaction log will be written. And looking into the first provided stacktrace it's already failing on index update phase which should be after that.
We will investigate and come back with a fix for that sneaky way as soon as possible.
While storing values that are longer than 32k will be as impossible as it was before.

@amadfida

This comment has been minimized.

Show comment
Hide comment
@amadfida

amadfida May 12, 2017

@MishaDemianenko Thanks for your response. Just to understand, are you saying that there is and always has been a hard limit on storing nodes values longer than 32K or that indexing values longer than 32K is a problem. As i am looking at my 3.1.x database and i have a string node property that is (at least I think they are) bigger than 32K.

neo4j> match (n:Issue) return size(n.solution) as chars ORDER BY chars desc LIMIT 1;
chars
67697

@MishaDemianenko Thanks for your response. Just to understand, are you saying that there is and always has been a hard limit on storing nodes values longer than 32K or that indexing values longer than 32K is a problem. As i am looking at my 3.1.x database and i have a string node property that is (at least I think they are) bigger than 32K.

neo4j> match (n:Issue) return size(n.solution) as chars ORDER BY chars desc LIMIT 1;
chars
67697
@MishaDemianenko

This comment has been minimized.

Show comment
Hide comment
@MishaDemianenko

MishaDemianenko May 12, 2017

Contributor

@amadfida lucene indexes does not support terms that are longer than value around 32K, you can see it at https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/index/IndexWriter.java#L264
Till migration to more recent lucene version, those terms were just silently ignored during index updates.
And 3.2 is the first version where we can change behaviour and throw validation exception for cases where supplied property value is too long.

Contributor

MishaDemianenko commented May 12, 2017

@amadfida lucene indexes does not support terms that are longer than value around 32K, you can see it at https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/index/IndexWriter.java#L264
Till migration to more recent lucene version, those terms were just silently ignored during index updates.
And 3.2 is the first version where we can change behaviour and throw validation exception for cases where supplied property value is too long.

@amadfida

This comment has been minimized.

Show comment
Hide comment
@amadfida

amadfida May 12, 2017

Got it, Would it be possible to log a WARN or ERROR and ignore the longer values (or perhaps truncate) vs. not allowing as right now i will have to remove index on existing dbs to get them work.

Elasticsearch seems to have a option to protect against this hard-coded limit, that essentially ignores above certain size.. (in their case the don't store either but they are only index store)

https://www.elastic.co/guide/en/elasticsearch/reference/current/ignore-above.html

Seems like a reasonable solution.

Thanks

amadfida commented May 12, 2017

Got it, Would it be possible to log a WARN or ERROR and ignore the longer values (or perhaps truncate) vs. not allowing as right now i will have to remove index on existing dbs to get them work.

Elasticsearch seems to have a option to protect against this hard-coded limit, that essentially ignores above certain size.. (in their case the don't store either but they are only index store)

https://www.elastic.co/guide/en/elasticsearch/reference/current/ignore-above.html

Seems like a reasonable solution.

Thanks

@MishaDemianenko

This comment has been minimized.

Show comment
Hide comment
@MishaDemianenko

MishaDemianenko May 12, 2017

Contributor

Silent trimming(even with WARN or ERROR log message) will not really work since your index becoming inconsistent - values in the index and DB are different, and we can't rely on the user to check their log messages to explain index inconsistencies and surprising query resuts.

Trimming value in the index - is something that user can do on its side by trimming property that is desirable to be indexed.

Mutch suitable solution for that problem would be a function based index where some function(trim for example) can be applied to the value before indexing it; unfortunately, we do not have those yet.

So if trimmed values are acceptable by your case i would suggest just updat them to accabtable length and keep the index, hope this helps

Contributor

MishaDemianenko commented May 12, 2017

Silent trimming(even with WARN or ERROR log message) will not really work since your index becoming inconsistent - values in the index and DB are different, and we can't rely on the user to check their log messages to explain index inconsistencies and surprising query resuts.

Trimming value in the index - is something that user can do on its side by trimming property that is desirable to be indexed.

Mutch suitable solution for that problem would be a function based index where some function(trim for example) can be applied to the value before indexing it; unfortunately, we do not have those yet.

So if trimmed values are acceptable by your case i would suggest just updat them to accabtable length and keep the index, hope this helps

@mburak

This comment has been minimized.

Show comment
Hide comment
@mburak

mburak May 12, 2017

Isn't it possible to use just a Lucene text field (that has no limit) instead of string for long fields? Because it doesn't make much sense to match exactly on long fields. They'd be used for a partial match (CONTAINS) and string fields doesn't work for that (well, they do using wildcards). Perhaps there should be a way to define different kind of indexes...

mburak commented May 12, 2017

Isn't it possible to use just a Lucene text field (that has no limit) instead of string for long fields? Because it doesn't make much sense to match exactly on long fields. They'd be used for a partial match (CONTAINS) and string fields doesn't work for that (well, they do using wildcards). Perhaps there should be a way to define different kind of indexes...

@marclambrichs

This comment has been minimized.

Show comment
Hide comment
@marclambrichs

marclambrichs May 12, 2017

@mburak

This comment has been minimized.

Show comment
Hide comment
@mburak

mburak May 12, 2017

@mlambrichs I think they replaced it for the label index, but not for field indexes.

mburak commented May 12, 2017

@mlambrichs I think they replaced it for the label index, but not for field indexes.

@amadfida

This comment has been minimized.

Show comment
Hide comment
@amadfida

amadfida May 12, 2017

Freaken Lucerne :) .. it's unfortunate as 90% of the values are less than 32K and we can't index them because of 10%.

And due to this limit, it's essentially imposing a limit on neo4j node property as well -- which really sucks !!

Freaken Lucerne :) .. it's unfortunate as 90% of the values are less than 32K and we can't index them because of 10%.

And due to this limit, it's essentially imposing a limit on neo4j node property as well -- which really sucks !!

@MishaDemianenko

This comment has been minimized.

Show comment
Hide comment
@MishaDemianenko

MishaDemianenko May 12, 2017

Contributor

@amadfida properties still allow you to store big properties, those are indexed properties that should be smaller than 32k;
but since you propose originally to trim values to some value, will that work for you then?
or you can create indexable property that will be used for search purposes that will be shorter then max limit and contains suitable substring; or if you need an exact match of such long properties you can index their checksum for example

Contributor

MishaDemianenko commented May 12, 2017

@amadfida properties still allow you to store big properties, those are indexed properties that should be smaller than 32k;
but since you propose originally to trim values to some value, will that work for you then?
or you can create indexable property that will be used for search purposes that will be shorter then max limit and contains suitable substring; or if you need an exact match of such long properties you can index their checksum for example

@amadfida

This comment has been minimized.

Show comment
Hide comment
@amadfida

amadfida May 12, 2017

Given there is no better way -- I will discuss with my team on trimming indexable values -- we never need exact match for long strings and it's always looking for some substring.

For example a long string would actually be something like a "stacktrace" property on an issue node in our data model where no one will ever search for exact value.

For existing databases we will need to do some manual schema and data migration.

I just wish that the exception thrown was more elegant than what it's right now -- also this should just be another constraint for indexable properties as it seems I can set a value but then indexing fails and causes database level issues vs. a simple tx rollback.

amadfida commented May 12, 2017

Given there is no better way -- I will discuss with my team on trimming indexable values -- we never need exact match for long strings and it's always looking for some substring.

For example a long string would actually be something like a "stacktrace" property on an issue node in our data model where no one will ever search for exact value.

For existing databases we will need to do some manual schema and data migration.

I just wish that the exception thrown was more elegant than what it's right now -- also this should just be another constraint for indexable properties as it seems I can set a value but then indexing fails and causes database level issues vs. a simple tx rollback.

@MishaDemianenko

This comment has been minimized.

Show comment
Hide comment
@MishaDemianenko

MishaDemianenko May 12, 2017

Contributor

@amadfida as I already mentioned before is should never cause issues on recovery or anything else that unrelated to current indexing operation.
You can get value validation exceptions only during index creation: when you want to create a new index over properties but they are bigger then supported by index implementation; or when you try to set a property so some value that over exceed limits. First should cause index creation failure, second transaction rollback, all the rest should be fixed.

Contributor

MishaDemianenko commented May 12, 2017

@amadfida as I already mentioned before is should never cause issues on recovery or anything else that unrelated to current indexing operation.
You can get value validation exceptions only during index creation: when you want to create a new index over properties but they are bigger then supported by index implementation; or when you try to set a property so some value that over exceed limits. First should cause index creation failure, second transaction rollback, all the rest should be fixed.

@jhb

This comment has been minimized.

Show comment
Hide comment
@jhb

jhb May 23, 2017

I was bitten by this bug as well [1]. Members of the neo4j team suggested "solutions" [2] as splitting the text on multiple attributes/nodes, truncating it, etc. This of course all does not fullfill the purpose of doing search in a text.

From the little of what I understand of lucene, it is also not a limitiation of lucene - see solr, elastic etc. which all use lucene, and handle big texts quite well. It only has a 'word limit' of 32k. Which is not the problem at hand. See the reprocuder script at the bottom of [1], which contains only words of the length 3.

Also, as a friend noted: because neo4j completely crashes because of this bug, this also implies that the transaction isolation is not working in neo4j at the moment. The problem of a single byte too much should not be able to cross transaction bounderies, and especially not kill the whole server.

[1] https://baach.de/Members/jhb/neo4j-full-text-indexing
[2] https://stackoverflow.com/questions/42909304

jhb commented May 23, 2017

I was bitten by this bug as well [1]. Members of the neo4j team suggested "solutions" [2] as splitting the text on multiple attributes/nodes, truncating it, etc. This of course all does not fullfill the purpose of doing search in a text.

From the little of what I understand of lucene, it is also not a limitiation of lucene - see solr, elastic etc. which all use lucene, and handle big texts quite well. It only has a 'word limit' of 32k. Which is not the problem at hand. See the reprocuder script at the bottom of [1], which contains only words of the length 3.

Also, as a friend noted: because neo4j completely crashes because of this bug, this also implies that the transaction isolation is not working in neo4j at the moment. The problem of a single byte too much should not be able to cross transaction bounderies, and especially not kill the whole server.

[1] https://baach.de/Members/jhb/neo4j-full-text-indexing
[2] https://stackoverflow.com/questions/42909304

@ragadeeshu

This comment has been minimized.

Show comment
Hide comment
@ragadeeshu

ragadeeshu May 23, 2017

Contributor

This issue has been been resolved by #9381
Invalid property values will now be caught immediately. Saying that this used to work in a prior version is inaccurate, as back then the value was quietly not indexed, and thus an inconsistent state was reached.

Contributor

ragadeeshu commented May 23, 2017

This issue has been been resolved by #9381
Invalid property values will now be caught immediately. Saying that this used to work in a prior version is inaccurate, as back then the value was quietly not indexed, and thus an inconsistent state was reached.

@ragadeeshu ragadeeshu closed this May 23, 2017

@tim-hanssen

This comment has been minimized.

Show comment
Hide comment
@tim-hanssen

tim-hanssen Jun 9, 2017

We are stuck in the same error while migrating our instance to 3.2.1. As far as we know, there are no parameters indexed that are that long. Still we got this error.

It looks like the Tag(hash) index fails, but the longest string in that param is 32 chars. Any ideas on how we can find the node that is breaking our import?

2017-06-09 10:31:55.716+0000 ERROR [o.n.k.i.a.i.IndexPopulationJob] Failed to populate index: [:Tag(Hash) [provider: {key=lucene, version=1.0}]] Property value bytes length: 35389 is longer then 32766, which is maximum supported length of indexed property value.
java.lang.IllegalArgumentException: Property value bytes length: 35389 is longer then 32766, which is maximum supported length of indexed property value.
at org.neo4j.kernel.impl.api.IndexValueLengthValidator.validate(IndexValueLengthValidator.java:44)
at org.neo4j.kernel.impl.api.IndexSimpleValueValidator.validate(IndexSimpleValueValidator.java:42)
at org.neo4j.kernel.impl.api.IndexValueValidator.validate(IndexValueValidator.java:36)
at org.neo4j.kernel.impl.transaction.state.storeview.StoreViewNodeStoreScan.process(StoreViewNodeStoreScan.java:108)
at org.neo4j.kernel.impl.transaction.state.storeview.NodeStoreScan.run(NodeStoreScan.java:74)
at org.neo4j.kernel.impl.api.index.BatchingMultipleIndexPopulator$BatchingStoreScan.run(BatchingMultipleIndexPopulator.java:378)
at org.neo4j.kernel.impl.api.index.IndexPopulationJob.indexAllNodes(IndexPopulationJob.java:137)
at org.neo4j.kernel.impl.api.index.IndexPopulationJob.run(IndexPopulationJob.java:109)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
at org.neo4j.helpers.NamedThreadFactory$2.run(NamedThreadFactory.java:109)

We are stuck in the same error while migrating our instance to 3.2.1. As far as we know, there are no parameters indexed that are that long. Still we got this error.

It looks like the Tag(hash) index fails, but the longest string in that param is 32 chars. Any ideas on how we can find the node that is breaking our import?

2017-06-09 10:31:55.716+0000 ERROR [o.n.k.i.a.i.IndexPopulationJob] Failed to populate index: [:Tag(Hash) [provider: {key=lucene, version=1.0}]] Property value bytes length: 35389 is longer then 32766, which is maximum supported length of indexed property value.
java.lang.IllegalArgumentException: Property value bytes length: 35389 is longer then 32766, which is maximum supported length of indexed property value.
at org.neo4j.kernel.impl.api.IndexValueLengthValidator.validate(IndexValueLengthValidator.java:44)
at org.neo4j.kernel.impl.api.IndexSimpleValueValidator.validate(IndexSimpleValueValidator.java:42)
at org.neo4j.kernel.impl.api.IndexValueValidator.validate(IndexValueValidator.java:36)
at org.neo4j.kernel.impl.transaction.state.storeview.StoreViewNodeStoreScan.process(StoreViewNodeStoreScan.java:108)
at org.neo4j.kernel.impl.transaction.state.storeview.NodeStoreScan.run(NodeStoreScan.java:74)
at org.neo4j.kernel.impl.api.index.BatchingMultipleIndexPopulator$BatchingStoreScan.run(BatchingMultipleIndexPopulator.java:378)
at org.neo4j.kernel.impl.api.index.IndexPopulationJob.indexAllNodes(IndexPopulationJob.java:137)
at org.neo4j.kernel.impl.api.index.IndexPopulationJob.run(IndexPopulationJob.java:109)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
at org.neo4j.helpers.NamedThreadFactory$2.run(NamedThreadFactory.java:109)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment