[
https://issues.apache.org/jira/browse/SOLR-9646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15576407#comment-15576407
]
Shawn Heisey commented on SOLR-9646:
------------------------------------
Please use the mailing list for discussion of problems before coming to Jira,
or join the #solr IRC channel on freenode. We intend this tracker for bugs,
enhancement requests, and development tasks that have been confirmed and
discussed, so they are well-focused and well-documented. Jira is not the first
step for support requests.
On the mailing list or IRC channel, we could have at least informed you that
this requires at least two, and possibly three separate issues:
* Enhancing the log message about deprecated version emulation so that it
correctly mentions luceneMatchVersion.
* Figuring out why updating the version emulation to 6.2 caused an error
message related to the 5.3 codec.
** This looks like it might be a bug. You're running a development version,
where bugs are relatively common. If this *IS* a bug, it would typically be
detected and fixed before release.
** My initial guess is that you have at least one index segment that was
written by the 5.3 version, and the newer version is having some trouble
dealing with that fact. It should be able to handle a 5.x index segment.
** luceneMatchVersion is not intended to influence the on-disk index format.
That should always be dependent on the actual version of the software.
** If you have multiple versions of Lucene/Solr jars on your classpath, it
MIGHT explain this problem.
* Figuring out why you got "Exception writing document id XXX".
Before creating additional issues or going any further on this one, please use
the mailing list or IRC channel. The mailing list has a VERY large audience.
When an error occurs, we need the *full* error from the log, all sections of
the stacktrace that go with it, and the version of Solr. With development
versions, the version info needs to be EXTREMELY precise -- including the
branch name, the git hash, and a complete description of any manual code
changes that are in place. Without that information, errors are very difficult
to track down.
> Error reporting & upgrade Doc could be much more helpful
> --------------------------------------------------------
>
> Key: SOLR-9646
> URL: https://issues.apache.org/jira/browse/SOLR-9646
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server, SolrJ
> Affects Versions: 6.3
> Environment: CentOS 7 VM (VirtualBox VM hosted on Windows).
> ColdFusion application talking to Solr via a mix of SolrJ and direct HTTP:
> calls. Using 6.3 snapshot linked to from SOLR-9325
> Reporter: Tim Parker
>
> Our Solr interface was originally built with Solr 4.10, and included some
> additional schema fields and some minor configuration updates (default of 10
> rows returned is too small for us, and we're doing all communication with
> JSON). This configuration works well with all versions through 6.2.1 (after
> updating our custom ClassLoader to work around SOLR-9231). However... when
> trying to run with a 6.3.0 snapshot... we get errors which are far from easy
> to decipher.
> 1) tons of warnings about deprecated 5.2 emulation - after some digging,
> traced these to our failing to update luceneMatchVersion in solrconfig.xml
> >> The warning should, at a minimum, point to the luceneMatchVersion setting
> >> - current log entry is:
> 2016-10-14 17:13:36.131 WARN (coreLoadExecutor-6-thread-1) [ ]
> o.a.s.s.FieldTypePluginLoader TokenizerFactory is using deprecated 5.2.0
> emulation. You should at some point declare and reindex to at least 6.0,
> because 5.x emulation is deprecated and will be removed in 7.0
> 2) [seen before updating luceneMatchVersion]
> 2016-10-14 17:31:15.978 ERROR (qtp2080166188-15) [ x:issues-1]
> o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: Exception
> writing document id {some document name} to the index; possible analysis
> error.
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:178)
> at
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:67)
> .....
> ===== I assume that this is something triggered by a change in 6.3, but it
> would be nice to have more of a clue about what it's complaining about
> 3) [after updating luceneMatchVersion to 6.2.0]
> 2016-10-14 18:20:02.847 ERROR (qtp2080166188-16) [ x:issues-1]
> o.a.s.h.RequestHandlerBase java.lang.UnsupportedOperationException: This
> format can only be used for reading
> at
> org.apache.lucene.codecs.lucene53.Lucene53NormsFormat.normsConsumer(Lucene53NormsFormat.java:77)
> at
> org.apache.lucene.index.DefaultIndexingChain.writeNorms(DefaultIndexingChain.java:266)
> at
> org.apache.lucene.index.DefaultIndexingChain.flush(DefaultIndexingChain.java:95)
> at
> org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:443)
> .....
> ==== what format is this referring to? why is lucene53 in play? is there
> another setting I need to update? If this is a configuration problem on my
> end, it would be more than nice to have some pointers here
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
