You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by GitBox <gi...@apache.org> on 2019/02/11 17:25:08 UTC

[GitHub] bbende edited a comment on issue #3041: NIFI-5224 Added SolrClientService.

bbende edited a comment on issue #3041: NIFI-5224 Added SolrClientService.
URL: https://github.com/apache/nifi/pull/3041#issuecomment-462413992
 
 
   Here are the remaining items that I think need to be addressed...
   
   1) Currently there is a recursive loop in createSolrClient that produces a StackOverflowException when starting a solr processor
   
   2) Currently SolrJ is brought in twice, once in nifi-solr-processors pom and again in nifi-solr-client-api pom, it needs to be removed from nifi-solr-processors since that will have a NAR dependency on the API
   
   3) Kerberos currently won't work using the client service because the code in the onTrigger of a processor has to be wrapped in a kerberos action:
   
   ```
   final KerberosUser kerberosUser = getKerberosKeytabUser();
           if (kerberosUser == null) {
               doOnTrigger(context, session);
           } else {
               // wrap doOnTrigger in a privileged action
               final PrivilegedAction action = () -> {
                   doOnTrigger(context, session);
                   return null;
               };
   
               // execute the privileged action as the given keytab user
               final KerberosAction kerberosAction = new KerberosAction(kerberosUser, action, context, getLogger());
               kerberosAction.execute();
           }
   ```
   I think we have to add a method to the client service to obtain the KerberosUser and then update SolrProcessor to use that KerberosUser when the service is set, or use the local one when service is not set.
   
   4) Currently the client service has a property for Collection, previously Collection supported expression language from flow file attributes, but it won't be able to do that when Collection is specified in the service.
   
   So we can either remove Collection from the service and have it always be specified in the processor, or allow it in the service but we have to make a copy of the property descriptor and change the EL scope so the docs say only "Variable Registry".
   
   Since I think the long term goal would eventually be to remove all the overlapping properties from the processors, I think would lean towards leaving Collection in the processors which allows us to support collection per flow file.
   
   
   #1 and #2 I resolved with the following changes:
   https://github.com/bbende/nifi/commit/6c8a7eb0d41446f9b312283d7c2a65fbe1bcc9c0
   
   Feel free to incorporate those into your PR.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services