Station 1 of 3 · 45 minutes · S01 / S02 · Exercise A
Queues and competing consumers
Explain how a queue retains waiting work and how consumers share it.
Shipping workers process order commands. When workers stop, orders should wait. When a second worker joins, it should help with the same backlog.
Prerequisites: Java foundations and the common setup, with Terminal 1 showing BROKER_READY. Use your own local broker. Keep a fresh namespace consistent across cooperating clients.
1. Predict
If two workers consume the same queue, which orders will each worker receive? What remains available when both workers stop?
Write your prediction in the worksheet before commands, hints or AI. Keep the sent and received business-ID sets as evidence.
2. Run
Send with no worker
Lab root: the folder containing mvnw.cmd (source) or RUN.md (runtime ZIP).
Leave Terminal 2 idle. Terminal 1 must already show BROKER_READY. Use pilot-q1 only for a fresh run.
.\scripts\lab.cmd s01 produce --count 10 --namespace pilot-q1
.\scripts\lab.cmd s01 browse --namespace pilot-q1Observe: Ten SEND business IDs and visible=10. Copy the ID set into your worksheet.
Process the waiting batch
Lab root: the folder containing mvnw.cmd (source) or RUN.md (runtime ZIP).
Use the same namespace as the producer. This bounded worker exits after ten deliveries.
.\scripts\lab.cmd s01 consume --worker alice --count 10 --namespace pilot-q1Observe: Ten COMMIT records. Reconcile the committed business IDs with the sent set.
Inspect after the worker exits
Lab root: the folder containing mvnw.cmd (source) or RUN.md (runtime ZIP).
Wait for Terminal 2 to finish before browsing.
.\scripts\lab.cmd s01 browse --namespace pilot-q1Observe: visible=0. Browsing is a snapshot and excludes active deliveries.
Start the first competing worker
Lab root: the folder containing mvnw.cmd (source) or RUN.md (runtime ZIP).
Use a new namespace, pilot-q2. This worker stays active; open Terminal 3 separately.
.\scripts\lab.cmd s02 consume --worker alice --continuous --sleep 150 --namespace pilot-q2Observe: Wait for READY in Terminal 2.
Start the second competing worker
Lab root: the folder containing mvnw.cmd (source) or RUN.md (runtime ZIP).
Do not publish until BOTH workers show READY. Each worker owns a connection and transacted session.
.\scripts\lab.cmd s02 consume --worker bob --continuous --sleep 150 --namespace pilot-q2Observe: Wait for READY in Terminal 3.
Send shared work
Lab root: the folder containing mvnw.cmd (source) or RUN.md (runtime ZIP).
Only after both READY signals. Keep the workers running until the combined committed set is complete.
.\scripts\lab.cmd s02 produce --count 10 --namespace pilot-q2Observe: Both workers participate. The union of their committed IDs equals the sent set, and their sets are disjoint in this controlled failure-free run. An equal split or alternating order is not required.
3. Break
Stop both workers after the complete set
Lab root: the folder containing mvnw.cmd (source) or RUN.md (runtime ZIP).
Use Ctrl+C in each worker terminal after all ten business IDs have committed. Do not crash during processing in this experiment; Station 3 covers that case.
Observe: Both worker processes have exited.
Create a backlog
Lab root: the folder containing mvnw.cmd (source) or RUN.md (runtime ZIP).
First confirm visible=0, then send three orders while both workers remain stopped.
.\scripts\lab.cmd s02 browse --namespace pilot-q2
.\scripts\lab.cmd s02 produce --count 3 --namespace pilot-q2
.\scripts\lab.cmd s02 browse --namespace pilot-q2Observe: The last browse shows visible=3. Work is retained even though processing has stopped.
4. Explain
- Where did the three waiting orders live after the producer exited?
- Show the sent and committed ID sets. Why do ten total commits not imply ten at each worker?
- Find receive, business work and session.commit() in the private code. How does a missing commit change the conclusion?
Staged hints
Use one hint at a time after recording your prediction.
Hint 1
A queue retains work for its consumers. Two consumers on that queue share deliveries; they are not independent subscriptions.
Hint 2
Use a transacted session per worker. Receive, perform the simulated work, then commit. Use continuous mode when each worker’s share is unknown and compare the combined business-ID set.
Check your understanding
Choose an answer, then check it for feedback. These questions do not affect quiz exam scoring.
5. Adapt
Complete or extend AExercise.java in the private exercises module. Implement the producer and transacted consumer using direct Jakarta Messaging calls. Change batch size and processing delay, predict the new result, then compare the ID sets. Use a fresh namespace in every exercise client; A uses S02 destinations. Rebuild with -Ptraining. Worked solutions remain in the separate private solutions module.
Reflect on the change
What did you predict, what changed, and which IDs or state support your explanation?
Which suggestion did you accept or reject, and what evidence informed that decision? If you used no assistance, explain the decision you made from the supplied material.
Completion checklist
This is a local self-assessment. Nothing is submitted or saved.
Clean up this station
Drain the known three-order backlog
Lab root: the folder containing mvnw.cmd (source) or RUN.md (runtime ZIP).
Both continuous workers must be stopped. Process the three orders created in the Break step.
.\scripts\lab.cmd s02 consume --worker cleanup --count 3 --namespace pilot-q2Observe: Three COMMITs, then process exit.
Confirm the station is clear
Lab root: the folder containing mvnw.cmd (source) or RUN.md (runtime ZIP).
Wait for the cleanup worker to exit. Leave the local broker running for Station 2.
.\scripts\lab.cmd s02 browse --namespace pilot-q2Observe: visible=0. If your adaptation used another namespace, drain its known remaining count separately.