[
https://issues.apache.org/jira/browse/METRON-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15677447#comment-15677447
]
ASF GitHub Bot commented on METRON-575:
---------------------------------------
Github user nickwallen commented on the issue:
https://github.com/apache/incubator-metron/pull/362
There are a couple of constraints on this parameter. (1) The profile TTL
must be greater than the period duration. (2) It doesn't make sense for a
profile to be invalidated part way through a period. I could have made the
profile TTL specified by time units, but then I would have to manually validate
these constraints. My thought was that if I allow the user to specify the
number of periods, then the constraints are mostly self-validating.
I also think, to some degree, it makes sense for the profile TTL to scale
with the period duration. But I am not sure I've fully convinced myself of
this yet.
Still think time units are better?
> State from different profiles can be co-mingled incorrectly
> -----------------------------------------------------------
>
> Key: METRON-575
> URL: https://issues.apache.org/jira/browse/METRON-575
> Project: Metron
> Issue Type: Bug
> Reporter: Nick Allen
> Assignee: Nick Allen
>
> The ProfileBuilderBolt incorrectly assumes that it will only ever see a
> single [profile, entity] pair. The bolt maintains a single StellarExecutor
> that is responsible for executing the init, update, result expressions. This
> assumption is incorrect as Storm's field grouping only guarantees that the
> same profile/entity pairs will go to the same task. Storm does not guarantee
> that a task only receives a single profile/entity pair.
> The easiest fix is to maintain a cache that maps a profile/entity to its
> state. This would follow what is currently done in the Join bolt.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
