Support Questions
Find answers, ask questions, and share your expertise
Announcements
Alert: Welcome to the Unified Cloudera Community. Former HCC members be sure to read and learn how to activate your account here.

Why DEFAULT_SCHEMA_CACHE_EXPIRY_INTERVAL_SECS is set so low, 300 ms?

Highlighted

Why DEFAULT_SCHEMA_CACHE_EXPIRY_INTERVAL_SECS is set so low, 300 ms?

New Contributor

The Horton SchemaRegistryClient is setting DEFAULT_SCHEMA_CACHE_EXPIRY_INTERVAL_SECS to a value of 300 ms making the schema to expire very quickly. That means a Kafka producer will republish the schema on very short intervals in a streaming scenario, creating a bottleneck.

Why the "_SECS" suffix if the value is used as TimeUnit.MILLISECONDS. Is this a bug and it should be TimeUnit.SECONDS instead? If not a bug, why is expiration interval set so low?

https://github.com/hortonworks/registry/blob/master/schema-registry/client/src/main/java/com/hortonw...

public static final long DEFAULT_SCHEMA_CACHE_EXPIRY_INTERVAL_SECS = 5 * 60L;

public static final ConfigEntry<Number> SCHEMA_TEXT_CACHE_EXPIRY_INTERVAL_SECS =
                ConfigEntry.optional("schema.registry.client.schema.text.cache.expiry.interval.secs",
                                     Integer.class,
                                     "Expiry interval(in seconds) of an entry in schema text cache.",
                                     DEFAULT_SCHEMA_CACHE_EXPIRY_INTERVAL_SECS,
                                     ConfigEntry.PositiveNumberValidator.get());

schemaTextCache = CacheBuilder.newBuilder()
                .maximumSize(((Number) configuration.getValue(Configuration.SCHEMA_TEXT_CACHE_SIZE.name())).longValue())
                .expireAfterAccess(((Number) configuration.getValue(Configuration.SCHEMA_TEXT_CACHE_EXPIRY_INTERVAL_SECS.name())).longValue(),
                                   TimeUnit.MILLISECONDS)
                .build();
Don't have an account?
Coming from Hortonworks? Activate your account here