redis/jedis · error · IllegalArgumentException

is not supported.

Error message

is not supported.

What it means

JedisCommandIterationBase.nextBatch executes a SCAN-family command by obtaining a connection from the iteration's connection holder. If the stored value is neither a Connection nor a Pool (the only two supported types), it throws this IllegalArgumentException naming the offending class. It indicates the iteration object was constructed or reached an unsupported connection type.

Solutions

  1. Pass a Connection or a Pool<Connection> (e.g. JedisPool) when constructing/configuring the iteration
  2. Unwrap custom connection wrappers to the underlying Connection before iterating
  3. Upgrade Jedis so the iteration base recognizes the connection type used by your client version
  4. If subclassing, override the connection-execution path instead of feeding unsupported types

Example fix

// before
iteration.addConnection(new MyConnectionWrapper(pool));
// after
try (Connection c = pool.getResource()) {
  iteration.addConnection(c);
}
Defensive patterns

Strategy: validation

Validate before calling

Object v = connection.getValue();
if (!(v instanceof Connection) && !(v instanceof Pool)) {
  throw new IllegalStateException("Iteration requires Connection or Pool, got " + v.getClass());
}

Type guard

boolean isSupportedConnectionHolder(Object v) { return v instanceof Connection || v instanceof Pool; }

Try / catch

try {
  iteration.nextBatch();
} catch (IllegalArgumentException e) {
  // rebuild iteration with a Connection or Pool<Connection>
}

Prevention

When it happens

Trigger: Running a scan iteration (e.g. cluster scan helper) whose connection holder value is some object other than Connection or Pool<Connection> — typically after custom construction of the iteration or a library/version change introducing a new connection wrapper type.

Common situations: Custom code passing a wrapped or proxied connection into the iteration base; mixing Jedis versions where the wrapper type changed; subclassing the iteration base and supplying a custom connection container.

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 redis/jedis@6dac31d4c2 (2026-09-08). Data as JSON: /api/errors/fe113d9246b1b143. Report an issue: GitHub.

Appendix: source

Thrown at src/main/java/redis/clients/jedis/util/JedisCommandIterationBase.java:75

    }

    CommandArguments args;
    if (iterationCompleted) {
      connection = connections.poll();
      args = initCommandArguments();
    } else {
      args = nextCommandArguments(lastReply);
    }

    Object rawReply;
    if (connection.getValue() instanceof Connection) {
      rawReply = ((Connection) connection.getValue()).executeCommand(args);
    } else if (connection.getValue() instanceof Pool) {
      try (Connection c = ((Pool<Connection>) connection.getValue()).getResource()) {
        rawReply = c.executeCommand(args);
      }
    } else {
      throw new IllegalArgumentException(connection.getValue().getClass() + "is not supported.");
    }

    lastReply = builder.build(rawReply);
    iterationCompleted = isNodeCompleted(lastReply);
    if (iterationCompleted) {
      if (connections.isEmpty()) {
        roundRobinCompleted = true;
      }
    }
    return lastReply;
  }

  protected abstract Collection<D> convertBatchToData(B batch);

  public final Collection<D> nextBatchList() {
    return convertBatchToData(nextBatch());
  }

View on GitHub (pinned to 6dac31d4c2)