apache/druid · error · RuntimeException

Unable to get SHA1 digest instance

Error message

Unable to get SHA1 digest instance

What it means

JavaScriptAggregatorFactory.getCacheKey computes a SHA-1 digest of the aggregator's configuration to build a stable cache key. It requests a MessageDigest instance for algorithm "SHA1" from the JCA provider; if no provider supplies SHA1, NoSuchAlgorithmException is thrown and rethrown as a RuntimeException with the message "Unable to get SHA1 digest instance". In a normal JVM this never happens because every conforming JDK includes SHA1 in its default provider set.

Source

Thrown at processing/src/main/java/org/apache/druid/query/aggregation/JavaScriptAggregatorFactory.java:246

    return fieldNames;
  }

  @Override
  public byte[] getCacheKey()
  {
    try {
      MessageDigest md = MessageDigest.getInstance("SHA-1");
      byte[] fieldNameBytes = StringUtils.toUtf8(Joiner.on(",").join(fieldNames));
      byte[] sha1 = md.digest(StringUtils.toUtf8(fnAggregate + fnReset + fnCombine));

      return ByteBuffer.allocate(1 + fieldNameBytes.length + sha1.length)
                       .put(AggregatorUtil.JS_CACHE_TYPE_ID)
                       .put(fieldNameBytes)
                       .put(sha1)
                       .array();
    }
    catch (NoSuchAlgorithmException e) {
      throw new RuntimeException("Unable to get SHA1 digest instance", e);
    }
  }

  @Override
  public ColumnType getIntermediateType()
  {
    return ColumnType.FLOAT;
  }

  @Override
  public ColumnType getResultType()
  {
    return ColumnType.FLOAT;
  }

  @Override
  public int getMaxIntermediateSize()
  {

View on GitHub (pinned to 9b90983fd2)

Solutions

  1. Restore the default JCA providers: remove java.security security provider overrides that exclude SUN, or add a provider that supplies SHA1 MessageDigest.
  2. Check that the JVM/JRE image includes java.base security modules (java.security.MessageDigest, SUN provider); use a full JDK distribution.
  3. If FIPS policy blocks SHA1 for MessageDigest (as opposed to signatures), allow SHA1 for digest-only use or configure the provider accordingly.
  4. Disable or bypass query result caching so getCacheKey is not invoked while the environment is being fixed.

Example fix

// before: stripped providers in java.security
// security.provider.1=org.bouncycastle.jce.provider.BouncyCastleProvider  (no SUN, no SHA1 MessageDigest)
// after: keep the default SUN provider which supplies SHA1
// security.provider.1=sun.security.provider.Sun
// security.provider.2=org.bouncycastle.jce.provider.BouncyCastleProvider
Defensive patterns

Strategy: try-catch

Validate before calling

// verify SHA1 MessageDigest is available before enabling caching paths
try {
  java.security.MessageDigest.getInstance("SHA1");
} catch (java.security.NoSuchAlgorithmException e) {
  throw new IllegalStateException("JVM is missing SHA1 MessageDigest; query result caching will fail", e);
}

Try / catch

try {
  byte[] cacheKey = (byte[]) factory.getCacheKey();
} catch (RuntimeException e) {
  if (e.getMessage() != null && e.getMessage().contains("Unable to get SHA1 digest instance")) {
    log.error(e, "JCA provider cannot supply SHA1; fix java.security providers");
    // disable caching and rethrow as configuration error
  }
  throw e;
}

Prevention

When it happens

Trigger: Invoking getCacheKey() on a JavaScriptAggregatorFactory while running on a JVM whose security providers were stripped of SHA1/MessageDigest support, or with a restricted JCE policy / custom Provider list that removes the SUN provider. The call occurs whenever query result caching is used (broker populates/populates cache keys for aggregators).

Common situations: Hardened or FIPS-only JVM configurations where SHA1 is deliberately disabled; custom java.security provider registrations that remove the default SUN provider; running on a nonstandard/minimal JRE (e.g. stripped module image) lacking the JCA MessageDigest implementation.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors


AI-assisted analysis of apache/druid@9b90983fd2 (2026-09-07). Data as JSON: /api/errors/44e09907807e1ab5. Report an issue: GitHub.