You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "Joseph Witt (JIRA)" <ji...@apache.org> on 2016/11/01 02:25:58 UTC

[jira] [Commented] (NIFI-2890) Provenance Repository corruption

    [ https://issues.apache.org/jira/browse/NIFI-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15624098#comment-15624098 ] 

Joseph Witt commented on NIFI-2890:
-----------------------------------

[~devriesb] on Oct 11th Writes:
 I just opened a ticket to address an issue we've encountered with
Provenance repo corruption[1].  This would address (as is currently
partially being done) how to recover from a corrupt provenance repo.
However, the question is whether we can avoid this sort of corruption in
the first place.  The immediate thought that jumped to mind was wrapping
the writes to lucene with a write ahead log.  Obviously, this would
increase the overhead on something that is already fairly expensive.
However, in cases where provenance is *really* important, it might be worth
considering.  This could potentially be another flavor of
ProvenanceEventRepository, e.g.  WriteAheadPersistentProvenanceRepository
or FaultTolerantProvenanceRepository.  Does anyone have any thoughts /
opinions?


--- 

This looks like an important issue.  [~markap14] Can you take a look at this?

> Provenance Repository corruption
> --------------------------------
>
>                 Key: NIFI-2890
>                 URL: https://issues.apache.org/jira/browse/NIFI-2890
>             Project: Apache NiFi
>          Issue Type: Bug
>    Affects Versions: 1.0.0, 0.7.0
>            Reporter: Brandon DeVries
>
> It looks as thought there was a ticket to address this\[1\], but it appears to not have completely addressed the issue. On an 0.6.1 instance (that crashed hard), I'm getting a stack trace on startup indicating a corrupt prov repo. The relevant part of the stack trace (unfortunately typed by hand, so forgive the inevitable typos) is:
> {quote}
> ...
> Caused By java.lang.IllegalArgumentException: No enum constant org.apahe.nifi.provenance.ProvenenceEventType.
> at java.lang/.Enum.valueOf...
> at org.apache.nifi.provenance.ProvenanaceEventType.valueOf(ProvenanaceEventType.java:19)
> at
> org.apache.nifi.provenance.StandardRecordReader.nextRecord(StandardRecordReader.java:284)
> at org.apache.nifi.provenance.PersistentProvenanceRepository.mergeJournals(PersistentProvenanceRepository.java:1678) \[2\]
> ...
> {quote}
> In 0.x HEAD, this appears to have moved a bit\[3\]. Same is true for 1.x\[4\]. In both 0.x\[5\] and 1.x\[6\], code was added to check for "bad" records coming from the reader, and skip them. However, this appears to only address the issue if the corrupt / bad record is the *first* record coming out of a reader. If it is a subsequent record, the corruption remains.
> \[1\] https://issues.apache.org/jira/browse/NIFI-803
> \[2\] https://github.com/apache/nifi/blob/rel/nifi-0.6.1/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java#L1678
> \[3\] https://github.com/apache/nifi/blob/0.x/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java#L1711
> \[4\] https://github.com/apache/nifi/blob/rel/nifi-0.6.1/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java#L1678
> \[5\] https://github.com/apache/nifi/blob/0.x/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java#L1564-L1578
> \[6\] https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java#L1658-L1672



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)