[ https://issues.apache.org/jira/browse/METRON-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15767942#comment-15767942 ]
ASF GitHub Bot commented on METRON-590: --------------------------------------- Github user mattf-horton commented on the issue: https://github.com/apache/incubator-metron/pull/395 Recording here for posterity, in case anyone is interested: I asked on the storm user list: ``` I’ve been unable to find this in the Storm documentation: How does the Storm topology loader identify if a Bolt is a “windowing” bolt and therefore needs to be wrapped with WindowedBoltExecutor? Does it look at: 1. Whether the Bolt’s getComponentConfiguration() method presents some or all of the windowing-related configuration parameters, as BaseWindowedBolt does; 2. Or does it use reflection to determine if the Bolt implements IWindowedBolt interface; 3. Or does the Bolt actually have to extend BaseWindowedBolt? There are indications in the docs that it is #2, but I wasn’t able to become certain. Please clarify. Thanks, --Matt ``` and got confirmation that it is #2 only: ``` From: Arthur Maciejewicz <art...@signafire.com> You must satisfy the IWindowedBolt and IComponent interfaces. BaseWindowedBolt is there for your convenience. When constructing the topology, there is a setBolt method on TopologyBuilder specifically for bolts satisfying the IWindowedBolt interface. It will be wrapped with a WindowedBoltExecutor by the TopologyBuilder for you. You can implement windows yourself by returning a HashMap from getComponentConfiguration in your custom bolt (as long as they also implement the IWindowedBolt interface). ``` > Enable Use of Event Time in Profiler > ------------------------------------ > > Key: METRON-590 > URL: https://issues.apache.org/jira/browse/METRON-590 > Project: Metron > Issue Type: Improvement > Reporter: Nick Allen > Assignee: Nick Allen > > There are at least two different times that are important to consider when > handling the telemetry messages received by Metron. > (1) Processing time is the time at which Metron processed the message. > (2) Event time is the time at which the event actually occurred. > If Metron is consuming live data and all is well, the processing and event > times may remain close and consistent. When processing time differs from > event time the data produced by the Profiler may be inaccurate. There are a > few scenarios under which these times might differ greatly which would > negatively impact the feature set produced by the Profiler. > (1) When the system has experienced an outage, for example, a scheduled > maintenance window. When restarted a high volume of messages will need to be > processed by the Profiler. The output of the Profiler will indicate an > increase in activity, although no change in activity actually occurred on the > target network. This could happen whether the outage was Metron itself or an > upstream system that feeds data to Metron. > (2) If the user attempts to replay historical telemetry through the Profiler, > the Profiler will attribute the activity to the time period in which it was > processed. Obviously the activity should be attributed to the time period in > which the raw telemetry events originated in. > There are some scenarios when processing time might be preferred and other > use cases where event time is preferred. The Profiler should be enhanced to > allow it to produce profiles based on either processing time or event time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)