apache/dubbo · error · RejectException
no more memory can be used !
Error message
no more memory can be used !
What it means
Thrown by AbortPolicy.reject when a bounded queue rejects an element, wrapped in a RejectException. AbortPolicy is the default rejection handler for Dubbo's concurrent queues; it aborts rather than blocking or dropping, signalling that the queue/executor cannot accept more work.
Source
Thrown at dubbo-common/src/main/java/org/apache/dubbo/common/concurrent/AbortPolicy.java:28
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.dubbo.common.concurrent;
import java.util.Queue;
/**
* A handler for rejected element that throws a {@code RejectException}.
*/
public class AbortPolicy<E> implements Rejector<E> {
@Override
public void reject(final E e, final Queue<E> queue) {
throw new RejectException("no more memory can be used !");
}
}
View on GitHub (pinned to 3a3043227f)
Solutions
- Increase the queue/pool capacity to match the expected throughput.
- Switch to a different Rejector (e.g. CallerRunsPolicy-style) if blocking the producer is acceptable.
- Add backpressure or rate-limiting at the producer to prevent saturation.
- Investigate downstream stalls that cause the queue to fill and fix the slow consumer.
Example fix
// before new AbortPolicy<>(); // throws on saturation // after new CallerRunsPolicy<>(); // or size the queue to load new LinkedBlockingQueue<>(10000);
Defensive patterns
Strategy: try-catch
Validate before calling
// Before enqueueing, check remaining capacity
if (queue.remainingCapacity() > 0) {
queue.offer(e);
} else {
// apply backpressure or resize the queue
} Type guard
static boolean hasCapacity(Queue<?> q, int capacity) {
return q.size() < capacity;
} Try / catch
try {
rejector.reject(e, queue);
} catch (RejectException ex) {
// queue saturated; back off, resize, or use a different policy
} Prevention
- Size queues and thread pools to expected throughput.
- Choose a rejection policy that fits your backpressure needs (e.g. caller-runs).
- Add rate limiting at producers to avoid saturation.
- Monitor and fix slow consumers that cause queues to fill.
When it happens
Trigger: A Rejector-backed queue (e.g. a Dubbo serialization/processing queue) is full or has been shut down, and AbortPolicy is the configured rejection policy. The reject() method unconditionally throws RejectException.
Common situations: Backpressure: the producer is faster than the consumer and the bounded queue saturates. Thread pool or queue capacity is too small for the load. A downstream stage is stalled, causing upstream queues to fill.
Related errors
- INTERNAL_ERROR
- Failed to acquire read lock on invokerRefreshLock within tim
- Interrupted while acquiring read lock for invoker access, ca
- {} is not exclusive. Maybe multiple Dubbo instances are usin
- ExtensionDirector is destroyed
AI-assisted analysis of apache/dubbo@3a3043227f (2026-08-14).
Data as JSON: /api/errors/6db157e16b3df7f4.
Report an issue: GitHub.