metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From nickwallen <>
Subject [GitHub] incubator-metron pull request #421: METRON-283 Migrate Geo Enrichment outsid...
Date Wed, 25 Jan 2017 16:16:30 GMT
Github user nickwallen commented on a diff in the pull request:
    --- Diff: metron-platform/metron-enrichment/src/main/java/org/apache/metron/enrichment/bolt/
    @@ -149,9 +154,10 @@ public JSONObject load(CacheKey key) throws Exception {
         cache = CacheBuilder.newBuilder().maximumSize(maxCacheSize)
                 .expireAfterWrite(maxTimeRetain, TimeUnit.MINUTES)
    +    GeoLiteDatabase.INSTANCE.update((String)getConfigurations().getGlobalConfig().get(GeoLiteDatabase.GEO_HDFS_FILE));
         boolean success = adapter.initializeAdapter();
    --- End diff --
    Does this mean that we will attempt to load the geo database into memory in every `GenericEnrichmentBolt`;
even ones not doing geo-enrichment?  Maybe that is one reason, we have singleton for the GeoLiteDatabase;
to avoid repeated initialization?
    Along the same lines, If I choose to not do geo-enrichment, do I still need to have a
valid Maxmind file in HDFS?  Or would that cause all GenericEnrichmentBolts to fail to initiailize?
    Would it make sense to update the EnrichmentAdapter interface to accept configuration
values, so that this initialization occurs in the GeoAdapter where it makes more sense?  Then
only the bolts doing geo-enrichment attempt to initialize the geo data?

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

View raw message