-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Shawn,

On 4/13/18 6:02 PM, Shawn Heisey wrote:
> 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.

Looks like that worked. I could find that nowhere in the documentation.

> If you hadn't given the command a specific URL, it probably would
> have figured out the correct URL on its own.

No, it wouldn't have. It doesn't read any configuration files and
guesses its way through everything. Simply adding HTTPS support
required me to modify the script and manually-specify the URL. That's
why I went through the trouble of explaining so in my initial post.

> 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. :)

;)

I don't mind all surprises. It's the ones that have zero documentation
that are the most surprising.

> 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.

I'm using it as a bulk-loading operation. I have no need in production
to completely bootstrap a document collection unless the existing one
has been trashed for some reason. Why bother writing my own client
that does the equivalent of "SELECT * FROM table" and then loop over
the ResultSet calling SolrJ's add-document method.

The SimplePostTool should be able to handle that for me, and if it
did, I'd have less code to babysit in perpetuity.

> 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.
I'm okay with terse error messages.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlrTtQ4ACgkQHPApP6U8
pFi4iA/+MQ97WTAkA6t06PqJWEjbu948gJSS5gaVo3HZlTtLqmzT3/4HhypKolId
aVWEU4KpdGGyOp9N2nkc31Zg8Wu4eLRa0k3GaOJ146b9CgJmUqgedJi/6sDlAXFL
mM472eAxDhVRpZB2wGpXp8HZyVxbjOd/ggCVX5ln6vj8TaRfkdDlhWWTX4Bci/uQ
Ia3M50whXIMxKVHmNKLziIsSbvJ/Bt1/rPoz9CzSBDch665yFK+21cXz3u8dAMsv
fdseYYvJ53tnZi6i8xDlGxsTQFbbWpYNWefs0tQjQGLF67t33NNdX5oC6ihChVjD
OlAxh+sL0TX10eGq8Q+1nQcvyg87QAiipY2yDM3CnFxFLbfn/9rdn28mFxtsNIRd
YQyNsVJN2NNXEPzjAYZe9khsIouvioQlmeX0XWhmuQOPdLbO0otiEGNRtwyUhDnt
ytXwkZ70htwRrAh9UC6GFXwgLkMgTN2E4KRjnOBJCbHSYmjL6YAFPWeeAQFX9fW1
18BVNlsyi2Qyo+v86Jbl50Ld3+64UQukjvNCJn8v/uQJ1O8NT2qfcV6jAZ9Wj273
QSzg1eVCiycmKSL+12EojS4ksSmmBVEuMa4pmFimR2JNEYZnzjyO/egaGgIx2FmQ
Sar14gER2OCeI2dXkrRI8sIiLmOaJOatkHCf9lMebpcuyvq+un8=
=D+Pm
-----END PGP SIGNATURE-----

Reply via email to