Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/1045
I assume you are talking to @nickwallen there @mmiklavc ?
---
Github user mmiklavc commented on the issue:
https://github.com/apache/metron/pull/1045
I didn't know you were still actively reviewing. The last comment I
received besides a +1 was "that looks great, thanks." We do have unit and
integration tests around all of this in addition to
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/1045
My comment was just about calling out a possible need for more shutdown
orchestration.
I am not reviewing.
---
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/1045
I was still going through it. Not sure where @ottobackwards landed on
this.
Besides the open TODO comment, I am not sure how much testing we did around
the Profiler or testing
Github user mmiklavc commented on the issue:
https://github.com/apache/metron/pull/1045
@nickwallen The PR has been up for 7 days, I addressed all community
comments days ago, and no comments appeared to be dissenting. Was there a
concern or issue you had before this was merged?
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/1045
@mmiklavc FYI You've got a TODO comment in `ConfiguredIndexingBolt.java`
that seems like something you wanted to address before merging.
Usually good to at least give a chance for all
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/1045
+1 by inspection. I ran this up in full-dev and data flowed through just
fine.
---
Github user mmiklavc commented on the issue:
https://github.com/apache/metron/pull/1045
Went through a few variations of testing enrichments using the new
KafkaWriter bulk message writer implementation with @anandsubbu and we are
seeing results close to the numbers we see in master
Github user mmiklavc commented on the issue:
https://github.com/apache/metron/pull/1045
@ottobackwards I believe this should already be handled by the acking
strategy. Anything not acked will be replayed since we're leveraging at least
once message processing semantics.
---
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/1045
Maybe we need some kind of orchestration service that you use to shutdown
metron without losing things in the pipeline already
---
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/1045
> This might actually explain why some of the topologies just won't die
sometimes.
The more I think about it, this is very likely what is happening in the
current code base when
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/1045
I noticed that we should probably use a timeout when we call
`KafkaProducer.close`. If we get a huge backlog of messages, it will just
block until the backlog is cleared. We can get in
12 matches
Mail list logo
