On 11/16/2016 11:02 AM, Mike Thomsen wrote:
> We're stuck on Solr 4.10.3 (Cloudera bundle). Is there any way to detect
> with SolrJ when a document added to the index violated the schema? All we
> see when we look at the stacktrace for the SolrException that comes back is
> that it contains messages about an IOException when talking to the solr
> nodes. Solr is up and running, and the documents are only invalid because I
> added a Java statement to make a field invalid for testing purposes. When I
> remove that statement, the indexing happens just fine.
>
> Any way to do this? I seem to recall that at least in newer versions of
> Solr it would tell you more about the specific error.
What *exactly* are you trying to get SolrJ/Solr to tell you that it
isn't telling you? Erick's response has information for one possible
scenario you might be describing.
Using the 4.10.3 client, trying to add a document with an unknown field,
I get very specific and relevant messages like the following from both
HttpSolrServer and CloudSolrServer:
org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
ERROR: [doc=123] unknown field 'florj'
at
org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:552)
at
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:210)
at
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:206)
at
org.apache.solr.client.solrj.impl.LBHttpSolrServer.doRequest(LBHttpSolrServer.java:340)
at
org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:301)
at
org.apache.solr.client.solrj.impl.CloudSolrServer.request(CloudSolrServer.java:659)
at
org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:124)
at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:116)
at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:102)
at org.elyograg.Flubber.main(Flubber.java:44)
(this specific stacktrace came from using a 4.10.3 client with SolrCloud
running 4.2.1 -- so my CloudSolrServer object had to be configured to
use xml instead of javabin)
When I adjusted the code to send a collection of docs instead of a
single doc, with one good doc and one bad doc, I got the same message,
with the uniqueKey field value from the bad document.
For newer versions, there is an issue where the load balancing client
(used by the cloud client) wraps *any* problem in an exception that just
says "No live SolrServers available to handle this request" ... but that
doesn't seem to be a problem in SolrJ 4.10.3. The problem was probably
introduced by the big changes for 5.0.
https://issues.apache.org/jira/browse/SOLR-7951
If you are running into SOLR-7951 (or any other bug), it will NOT be
fixed in any 4.x version. Development on 4.x has ceased entirely.
There's a good chance it won't even be fixed in 5.x, but only in a new
6.x version. I have no idea when Cloudera might update the version of
Solr that they include.
Note that even on versions affected by SOLR-7951, you'd still be able to
see the actual problem exception, because it's still there, as the cause
of the outer exception.
It's always possible that Cloudera has embedded a layer on top of Solr
or SolrJ that gets rid of the meaningful messages that Solr normally
returns. We'll need the actual entire stacktrace and error message
you're seeing.
Thanks,
Shawn
