Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/711
@nickwallen
The question of the assumption of how complete the passed data is can wait.
My point about escalateOne vs. escalateMany stands.
---
Laurens,
If you have exceptions, you may have seen the effects of this, if from a
different cause.
On September 4, 2017 at 13:25:42, Laurens Vets (laur...@daemon.be) wrote:
Hi Otto,
Might this be related to the issues I was seeing? If/when indexing
topology got broken, I couldn't recover until
if i do not use the ambari mpack, is there a way to configure and start the
indexing topology manually?
i have not installed the mpack as i ran into issues and installed hadoop
without it.
i found the start_elasticsearch_topology.sh, found the elasticsearch.properties
file, but no luck manua
Hi Otto,
Might this be related to the issues I was seeing? If/when indexing
topology got broken, I couldn't recover until I cleared all queues.
On 2017-09-04 08:23, Otto Fowler wrote:
It looks like if the SourceHandler has a problem with it’s output
stream,
it will never recover.
The handler
!ret.isUsable
On September 4, 2017 at 11:23:09, Otto Fowler (ottobackwa...@gmail.com)
wrote:
> It looks like if the SourceHandler has a problem with it’s output stream,
> it will never recover.
> The handler will be in the map and continue to be used, but it will
> continue to throw exceptions.
>
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/711
@ottobackwards What do you think about this one? Good enough for a first
pass?
---
It looks like if the SourceHandler has a problem with it’s output stream,
it will never recover.
The handler will be in the map and continue to be used, but it will
continue to throw exceptions.
Is there a reason why we don’t try to recover and recreate the SourceHandler,
such as:
synchronized So
