On 9/25/2016 4:24 AM, xavi jmlucjav wrote:
> Everything went well, no errors when solr restarted, the collections shows
> the right number of docs. But when I try to run a query, I get:
>
> null:java.lang.NullPointerException

Did you change any of the fieldType class values as you adjusted the
schema for the upgrade?  A number of classes that were valid and
deprecated in 3.6 and 4.x were completely removed by 5.x, and 6.x
probably removed a few more.

If you did make changes like this to your schema, then what's in the
index will no longer match the schema, and the *only* option is a
reindex.  Exceptions are likely if you don't reindex after schema
changes to the class value(s) or the index analyzer(s).

Regarding the _version_ field:  SolrCloud expects this field to be in
your schema.  It might also expect that that every document in the index
will already contain a value in this field.  Adding _version_ to your
schema should be treated similarly to the changes mentioned above -- a
reindex is required for proper operation.

Even if the schema didn't change in a way that *requires* a reindex ...
the number of changes to the analysis components across three major
version jumps is quite large.  Solr might not work as expected because
of those changes unless you reindex, even if you don't see any
exceptions.  Changes to your schema because of changes in analysis
component behavior might  be required -- which is another situation that
usually requires a reindex.

Because of these potential problems, I always start a new Solr version
with no index data and completely rebuild my indexes after an upgrade. 
That is the best way to ensure success.

You referenced a mailing list thread where somebody had success
converting non-cloud to cloud... but that was on version 4.8.1, two
major versions back from the version you're running.  They also did not
upgrade major versions -- from some things they said at the beginning of
the thread, I know that the source version was at least 4.4.  The thread
didn't mention any schema changes, either.

If the schema doesn't change at all, moving from non-cloud to cloud is
very possible, but if the schema changes, the index data might not match
the schema any more, and that situation will not work.

Since you jumped three major versions, it's almost guaranteed that your
schema *did* change, and the changes may have been more extensive than
just adding the _version_ field.

It's possible that there's a problem when converting a non-cloud install
with no _version_ field to a cloud install where the only schema change
is adding the _version_ field.  We can treat THAT situation as a bug,
but if there are other schema changes besides adding _version_, the
exception you encountered is most likely not a bug.

Thanks,
Shawn

Reply via email to