Mulesoft -- Persistent Queues, Batch Job Queues, Object Store V2(OSV2) , Persistent Object Store, Non-Persistent Object Store in CloudHub 1.0

 In MuleSoft CloudHub 1.0, persistent queues and batch job queues are mechanisms to ensure reliable message processing and handle large datasets asynchronously. They are stored and managed differently but work together to provide scalability and reliability.

Persistent Queues:

• Persistent queues in CloudHub 1.0 are used for reliable message delivery across Mule applications, particularly for VM (Virtual Machine) connectors or when distributing workloads across multiple workers.
• They are backed by CloudHub’s Cloud Queue Storage (CQS), which uses Amazon SQS under the hood for persistence.
• When enabled in the Anypoint Runtime Manager (via the "Persistent Queues" checkbox), all VM queues in the application are stored persistently in CQS, overriding any transient queue settings in the Mule configuration.
• Data in persistent queues is stored in the same region as the worker (e.g., AWS SQS in the deployed region) and survives worker restarts or crashes, ensuring zero message loss. However, they do not guarantee one-time-only delivery, and duplicate messages may occur.
• Persistent queues are used for inter-worker communication and workload distribution when an application is deployed to multiple workers.

Batch Job Queues:

• Batch job queues are specific to Mule’s batch processing module, designed to handle large datasets by splitting them into individual records.
• Each batch job instance creates a single persistent queue (prefixed with "BSQ" in Anypoint Runtime Manager) to store records during processing.
• These queues are stored in the worker’s secondary storage (disk-based) by default in CloudHub 1.0. If persistent queues are enabled for the application, batch job queues leverage CloudHub’s CQS (Amazon SQS) for enhanced reliability.
• Records are processed asynchronously through batch steps, and the queue tracks the state of each record (e.g., which steps it has completed). If a worker restarts, the batch job can resume from the last processed record, provided the data is stored in CQS.
• Batch jobs run on a single primary worker and cannot be distributed across multiple workers, unlike persistent queues used for VM connectors.

Object Store V2:

• Stores data and states for Mule 4 applications, accessible within an application or via the Object Store v2 REST API. It supports use cases like caching, duplicate checks, and watermarking.

• Data is stored in the same region as the deployed workers

• Available via the Object Store Connector (works with both v1 and v2) or REST API.

• For Mule 4 apps, select the "Use Object Store v2" checkbox in Runtime Manager during deployment.

• Maximum time-to-live (TTL) of 30 days, Supports both rolling TTL and static TTL

Persistent Object Store:

• A default key-value store in Mule 4 (and Mule 3) for storing data that persists across application restarts, redeployments, or crashes.

• Data is retained for up to 30 days or until explicitly removed. TTL resets only when a key is updated (static TTL).

• Ideal for scenarios requiring data durability, such as caching, watermarking, or duplicate checks within a single application.

Non Persistent Object Store:

• An in-memory key-value store for temporary data storage that does not survive application restarts or redeployments.

• Data is lost when the application restarts, crashes, or is redeployed

• Stored in memory on the CloudHub worker, not persisted to disk or a distributed store. No encryption at rest since it’s ephemeral.

• Via Object Store Connector within the Mule application. No REST API or Runtime Manager UI access, as it’s in-memory and local to the worker.