apache/cassandra · error · java.lang.UnsupportedOperationException

UnsupportedOperationException

Error message

UnsupportedOperationException

What it means

SEPExecutor.AsynchronousExecutor-style inExecutor() is intentionally not implemented for SEPExecutor: the executor cannot reliably determine whether the current thread belongs to it under its shared-worker model, so the method throws UnsupportedOperationException unconditionally. It is a compile-time-contract stub, not a runtime state failure.

Source

Thrown at src/java/org/apache/cassandra/concurrent/SEPExecutor.java:293

        return addTask(taskFactory.toSubmit(withResources, run, result));
    }

    @Override
    public Future<?> submit(WithResources withResources, Runnable run)
    {
        return addTask(taskFactory.toSubmit(withResources, run));
    }

    @Override
    public <T> Future<T> submit(WithResources withResources, Callable<T> call)
    {
        return addTask(taskFactory.toSubmit(withResources, call));
    }

    @Override
    public boolean inExecutor()
    {
        throw new UnsupportedOperationException();
    }

    public synchronized void shutdown()
    {
        if (shuttingDown)
            return;
        shuttingDown = true;
        pool.executors.remove(this);
        if (getActiveTaskCount() == 0)
            shutdown.signalAll();

        // release metrics
        metrics.release();
        MBeanWrapper.instance.unregisterMBean(mbeanName);
    }

    public synchronized List<Runnable> shutdownNow()
    {

View on GitHub (pinned to 88fd0f6a0e)

Solutions

1. Do not call inExecutor() on SEPExecutor; track executor membership yourself (e.g. compare Thread.currentThread() against your own marker, or wrap tasks to set a ThreadLocal)
2. Guard the call with `if (executor instanceof SEPExecutor)` and take a different path
3. If the check exists to prevent nested execute(), restructure the code so nested submission is unnecessary
4. Report/patch the call site to use an API SEPExecutor supports

Example fix

// before
if (executor.inExecutor()) { ... } // UnsupportedOperationException
// after
if (!(executor instanceof SEPExecutor) && executor.inExecutor()) { ... }

if (executor instanceof SEPExecutor)
    throw new UnsupportedOperationException("SEPExecutor.inExecutor() is unsupported; track membership yourself");

static boolean supportsInExecutor(ExecutorPlus e)
{
    return !(e instanceof SEPExecutor);
}

When it happens

Trigger: Calling executor.inExecutor() on a SEPExecutor (e.g. code that guards re-entrant submission or asserts 'am I on this executor?'), typically via the ExecutorPlus interface.

Common situations: Shared utility code that calls inExecutor() on any ExecutorPlus (works for ThreadPoolExecutorPlus but not SEPExecutor); defensive checks added before calling execute() to avoid nested submission; debugging assertions.

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

• Cannot resize core pool size of SEPExecutor
• Maximum pool size has been changed while resizing
• mTLS Authenticator only supports certificate based authentic
• Chunk cache size cannot be changed.
• Setting capacity of NopCache is not permitted as this cache

AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10). Data as JSON: /api/errors/ba73e28139693d65. Report an issue: GitHub.