apache/cassandra · error · java.lang.IllegalArgumentException

Cannot resize core pool size of SEPExecutor

Error message

Cannot resize core pool size of SEPExecutor

What it means

SEPExecutor has no fixed core pool; worker counts are driven by shared-permit accounting in SharedExecutorPool, so setCorePoolSize is meaningless for it and always throws IllegalArgumentException. The message explicitly says the core pool size of a SEPExecutor cannot be resized.

Source

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

    @Override
    public long getCompletedTaskCount()
    {
        return completedTasks.get();
    }

    public int getActiveTaskCount()
    {
        return maximumPoolSize.get() - workPermits(permits.get());
    }

    public int getCorePoolSize()
    {
        return 0;
    }

    public void setCorePoolSize(int newCorePoolSize)
    {
        throw new IllegalArgumentException("Cannot resize core pool size of SEPExecutor");
    }

    @Override
    public int getMaximumPoolSize()
    {
        return maximumPoolSize.get();
    }

    @Override
    public synchronized void setMaximumPoolSize(int newMaximumPoolSize)
    {
        final int oldMaximumPoolSize = maximumPoolSize.get();

        if (newMaximumPoolSize < 0)
        {
            throw new IllegalArgumentException("Maximum number of workers must not be negative");
        }

View on GitHub (pinned to 88fd0f6a0e)

Solutions

1. Do not resize SEPExecutors; size them correctly at construction (max pool size can still be adjusted via setMaximumPoolSize)
2. Guard with `if (executor instanceof SEPExecutor)` before calling setCorePoolSize and skip/handle it
3. Use setMaximumPoolSize if the intent is to change capacity of the SEPExecutor
4. Apply dynamic resizing only to ThreadPoolExecutorPlus-based executors

Example fix

// before
executor.setCorePoolSize(newSize); // IllegalArgumentException
// after
if (!(executor instanceof SEPExecutor))
    executor.setCorePoolSize(newSize);
else
    executor.setMaximumPoolSize(newSize);

if (executor instanceof SEPExecutor)
    throw new UnsupportedOperationException("setCorePoolSize is unsupported for SEPExecutor");
if (newSize < 0)
    throw new IllegalArgumentException("pool size must be non-negative");

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

When it happens

Trigger: Calling setCorePoolSize(n) on any SEPExecutor, typically via generic code that resizes ThreadPoolExecutor-style pools or dynamic pool-sizing config applied uniformly to all ExecutorPlus instances.

Common situations: JMX/admin tooling that resizes all registered executors; configuration like concurrent_compactors/counter writes being applied via setCorePoolSize on native-transport or internal SEP executors; test code parameterized over executor types.

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

• UnsupportedOperationException
• Maximum number of workers must not be negative
• 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/6d254e94e2ae6769. Report an issue: GitHub.