On 4/13/2018 7:49 AM, Christopher Schultz wrote:
> $ SOLR_POST_OPTS="-Djavax.net.ssl.trustStore=/etc/solr/solr-client.p12
> -Djavax.net.ssl.trustStorePassword=whatevs
> -Djavax.net.ssl.trustStoreType=PKCS12" /usr/local/solr/bin/post -c
> new_core https://localhost:8983/solr/new_core
> [time passes while bin/post uploads a very large file]
> SimplePostTool version 5.0.0
> Posting files to [base] url https://localhost:8983/solr/new_core...
> Entering auto mode. File endings considered are
> xml,json,jsonl,csv,pdf,doc,docx,ppt,pptx,xls,xlsx,odt,odp,ods,ott,otp,ots,rtf,htm,html,txt,log
> POSTing file new_core.json (application/json) to [base]/json/docs
> SimplePostTool: WARNING: Solr returned an error #404 (Not Found) for
> url: https://localhost:8983/solr/new_core/json/docs

The URL path (beyond the core name) it's ending up with is /json/docs,
when it should be /update/json/docs.

If you hadn't given the command a specific URL, it probably would have
figured out the correct URL on its own.  The base URL for the post tool
normally includes the /update path, which is different than the base URL
for something like HttpSolrClient (in the SolrJ library).  Changing the
handler path is done differently in SolrJ than it is with the post tool.

I know, we've violated that principle again. :)

The bin/post tool is a *simple* tool.  The java class that it calls is
even named "SimplePostTool".  It is expected that most users will
outgrow its functionality quickly and write their own indexing software
that does whatever custom processing they require.  The tool doesn't get
a lot of improvements because we don't intend it to be used as a
production indexing mechanism.  If it does what you need, there's
nothing wrong with production usage, but you need to be aware that it
doesn't have robust error handling, which is usually pretty important
for production.


Reply via email to