[
https://issues.apache.org/jira/browse/METRON-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16630784#comment-16630784
]
ASF GitHub Bot commented on METRON-1681:
----------------------------------------
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/1213
> @merrimanr: I decided to keep writing out of the abstraction in this PR.
Agreed. I don't think we want this to write. How we write out the result
of parsing will depend on the execution environment.
> @merrimanr To maintain this behavior I added 2 callback functions in the
form of Java Consumers: onSuccess and OnError. The other option would be to
make message processing synchronous and just return a list of results.
I prefer your second suggested approach; just return a list of results. We
can add complexity (like multiple threads, caching) on top of a simple,
synchronous approach should it be needed. But I think the base functionality
should be stupid-simple.
I would make your `ParserRunner` an interface and then make your current
`ParserRunner` the default implementation. Later on we could provide
alternative implementations that maintain a thread pool or do intelligent
caching.
> Decouple the ParserBolt from the Parse execution logic
> ------------------------------------------------------
>
> Key: METRON-1681
> URL: https://issues.apache.org/jira/browse/METRON-1681
> Project: Metron
> Issue Type: Improvement
> Reporter: Justin Leet
> Priority: Major
>
> Per discussion on https://github.com/apache/metron/pull/1099, 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
(v7.6.3#76005)
