[
https://issues.apache.org/jira/browse/NIFI-2452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15404962#comment-15404962
]
Joseph Witt commented on NIFI-2452:
-----------------------------------
[~markap14]ok on comments - understood. Given the trivial nature of the
correction i understand why you addressed that here. It is as you know a
general rule best to address the scope of the JIRA directly in a PR and if more
needs to be done either increase the scope of a JIRA or spawn a new JIRA. It
just makes the review process easier and also if someone runs into the other
issue they'll be able to find a JIRA suggesting it was addressed. I've added
that to the description in this case. I've had a pretty complex flow with
significant retention running through the day, have kicked it, let it fill up,
run many queries and the performance has definitely been more consistent and
I've not seen any JVM restarts due to lucene/jvm crashes because we closed
indexes too soon. So, wrapping up testing and then will merge. +1.
Great fix!
> Provenance Repository's Index Readers can be prematurely closed
> ---------------------------------------------------------------
>
> Key: NIFI-2452
> URL: https://issues.apache.org/jira/browse/NIFI-2452
> Project: Apache NiFi
> Issue Type: Sub-task
> Components: Core Framework
> Reporter: Mark Payne
> Assignee: Joseph Witt
> Priority: Blocker
> Fix For: 1.0.0
>
>
> I occasionally see when I run Provenance queries against an active provenance
> repository that the JVM will crash, writing out an hs_err_pid_XXX.log file.
> This appears to be related to
> https://issues.apache.org/jira/browse/LUCENE-7183 which indicates that it's
> caused by using a closed IndexReader.
> Adding to description from nice Github comments from mark:
> Ensure that we keep track of how many references we have to each lucene
> searcher and only close the underlying index reader if there are no
> references to the searcher. Also updated to prefer newer provenance events
> over older provenance events, and calculate FlowFile lineage based on an
> event id instead of a FlowFile UUID, as it's much more efficient
> In resolving the JIRA also cleaned up logic for handling heartbeat messages
> where a few states weren't accounted for leading to an incorrect accounting
> of heartbeats.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
