[jira] [Commented] (SOLR-13003) Query Result Cache does not honour maxRamBytes parameter
[
https://issues.apache.org/jira/browse/SOLR-13003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16695315#comment-16695315
]
Cetra Free commented on SOLR-13003:
---
With regards to {{FastLRUCache}}: the actual accounting implementation is in
{{ConcurrentLRUCache}} which appears to be doing the right thing. But the
issue is the size comparison, so I don't think swapping would help. I will give
it a shot regardless.
I've noticed the QueryResultKey is greater than 75kb of memory per key, which
is much greater size than the value.
I will try out the patched version from Shawn & see if I can trigger it and get
some stats out.
> Query Result Cache does not honour maxRamBytes parameter
>
>
> Key: SOLR-13003
> URL: https://issues.apache.org/jira/browse/SOLR-13003
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.3.1
>Reporter: Cetra Free
>Priority: Major
> Attachments: CLRU-logging.patch, lrucacheexpanded.png,
> lrucachemaxmb.png, solr-core-7.3.1-SNAPSHOT.jar, solrconfig.xml
>
>
> When using the maxRamBytes parameter with the queryResultCache directive, we
> have seen the retained size of the cache orders of magnitude larger than what
> is configured.
> Please see attached VisualVM output which shows the retained size is about
> 1.5gb, but the maxRamBytes is set to 64mb.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13003) Query Result Cache does not honour maxRamBytes parameter
[
https://issues.apache.org/jira/browse/SOLR-13003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694134#comment-16694134
]
Cetra Free commented on SOLR-13003:
---
I've added in this expanded cache line as as screenshot.
My suspicion is that the RAM amount used is not calculated correctly which is
what is causing this issue.
I couldn't find any way to validate that the returned
{{Accountable.ramBytesUsed()}} size is accurate for the cache type
({{SolrCache}}).
The config for caches is as follows (I've attached the full config to this
ticket):
{code:xml}
{code}
> Query Result Cache does not honour maxRamBytes parameter
>
>
> Key: SOLR-13003
> URL: https://issues.apache.org/jira/browse/SOLR-13003
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.3.1
>Reporter: Cetra Free
>Priority: Major
> Attachments: lrucacheexpanded.png, lrucachemaxmb.png, solrconfig.xml
>
>
> When using the maxRamBytes parameter with the queryResultCache directive, we
> have seen the retained size of the cache orders of magnitude larger than what
> is configured.
> Please see attached VisualVM output which shows the retained size is about
> 1.5gb, but the maxRamBytes is set to 64mb.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13003) Query Result Cache does not honour maxRamBytes parameter
[ https://issues.apache.org/jira/browse/SOLR-13003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cetra Free updated SOLR-13003: -- Attachment: lrucacheexpanded.png > Query Result Cache does not honour maxRamBytes parameter > > > Key: SOLR-13003 > URL: https://issues.apache.org/jira/browse/SOLR-13003 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.3.1 >Reporter: Cetra Free >Priority: Major > Attachments: lrucacheexpanded.png, lrucachemaxmb.png, solrconfig.xml > > > When using the maxRamBytes parameter with the queryResultCache directive, we > have seen the retained size of the cache orders of magnitude larger than what > is configured. > Please see attached VisualVM output which shows the retained size is about > 1.5gb, but the maxRamBytes is set to 64mb. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13003) Query Result Cache does not honour maxRamBytes parameter
[ https://issues.apache.org/jira/browse/SOLR-13003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cetra Free updated SOLR-13003: -- Attachment: solrconfig.xml > Query Result Cache does not honour maxRamBytes parameter > > > Key: SOLR-13003 > URL: https://issues.apache.org/jira/browse/SOLR-13003 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.3.1 >Reporter: Cetra Free >Priority: Major > Attachments: lrucachemaxmb.png, solrconfig.xml > > > When using the maxRamBytes parameter with the queryResultCache directive, we > have seen the retained size of the cache orders of magnitude larger than what > is configured. > Please see attached VisualVM output which shows the retained size is about > 1.5gb, but the maxRamBytes is set to 64mb. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13003) Query Result Cache does not honour maxRamBytes parameter
[
https://issues.apache.org/jira/browse/SOLR-13003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16693955#comment-16693955
]
Cetra Free edited comment on SOLR-13003 at 11/21/18 12:42 AM:
--
Sorry if it was not clear.
The maxRamBytes is set to {{67108864}} bytes (64mb).
The Retained size of the ConcurrentLRUCache is {{1589995450}} bytes (1.5gb)
In other words, the actual RAM size is about 23x the size of the configured
limit.
was (Author: cetra3):
Sorry if it was not clear.
The maxRamBytes is set to {{67108864}} bytes (64mb).
The Retained size of the ConcurrentLRUCache is {{1589995450}} bytes (1.5gb)
In other words, the RAM size is about 21x the size of the configured limit.
> Query Result Cache does not honour maxRamBytes parameter
>
>
> Key: SOLR-13003
> URL: https://issues.apache.org/jira/browse/SOLR-13003
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.3.1
>Reporter: Cetra Free
>Priority: Major
> Attachments: lrucachemaxmb.png
>
>
> When using the maxRamBytes parameter with the queryResultCache directive, we
> have seen the retained size of the cache orders of magnitude larger than what
> is configured.
> Please see attached VisualVM output which shows the retained size is about
> 1.5gb, but the maxRamBytes is set to 64mb.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13003) Query Result Cache does not honour maxRamBytes parameter
[
https://issues.apache.org/jira/browse/SOLR-13003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16693955#comment-16693955
]
Cetra Free commented on SOLR-13003:
---
Sorry if it was not clear.
The maxRamBytes is set to {{67108864}} bytes (64mb).
The Retained size of the ConcurrentLRUCache is {{1589995450}} bytes (1.5gb)
In other words, the RAM size is about 21x the size of the configured limit.
> Query Result Cache does not honour maxRamBytes parameter
>
>
> Key: SOLR-13003
> URL: https://issues.apache.org/jira/browse/SOLR-13003
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.3.1
>Reporter: Cetra Free
>Priority: Major
> Attachments: lrucachemaxmb.png
>
>
> When using the maxRamBytes parameter with the queryResultCache directive, we
> have seen the retained size of the cache orders of magnitude larger than what
> is configured.
> Please see attached VisualVM output which shows the retained size is about
> 1.5gb, but the maxRamBytes is set to 64mb.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13003) Query Result Cache does not honour maxRamBytes parameter
Cetra Free created SOLR-13003: - Summary: Query Result Cache does not honour maxRamBytes parameter Key: SOLR-13003 URL: https://issues.apache.org/jira/browse/SOLR-13003 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 7.3.1 Reporter: Cetra Free Attachments: lrucachemaxmb.png When using the maxRamBytes parameter with the queryResultCache directive, we have seen the retained size of the cache orders of magnitude larger than what is configured. Please see attached VisualVM output which shows the retained size is about 1.5gb, but the maxRamBytes is set to 64mb. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8409) Cannot delete individual fields from index
Cetra Free created LUCENE-8409: -- Summary: Cannot delete individual fields from index Key: LUCENE-8409 URL: https://issues.apache.org/jira/browse/LUCENE-8409 Project: Lucene - Core Issue Type: Bug Reporter: Cetra Free This is based upon the following tickets: https://issues.apache.org/jira/browse/SOLR-12185 https://issues.apache.org/jira/browse/LUCENE-8235 I'd like a way to be able to clear and recreate a specific field so I don't have to completely reindex if I change a field type. It's a real pain if you change a specific field from single valued to multivalued, you have to delete the entire index from disk and start from scratch. As being able to modify a field is not an [intended feature|https://issues.apache.org/jira/browse/LUCENE-8235?focusedCommentId=16530918&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16530918], It'd be preferable if a field could be at least deleted and recreated to deal with this scenario. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12185) Can't change Single Valued field to Multi Valued even by deleting/readding
[
https://issues.apache.org/jira/browse/SOLR-12185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16426285#comment-16426285
]
Cetra Free commented on SOLR-12185:
---
I've raised this as a ticket to see if it gets traction:
https://issues.apache.org/jira/browse/LUCENE-8235
It would be nice if you could fully purge a field when you delete it, rather
than facebook it and just mark it as deleted but keep it around :)
> Can't change Single Valued field to Multi Valued even by deleting/readding
> --
>
> Key: SOLR-12185
> URL: https://issues.apache.org/jira/browse/SOLR-12185
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Schema and Analysis
>Affects Versions: 7.1
>Reporter: Cetra Free
>Priority: Major
>
> Changing a single-valued field to multi-valued field with doc values breaks
> things. This doesn't matter if you change the field or do a complete delete
> and re-add of the field. The only way I have found to "fix" this is to
> delete the entire core from disk and re-add it.
> h2. Steps to replicate:
> * Create a field, make it single valued with doc values
> * Index a couple of docs
> * Delete the field
> * Add the field again with the same name, but change it to multiValued
> * Try indexing a couple of docs
> h2. Expected result:
> The documents are indexed correctly and there are no issues
> h2. Actual outcome:
> The documents refuse to be indexed and you see this in the logs:
> {code:java}
> org.apache.solr.common.SolrException: Exception writing document id
> 6a3226c8-c904-40d7-aecb-76c3515db7b8 to the index; possible analysis error:
> cannot change DocValues type from SORTED to SORTED_SET for field
> "example_field"
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:221)
> at
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:67)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:991)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1207)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:753)
> at
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
> at
> org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactory$AddSchemaFieldsUpdateProcessor.processAdd(AddSchemaFieldsUpdateProcessorFactory.java:474)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
> at
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
> at
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
> at
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
> at
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
> at
> org.apache.solr.update.processor.FieldNameMutatingUpdateProcessorFactory$1.processAdd(FieldNameMutatingUpdateProcessorFactory.java:74)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
> at
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
> at
> org.apache.solr.update.processor.AbstractDefaultValueUpdateProcessorFactory$DefaultValueUpdateProcessor.processAdd(AbstractDefaultValueUpdateProcessorFactory.java:91)
> at
> org.apache.solr.handler.dataimport.SolrWriter.upload(SolrWriter.java:80)
> at
> o
[jira] [Created] (LUCENE-8235) Can't change Single Valued field to Multi Valued even by deleting/readding
Cetra Free created LUCENE-8235: -- Summary: Can't change Single Valued field to Multi Valued even by deleting/readding Key: LUCENE-8235 URL: https://issues.apache.org/jira/browse/LUCENE-8235 Project: Lucene - Core Issue Type: Bug Reporter: Cetra Free Basically from here: https://issues.apache.org/jira/browse/SOLR-12185 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12185) Can't change Single Valued field to Multi Valued even by deleting/readding
[
https://issues.apache.org/jira/browse/SOLR-12185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16424961#comment-16424961
]
Cetra Free commented on SOLR-12185:
---
Should I raise this with Lucene then?
> Can't change Single Valued field to Multi Valued even by deleting/readding
> --
>
> Key: SOLR-12185
> URL: https://issues.apache.org/jira/browse/SOLR-12185
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Schema and Analysis
>Affects Versions: 7.1
>Reporter: Cetra Free
>Priority: Major
>
> Changing a single-valued field to multi-valued field with doc values breaks
> things. This doesn't matter if you change the field or do a complete delete
> and re-add of the field. The only way I have found to "fix" this is to
> delete the entire core from disk and re-add it.
> h2. Steps to replicate:
> * Create a field, make it single valued with doc values
> * Index a couple of docs
> * Delete the field
> * Add the field again with the same name, but change it to multiValued
> * Try indexing a couple of docs
> h2. Expected result:
> The documents are indexed correctly and there are no issues
> h2. Actual outcome:
> The documents refuse to be indexed and you see this in the logs:
> {code:java}
> org.apache.solr.common.SolrException: Exception writing document id
> 6a3226c8-c904-40d7-aecb-76c3515db7b8 to the index; possible analysis error:
> cannot change DocValues type from SORTED to SORTED_SET for field
> "example_field"
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:221)
> at
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:67)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:991)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1207)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:753)
> at
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
> at
> org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactory$AddSchemaFieldsUpdateProcessor.processAdd(AddSchemaFieldsUpdateProcessorFactory.java:474)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
> at
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
> at
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
> at
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
> at
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
> at
> org.apache.solr.update.processor.FieldNameMutatingUpdateProcessorFactory$1.processAdd(FieldNameMutatingUpdateProcessorFactory.java:74)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
> at
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
> at
> org.apache.solr.update.processor.AbstractDefaultValueUpdateProcessorFactory$DefaultValueUpdateProcessor.processAdd(AbstractDefaultValueUpdateProcessorFactory.java:91)
> at
> org.apache.solr.handler.dataimport.SolrWriter.upload(SolrWriter.java:80)
> at
> org.apache.solr.handler.dataimport.DataImportHandler$1.upload(DataImportHandler.java:257)
> at
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:527)
> at
> org.apache.sol
[jira] [Created] (SOLR-12186) XPathEntityProcessor with useSolrAddSchema does not add nested child documents
Cetra Free created SOLR-12186:
-
Summary: XPathEntityProcessor with useSolrAddSchema does not add
nested child documents
Key: SOLR-12186
URL: https://issues.apache.org/jira/browse/SOLR-12186
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: contrib - DataImportHandler
Affects Versions: 7.1
Reporter: Cetra Free
When using {{useSolrAddSchema=true}} this does not support child nested
documents as per the normal update handler.
I would expect this to either be mentioned in the documentation as a
limitation, or supported.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12185) Can't change Single Valued field to Multi Valued even by deleting/readding
Cetra Free created SOLR-12185:
-
Summary: Can't change Single Valued field to Multi Valued even by
deleting/readding
Key: SOLR-12185
URL: https://issues.apache.org/jira/browse/SOLR-12185
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: Schema and Analysis
Affects Versions: 7.1
Reporter: Cetra Free
Changing a single-valued field to multi-valued field with doc values breaks
things. This doesn't matter if you change the field or do a complete delete
and re-add of the field. The only way I have found to "fix" this is to delete
the entire core from disk and re-add it.
h2. Steps to replicate:
* Create a field, make it single valued with doc values
* Index a couple of docs
* Delete the field
* Add the field again with the same name, but change it to multiValued
* Try indexing a couple of docs
h2. Expected result:
The documents are indexed correctly and there are no issues
h2. Actual outcome:
The documents refuse to be indexed and you see this in the logs:
{code:java}
org.apache.solr.common.SolrException: Exception writing document id
6a3226c8-c904-40d7-aecb-76c3515db7b8 to the index; possible analysis error:
cannot change DocValues type from SORTED to SORTED_SET for field "example_field"
at
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:221)
at
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:67)
at
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
at
org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:991)
at
org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1207)
at
org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:753)
at
org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)
at
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
at
org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactory$AddSchemaFieldsUpdateProcessor.processAdd(AddSchemaFieldsUpdateProcessorFactory.java:474)
at
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
at
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
at
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
at
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
at
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
at
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
at
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
at
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
at
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
at
org.apache.solr.update.processor.FieldNameMutatingUpdateProcessorFactory$1.processAdd(FieldNameMutatingUpdateProcessorFactory.java:74)
at
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
at
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
at
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
at
org.apache.solr.update.processor.AbstractDefaultValueUpdateProcessorFactory$DefaultValueUpdateProcessor.processAdd(AbstractDefaultValueUpdateProcessorFactory.java:91)
at
org.apache.solr.handler.dataimport.SolrWriter.upload(SolrWriter.java:80)
at
org.apache.solr.handler.dataimport.DataImportHandler$1.upload(DataImportHandler.java:257)
at
org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:527)
at
org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:415)
at
org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:330)
at
org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:233)
at
org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:415)
at
org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:474)
at
org.apache.solr.ha
