What is OxMQ?

OxMQ is an ultra-high-performance distributed message and job queue engine for Java 17+ and Java 21+ engineered with native Project Loom Virtual Threads and offering 100% wire and functional parity with BullMQ v6.

It bridges the distributed queue gap in the Java enterprise ecosystem, unlocking virtual thread concurrency while maintaining zero-protocol friction with Redis and BullMQ ecosystems (including Bull-Board).

---

💡 The Problem: The Java Queue Dilemma

Historically, Java developers building distributed task processing faced an awkward compromise:

1. Heavyweight Message Brokers (Kafka / RabbitMQ): Outstanding for event streaming and pub/sub routing, but complex to operate when you need atomic job delayed retries, job parent-child DAGs, progress tracking, rate limiting, and ad-hoc job cancellations.
2. Traditional Java Redis Queues: Built for Java 8/11 with fixed OS thread pools (FixedThreadPool). When tasks perform blocking I/O (database queries, third-party REST APIs, LLM calls), thread pools quickly become saturated, driving up memory consumption and latency.
3. Node.js BullMQ Parity Gap: Teams using BullMQ in TypeScript/Node had no direct equivalent in Java with matching Redis key topologies and Lua scripts, preventing seamless polyglot architectures.

---

⚡ The Solution: OxMQ — The Java Alternative to BullMQ

OxMQ provides the modern Java ecosystem with the same ergonomic, battle-tested distributed queue architecture that made BullMQ the gold standard in Node.js, supercharged with Java 21 Project Loom Virtual Threads, enterprise Context Isolation, and Java 17 LTS compatibility:

• Native Loom Concurrency with Java 17 Fallback: Every worker task executes on a lightweight Virtual Thread on Java 21+ (Executors.newVirtualThreadPerTaskExecutor()). Virtual threads unmount from carrier threads during blocking I/O (HTTP calls, DB queries, LLM inferences), allowing single worker nodes to comfortably handle thousands of concurrent in-flight jobs. On Java 17 LTS, OxMQ automatically falls back to a tuned platform thread pool via DispatcherExecutorFactory without requiring any code changes.
• 100% BullMQ Wire & Script Parity: Direct execution of 49 official, battle-tested BullMQ Lua scripts with zero custom Lua for atomic job state transitions, locking, scheduling, rate limiting, and DAG dependency re-attachment.
• Native Context Isolation & Multi-Tenancy: Run dozens of microservices safely on a single shared Redis cluster without key collisions or cross-talk using service-level namespace auto-inheritance (oxmq.namespace).
• Synchronous & Reactive Request-Reply (waitUntilFinished): Await background task completion directly from REST controllers or workflow coordinators via Redis Streams and isFinished-3.lua without loop-polling.
• Automated Memory Retention (KeepJobs): Prevent Redis memory creep with structured retention policies (count, ageSeconds, limit) integrated atomically into moveToFinished-14.lua.
• Full Polyglot & Bull-Board Compatibility: Uses standard {prefix}:{queue}:* Redis keys and MessagePack serialization, allowing instant plug-and-play with the open-source Bull-Board Web UI and cross-language Node.js/Python producers and workers.
• Pluggable Storage Backend (QueueBackend): Clean abstraction mirroring BullMQ v6 architecture with RedisQueueBackend implementation.
• Spring Boot 3+ Enterprise Integration: Declarative @OxmqListener and @OxmqBatchListener annotations, multi-event @OxmqHandler routing, auto-configuration, and Spring Boot Actuator health checks.

---

🏛️ High-Level Architecture

---

🎯 Next Steps

• Check out the Quickstart Guide to build your first queue and worker.
• Explore the Spring Boot 3+ Starter for declarative @OxmqListener usage.
• Read about Project Loom Virtual Threads and concurrency management.
• Learn about Memory Optimization & Resource Efficiency for zero-allocation and compaction techniques.