{"record":{"id":"6d254e94e2ae6769","repo":"apache/cassandra","slug":"cannot-resize-core-pool-size-of-sepexecutor","errorCode":null,"errorMessage":"Cannot resize core pool size of SEPExecutor","messagePattern":"Cannot resize core pool size of SEPExecutor","errorType":"exception","errorClass":"java.lang.IllegalArgumentException","httpStatus":null,"severity":"error","filePath":"src/java/org/apache/cassandra/concurrent/SEPExecutor.java","lineNumber":359,"sourceCode":"    @Override\n    public long getCompletedTaskCount()\n    {\n        return completedTasks.get();\n    }\n\n    public int getActiveTaskCount()\n    {\n        return maximumPoolSize.get() - workPermits(permits.get());\n    }\n\n    public int getCorePoolSize()\n    {\n        return 0;\n    }\n\n    public void setCorePoolSize(int newCorePoolSize)\n    {\n        throw new IllegalArgumentException(\"Cannot resize core pool size of SEPExecutor\");\n    }\n\n    @Override\n    public int getMaximumPoolSize()\n    {\n        return maximumPoolSize.get();\n    }\n\n    @Override\n    public synchronized void setMaximumPoolSize(int newMaximumPoolSize)\n    {\n        final int oldMaximumPoolSize = maximumPoolSize.get();\n\n        if (newMaximumPoolSize < 0)\n        {\n            throw new IllegalArgumentException(\"Maximum number of workers must not be negative\");\n        }\n","sourceCodeStart":341,"sourceCodeEnd":377,"githubUrl":"https://github.com/apache/cassandra/blob/88fd0f6a0eaed8943f05ac9e8f947882b8ddc8f1/src/java/org/apache/cassandra/concurrent/SEPExecutor.java#L341-L377","documentation":"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.","triggerScenarios":"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.","commonSituations":"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.","solutions":["Do not resize SEPExecutors; size them correctly at construction (max pool size can still be adjusted via setMaximumPoolSize)","Guard with `if (executor instanceof SEPExecutor)` before calling setCorePoolSize and skip/handle it","Use setMaximumPoolSize if the intent is to change capacity of the SEPExecutor","Apply dynamic resizing only to ThreadPoolExecutorPlus-based executors"],"exampleFix":"// before\nexecutor.setCorePoolSize(newSize); // IllegalArgumentException\n// after\nif (!(executor instanceof SEPExecutor))\n    executor.setCorePoolSize(newSize);\nelse\n    executor.setMaximumPoolSize(newSize);","handlingStrategy":"validation","validationCode":"if (executor instanceof SEPExecutor)\n    throw new UnsupportedOperationException(\"setCorePoolSize is unsupported for SEPExecutor\");\nif (newSize < 0)\n    throw new IllegalArgumentException(\"pool size must be non-negative\");","typeGuard":"static boolean supportsCorePoolResize(ExecutorPlus e)\n{\n    return !(e instanceof SEPExecutor);\n}","tryCatchPattern":null,"preventionTips":["Size SEPExecutors at construction; resize only via setMaximumPoolSize","Apply core-pool resizing only to ThreadPoolExecutorPlus executors","Make admin/JMX resize paths type-aware","Validate parsed pool-size config values before applying them"],"tags":["unsupported-operation","executor","illegal-argument"],"backgroundTag":"unsupported-operation","analyzedSha":"88fd0f6a0eaed8943f05ac9e8f947882b8ddc8f1","analyzedAt":"2026-09-10T07:29:22.284Z","contentChangedAt":"2026-09-10T07:29:22.284Z","schemaVersion":2},"datasetVersion":"2026-09-14T16:17:12.679Z"}