Github user nickwallen commented on a diff in the pull request:

    https://github.com/apache/metron/pull/977#discussion_r179868541
  
    --- Diff: 
metron-analytics/metron-profiler-common/src/main/java/org/apache/metron/profiler/DefaultMessageDistributor.java
 ---
    @@ -262,11 +262,19 @@ public ProfileBuilder getBuilder(MessageRoute route, 
Context context) throws Exe
       /**
        * Builds the key that is used to lookup the {@link ProfileBuilder} 
within the cache.
        *
    +   * <p>The cache key is built using the hash codes of the profile and 
entity name.  If the profile
    +   * definition is ever changed, the same cache entry will not be reused.  
This ensures that no
    +   * state can be carried over from the old definition into the new, which 
might result in an
    +   * invalid profile measurement.
    +   *
        * @param profile The profile definition.
        * @param entity The entity.
        */
    -  private String cacheKey(ProfileConfig profile, String entity) {
    -    return format("%s:%s", profile, entity);
    +  private int cacheKey(ProfileConfig profile, String entity) {
    +    return new HashCodeBuilder(17, 37)
    --- End diff --
    
    That state is maintained in a `ProfileBuilder` stored in this cache.  If 
the profile definition changes, the cache key would change, which would force 
it to start using a different `ProfileBuilder` instance. 
    
    Say I had a v1.0 of the profile that has been running and now I make 
changes, so I'll call that version 2.0 of the profile.  We'd have 
a`ProfileBuilder` that handles v1.0 of the profile definition and another that 
handles v2.0 of the profile.
    
    The v1.0 instance will stop receiving messages because that profile 
definition no longer exists.  The TTL for the profile will lapse and the 
profile will be marked as "expired".  Then periodically this timer thread will 
trigger a flush of all expired profiles.  The state that was in v1.0 will then 
be flushed and stored.
    
    The v2.0 instance will start receiving messages and building its state.  
This instance will remain "active" because it is receiving messages.  This 
active profile will flush when the period expires and its state will be stored.
    
    It is not safe to mix state when a profile definition is changed by a user. 
 You don't know how the profile was changed and whether the change was 
compatible or not. 


---

Reply via email to