@AlokKumar  You need to make sure each user is authenticating with a unique username in order to know which user made a change If you are using the same user, then all recorded changes will show that single user.  Form a pure security standpoint it is a bad practice to have multiple users share authentication credentials.  Apache NiFi offers numerous methods for User Authentication.   While Lightweight Directory Access Protocol (LDAP) is probably the most commonly used, there are other options to include OpenID Connect, Kerberos, SAML, JSON Web Tokens, and X.509 Client Certificates. If you are currently using the default Single User authentication which the utilizes the Single User authorizer, you will also need to select a different Multi-Tenant Authorization as well to go with the new multi user authentication methods.  The most commonly used is the StandardManagedAuthorizer.  Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@nisaar  I expect that retry set on the Success relationship out of ListSMB is impacting your scheduling.  I suspect that retry is blocking "successful" attempts by until both retry have been made which aligns with the skip twice you are seeing in scheduling.  As I mentioned before, you should not be setting "retry" on any success relationships.   This is an anti-pattern that will delay processing of any successful execution for the duration of the retry (Each retry would occur at the processors scheduled execution times). Note: Scheduling of a NiFi component does not mean immediate execution.   That execution depends on availability of threads to service the execution.   NiFi has a "max timer driven thread count" configuration that establishes the thread pool from which all scheduled component threads come from.  So things like number of running components, number of concurrent tasks set on a given component, CPU insensitive components, etc can impact when a "scheduled" component is given a thread from the thread pool to execute.    I Thread pool does not impact scheduler unless the processor has been scheduled and never executes until within the 1.5 hours since it was initially scheduled (which I doubt in this case).  The more logical cause because of the consistent behavior is the "retry" you have set on Success from ListSMB. Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt   ... View more

Issue is resolved after the vendor whitelisted the IP's Thanks   ... View more