Github user merrimanr commented on a diff in the pull request:
https://github.com/apache/incubator-metron/pull/395#discussion_r93111809
--- Diff:
metron-platform/metron-common/src/main/java/org/apache/metron/common/configuration/manager/ZkConfigurationManager.java
---
@@ -0,0 +1,129 @@
+/*
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ *
+ */
+
+package org.apache.metron.common.configuration.manager;
+
+import org.apache.curator.framework.CuratorFramework;
+import org.apache.curator.framework.recipes.cache.NodeCache;
+import org.apache.curator.utils.CloseableUtils;
+import org.apache.metron.common.utils.JSONUtils;
+
+import java.io.ByteArrayInputStream;
+import java.io.IOException;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.Map;
+import java.util.Optional;
+
+import static org.apache.commons.lang.ArrayUtils.isNotEmpty;
+
+/**
+ * Responsible for managing configuration values that are created,
persisted, and updated
+ * in Zookeeper.
+ */
+public class ZkConfigurationManager implements ConfigurationManager {
--- End diff --
Let me attempt to give you some context as to why the
ConfiguredBolt.prepare method was written that way. First a TreeCache was
necessary to allow configs to be added at runtime since the Zookeeper node for
that config may or may not exist at startup. If that feature is not important
then I think a collection of NodeCaches is fine. Second, the configs are
stored in Zookeeper as JSON so there is a deserialization step that needs to
happen before they can be read in a bolt. A listener allows a bolt to react
to configuration changes asynchronously, hence deserialization only happens
when a config changes and not every time a tuple is processed. A bolt can
also do other expensive tasks (not just deserializing JSON) like reinitializing
objects or clearing caches.
That being said it makes me nervous that deserialization happens in a
synchronized method every time a tuple is executed. If this is going to be
used in a low volume topology it's probably fine but if you might want to
reconsider using a listener if this should be supported in high velocity
streams.
It's a bummer you couldn't reuse ConfiguredBolt. Is there a way we can
make it more flexible so that you can reuse it?
---
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.
---
