Thanks @cotopaul state-management.xml  Connect String was missing , Yes  ... View more

hi @Satya1,   The inactive sessions are getting terminated after 25 mins after the extraction is complete. For example, if you extraction takes 25 minutes to load the data from your database and into the flowfile (no matter the file type), you will keep on seeing those inactive sessions for another 25 more minutes, meaning that they will be completely gone after 50 mins, since you started your flow.   If you want, you can reduce the time to a lower value, as 25 is a bit big for most cases. You can modify it into 5 minutes and test it for yourself. I did it and my flow took 2 minutes, the sessions got evicted after 5 and in 7 minutes all the sessions were gone. ... View more

@anoop89  This is an unrelated issue to this original thread. Please start a new question.  Fell free to @ckumar and @MattWho  in your question so we get notified.  This issue is related to authorization of your user. Thanks, Matt ... View more

Assuming that there would be a way to check for flow files which went through failure, how would you extract them? Manual search within the Data Provenance Menu from within the GUI? Or using the REST API? Now, what I do know is that you cannot identify those files that easy, because they do not write any specific lines within the Data Provenance. If you have a processor right after the failure queue (or if you terminate the failure queue in the processing processor) you can query using that Component ID and identify the type = DROP, meaning that those files have been "processed" (Indicates a provenance event for the conclusion of an object's life for some reason other than object expiration). More about the types can be found here: https://docs.cloudera.com/HDPDocuments/HDF3/HDF-3.1.2/bk_user-guide/content/provenance_events.html ... View more

Well if I understand your flow logic correctly, what you are trying to achieve is not really possible, so please correct me if I am wrong. In your QueryRecord you receive input from the InputPort and from the QueryDatabaseTable Flow as well. Based on the FlowFile coming from that InputPort, you are trying to filter the data, using a SQL which is built on the input coming from the QueryDatabaseTable Flow, right? Basically you want to filter the InputPort Data (FlowFile1) based on the ${value} from QueryDatabaseTable (FlowFile2). Based on my current experience with NiFi, such a thing is not possible because the processors work on a single FlowFile and not with 2+ FlowFiles (unless merged). But maybe somebody with more experience can tell you otherwise. You would need to rethink your flow and build something else --> hence the idea with LookupRecord/LookupAttribute. ... View more

Awesome news, +2 solutions here.   ... View more

Please suggest me for same ... View more

well if you want to modify the port, you have to stop nifi, modify nifi.properties and restart nifi. But without knowing how you configured NiFi ( content of nifi.properties) nobody can tell you how to solve your issue. Maybe you can add the content of nifi.properties here and afterwards we can guide you further. Nevertheless, how Matt stated below, you need to check your application logs and see if NiFi started correctly. If NiFi starts correctly, you will see a log line saying that NiFi UI (User Interface) is available at a specific URL. You need to take that URL and paste it in your browser. If such a line is not available, than you need to check the logs to see what the error is. ... View more

can you maybe post the statement you are running in mongo + the result and afterwards the query you execute in NiFi and the entire error message you receive? Right now it seems to be an error regarding the format of the date/query. I am not that familiar with mongoDB but maybe in the meantime somebody with more experience will intervene. ... View more