[
https://issues.apache.org/jira/browse/NIFI-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15822049#comment-15822049
]
ASF GitHub Bot commented on NIFI-1135:
--------------------------------------
Github user markap14 commented on the issue:
https://github.com/apache/nifi/pull/1413
@mcgilman very cool to have this making its way into NiFi! I did some
testing, and things work well for the most part. However, I did hit a NPE when
running in non-cluster mode:
```
2017-01-13 17:39:42,680 ERROR [NiFi Web Server-33]
o.a.nifi.web.api.config.ThrowableMapper An unexpected error has occurred:
java.lang.NullPointerException. Returning Internal Server Error response.
java.lang.NullPointerException: null
at
org.apache.nifi.web.api.ProvenanceEventResource.getProvenanceEvent(ProvenanceEventResource.java:293)
~[classes/:na]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
~[na:1.8.0_111]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
~[na:1.8.0_111]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[na:1.8.0_111]
at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_111]
```
Looks like the resource is calling getClusterCoordinator() and not
expecting a 'null' to be returned. But in standalone mode, there's no Cluster
Coordinator.
> For Provenance Query, bring back Event Summaries instead of the Events
> themselves
> ---------------------------------------------------------------------------------
>
> Key: NIFI-1135
> URL: https://issues.apache.org/jira/browse/NIFI-1135
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework, Core UI
> Affects Versions: 1.0.0
> Reporter: Mark Payne
> Assignee: Matt Gilman
>
> Currently, when we query Provenance, we pull back up to 1000 events. These
> are full Provenance Events with attributes, etc. If the query takes a long
> time, we will request those objects that already have matched the query many
> times. This amounts to a great deal of heap being used and sending back very
> large JSON objects (10+ MB is not uncommon and it could potentially be far
> worse).
> We should instead use a ProvenanceEventSummary object. This object should
> contain just the info shown in the results table and the pointer to the
> actual event in the Provenance Store. This allows us to return the queries
> much faster, store less data in the heap, and provide less data back to the
> end user with virtually the same experience.
> The one place that this would differ in UX is when the user clicks the "info"
> button to view the entire provenance event, we would have to pull the event
> back from the server, rather than already having that in memory.
> We should consider storing all of the fields in the results table in Lucene
> to provide faster results. Otherwise, we could still get potentially better
> results with the current approach if we just ensure that the first fields
> that we store are those in the results table. This allows us to read just a
> small portion of the event from file and deserializing just a small amount of
> data before moving on to the next event.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
