Github user mattf-horton commented on a diff in the pull request:

    https://github.com/apache/incubator-metron/pull/308#discussion_r83505093
  
    --- Diff: 
metron-platform/metron-parsers/src/main/java/org/apache/metron/parsers/interfaces/MessageParser.java
 ---
    @@ -34,15 +34,15 @@
        * @param rawMessage
        * @return If null is returned, this is treated as an empty list.
        */
    -  List<T> parse(byte[] rawMessage);
    +  List<T> parse(byte[] rawMessage, SensorParserConfig sensorParserConfig);
    --- End diff --
    
    My inclination (and my original suggestion) is to keep all the asynchronous 
behavior entirely in the ParserBolt (where it already is) and only call 
parser.configurationUpdate() synchronously in the execute method.  So yes to 
that.  Then no synch at all needed in GrokParser.
    
    However, your understanding that you could use ParserBolt#updateConfig() to 
capture notification of changes WITHOUT expensive checks, is brilliant, and 
exactly what updateConfig() is for.  If we do it in ParserBolt, all you need is 
one synchronized routine:
    private boolean configUpdatedFlag = false;
    synchronized public boolean atomicCheckAndSet(boolean newValue) {
    boolean oldValue = configUpdatedFlag; configUpdatedFlag = newValue; return 
oldValue;}
    
    Trivial, safe as can be, and ultra cheap.  No way to get deadlock, altho if 
paranoid, one could give it its own lock object instead of using implicit 
locking on the ParserBolt instance.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Reply via email to