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. Thanks, Shawn
