metron-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (METRON-1681) Decouple the ParserBolt from the Parse execution logic
Date Thu, 04 Oct 2018 20:46:00 GMT


ASF GitHub Bot commented on METRON-1681:

Github user merrimanr commented on the issue:
    The latest commit removes the callbacks.  Now the execute method returns a list of ParserResult
objects.  I had to add a MetronError field to the ParserResult class so that both successful
messages and errors are passed back.
    I also noticed we are currently skipping a tuple if no configuration is found for that
sensor.  I think skipping the tuple is fine but we should still log an error message.  I made
a change in the ParserRunner class to throw an error on this condition.  The parser bolt will
catch it and handle it similar to a parser error by creating a MetronError object and sending
it to the error topic.  Does anyone think we should keep as it is now?

> Decouple the ParserBolt from the Parse execution logic
> ------------------------------------------------------
>                 Key: METRON-1681
>                 URL:
>             Project: Metron
>          Issue Type: Improvement
>            Reporter: Justin Leet
>            Priority: Major
> Per discussion on, there are concerns about
the ParserBolt needed some refactoring.  The discussion didn't hold the PR up, but it was
generally agreed that we should decouple some of the initialization and execution logic.
> This also aids us in integrating with other systems such as NiFi or Spark.

This message was sent by Atlassian JIRA

View raw message