Interesting ... yeah, it's totally possible that those combinations of features may not play nicely with eachother, because the DocExpirationUpdateProcessor initiates it's own solr requests under the covers - it has no "original request" to copy authentication credentials from.
Can you please file a jira about this? The obvious workaround is to use your own externally scheduled cronjob to just send a deleteByQuery (with the neccessary credentials) using a date range on the timestamp field (that's all DocExpirationUpdateProcessor does under the covers) I suspect that we need to add a standard way for plugins that want to "initiate" cluster requests to ask Solr to pre-populate it with required info (like credentials) and then DocExpirationUpdateProcessor could use that ... (i wonder if something like that was already added when authentication was introduced but folks forgot to updated DocExpirationUpdateProcessor to use it? ... i wonder how things like autoCommit and overseer initiated core admin commands get correct auth credentials today?) : Date: Thu, 12 May 2016 08:06:49 -0500 : From: Brian J. Vanecek <bjvan...@up.com> : Reply-To: solr-user@lucene.apache.org : To: solr-user@lucene.apache.org : Subject: Doc expiration & security plug-ins : : All, : : I'm facing some difficulties utilizing both document expiration and the : security plug-ins in Solr 5.5.0. Looking at the log file for the shard1 : leader, I can see it initiate the delete process. Unfortunately, it : rapidly emits errors for all of the other nodes, as those requests get : rejected for lack of credentials (note that I've replaced collection name, : hostnames, ports): : : 2016-05-10 13:26:25.269 INFO (autoExpireDocs-19-thread-1) : [c:collection s:shard1 r:core_node3 x:collection_shard1_replica1] : o.a.s.u.p.DocExpirationUpdateProcessorFactory Begining periodic deletion : of expired docs : 2016-05-10 13:26:25.270 WARN : (updateExecutor-2-thread-25124-processing-http:////HOSTNAME:PORT//solr//collection_shard3_replica1 : s:shard1 x:collection_shard1_replica1 c:collection n:HOSTNAME:PORT_solr : r:core_node3) [c:collection s:shard1 r:core_node3 : x:collection_shard1_replica1] o.a.s.c.s.i.ConcurrentUpdateSolrClient : Failed to parse error response from : http://HOSTNAME:PORT/solr/collection_shard3_replica1 due to: : java.lang.RuntimeException: Invalid version (expected 2, but 60) or the : data in not in 'javabin' format : org.apache.solr.common.SolrException: Unauthorized request, : Response code: 401 : ... : : However, this doesn't seem to be an issue with how the security is : configured, as everything else is working fine. In fact, I can manually : issue the delete command, and it completes as expected. I set the PKI : plug-in to debug logging and confirmed that no authentication log appeared : in a server receiving the request (from the automatic expiration). It : looks like Solr is not adding the PKI header to the request, so the other : nodes cannot identify it as an inter-node request. : : I've spent some time digging through JIRA and the mail list, but I haven't : seen any other complaints/issues regarding this problem. Has anyone else : gotten both of these working? Could I have configured the security in a : way that breaks only this case? : : - Brian Vanecek : : ** : : This email and any attachments may contain information that is confidential and/or privileged for the sole use of the intended recipient. Any use, review, disclosure, copying, distribution or reliance by others, and any forwarding of this email or its contents, without the express permission of the sender is strictly prohibited by law. If you are not the intended recipient, please contact the sender immediately, delete the e-mail and destroy all copies. : ** : -Hoss http://www.lucidworks.com/
