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 [email protected] or file a JIRA ticket
with INFRA.
---
