What causes "UnsupportedOperationException" in apache/cassandra?

Drain the queue with poll() in a loop instead of iterating.

apache/cassandra · warning · java.lang.UnsupportedOperationException

UnsupportedOperationException

Error message

UnsupportedOperationException

What it means

ManyToOneConcurrentLinkedQueue is a specialized many-producer/single-consumer queue that supports only the mutation/inspection primitives it needs (offer, poll, peek, etc.). iterator() is intentionally unimplemented and always throws UnsupportedOperationException, because traversal would violate its single-consumer design and lock-free implementation.

Source

Thrown at src/java/org/apache/cassandra/concurrent/ManyToOneConcurrentLinkedQueue.java:241

            }
            else
            {
                // check for tail updates after two hops
                p = (p != t && t != (t = tail)) ? t : q;
            }
        }
    }

    @Override
    public boolean contains(Object o)
    {
        throw new UnsupportedOperationException();
    }

    @Override
    public Iterator<E> iterator()
    {
        throw new UnsupportedOperationException();
    }

    @Override
    public Object[] toArray()
    {
        throw new UnsupportedOperationException();
    }

    @Override
    public <T> T[] toArray(T[] a)
    {
        throw new UnsupportedOperationException();
    }

    @Override
    public boolean containsAll(Collection<?> c)
    {
        throw new UnsupportedOperationException();

View on GitHub (pinned to 88fd0f6a0e)

Solutions

Drain the queue with poll() in a loop instead of iterating.
Snapshot contents yourself: repeatedly poll into a list if you can afford consuming the elements.
Catch UnsupportedOperationException around iteration and fall back to drain-based inspection.
If full Collection semantics are needed, use ConcurrentLinkedQueue or ArrayBlockingQueue instead.

Example fix

// before
for (E e : queue) { inspect(e); } // throws UnsupportedOperationException
// after
List<E> drained = new ArrayList<>();
E e;
while ((e = queue.poll()) != null) drained.add(e);

Defensive patterns

Strategy: try-catch

Validate before calling

// avoid iteration entirely; drain instead
List<E> snapshot = new ArrayList<>();
E e;
while ((e = queue.poll()) != null) snapshot.add(e);

Type guard

boolean supportsIteration(Collection<E> c) { return !(c instanceof ManyToOneConcurrentLinkedQueue); }

Try / catch

try {
    for (E e : queue) inspect(e);
} catch (UnsupportedOperationException e) {
    // fall back to drain-based inspection
}

Prevention

Never use for-each/streams on ManyToOneConcurrentLinkedQueue.
Drain with poll() to inspect contents.
Do not pass it as Collection<E> to generic utilities.
Use ConcurrentLinkedQueue if iteration is required.

When it happens

Trigger: Calling iterator() on the queue — directly, via for-each loops (for (E e : queue)), via streams (queue.stream()), or via Collection-copying helpers like new ArrayList<>(queue) and Guava/Collectors helpers that use Spliterator/iteration.

Common situations: Debug/monitoring code that dumps queue contents; tests iterating the queue to assert contents; generic code accepting Collection<E> and iterating it; converting the queue with copy constructors.

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/cassandra@88fd0f6a0e (2026-09-10). Data as JSON: /api/errors/1523d87a9512ef34. Report an issue: GitHub.