Command platformKept for this browser session. No learning progress is saved.

Station 2 of 3 · 45 minutes · S03 · Exercise B · S04 optional

Events and independent subscribers

Distinguish shared work from independent interest in the same event.

An accepted order matters to both billing and shipping. Each service needs its own complete set of future OrderCreated events, even though they work at different speeds.

Order events → topicBilling subscriptionShipping subscription

The topic fans out to independent billing and shipping subscriptions. Both active subscribers receive every published event; they do not share one queue.

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

How will billing and shipping differ from the two workers in Station 1? Which events will a subscriber created after the first batch receive?

Write your prediction in the worksheet before commands, hints or AI. Keep the sent and received business-ID sets as evidence.

2. Run

Terminal 2 — billing

Create the billing interest

Lab root: the folder containing mvnw.cmd (source) or RUN.md (runtime ZIP).

Terminal 1 remains the local broker. Billing and shipping use independent non-durable consumers, each with its own connection. Start the other subscriber and producer within the 60-second receive timeout; if you time out before publishing, restart both in a fresh namespace.

.\scripts\lab.cmd s03 subscribe --subscription billing --worker billing --count 3 --timeout 60000 --namespace pilot-events

Observe: READY in Terminal 2, before publishing.

Terminal 3 — shipping

Create the shipping interest

Lab root: the folder containing mvnw.cmd (source) or RUN.md (runtime ZIP).

Use the same topic namespace and a separate process. Do not publish yet.

.\scripts\lab.cmd s03 subscribe --subscription shipping --worker shipping --count 3 --timeout 60000 --namespace pilot-events

Observe: READY in Terminal 3. Both subscribers must now be ready.

Terminal 4 — producer

Publish the first three events

Lab root: the folder containing mvnw.cmd (source) or RUN.md (runtime ZIP).

Only after both subscribers show READY. Record the SEND IDs and compare them with each subscriber’s COMMIT set after both exit.

.\scripts\lab.cmd s03 produce --count 3 --namespace pilot-events

Observe: Billing receives all three business event IDs. Shipping independently receives those same three IDs. Repeated IDs across independent subscriptions are expected copies.

Terminal 2 — late subscriber

Create a late interest

Lab root: the folder containing mvnw.cmd (source) or RUN.md (runtime ZIP).

The initial billing process has exited. This new non-durable subscriber is created after the first batch. Its CLI subscription label does not register an offline durable identity.

.\scripts\lab.cmd s03 subscribe --subscription late --worker late --count 2 --timeout 60000 --namespace pilot-events

Observe: READY for late, with no replay of the earlier three events.

Terminal 4 — producer

Publish two future events

Lab root: the folder containing mvnw.cmd (source) or RUN.md (runtime ZIP).

Wait for late to show READY first. Compare its set only with this second SEND set.

.\scripts\lab.cmd s03 produce --count 2 --namespace pilot-events

Observe: Late receives exactly the two future IDs and exits. It does not receive the original three.

3. Break

Terminal 4 — producer

Publish before the next subscriber exists

Lab root: the folder containing mvnw.cmd (source) or RUN.md (runtime ZIP).

All prior bounded subscribers must have exited. Predict the result before sending. Use a fresh namespace for this controlled missing-history experiment.

.\scripts\lab.cmd s03 produce --count 2 --namespace pilot-late-break

Observe: Two SEND records. There is no active non-durable subscriber to receive them.

Terminal 2 — new subscriber

Observe missing history with a bounded wait

Lab root: the folder containing mvnw.cmd (source) or RUN.md (runtime ZIP).

Now subscribe, without sending any new events. The five-second timeout is deliberate. Do not retry indefinitely or assume a networking failure.

.\scripts\lab.cmd s03 subscribe --subscription after --worker after --count 2 --timeout 5000 --namespace pilot-late-break

Observe: READY, then TIMEOUT received=0 and exit code 2. This subscriber did not exist for the earlier sends, so the result is expected.

4. Explain

Compare the two complete first-batch ID sets with Station 1’s shared set. Where was a copy created?
Why did late receive only the second batch? Why does the CLI label not create durability?
What would need to be registered before an offline period? Keep durable subscription identity and persistent message delivery as separate properties. S04 is an optional follow-up.

Staged hints

Use one hint at a time after recording your prediction.

Hint 1

Independent interests need independent subscriptions. Two consumers on the same queue would divide one copy.

Hint 2

Create each consumer, call connection.start(), then signal READY before publishing. A new non-durable consumer has no prior history. Durable interest must be registered first with a stable identity.

Check your understanding

Choose an answer, then check it for feedback. These questions do not affect quiz exam scoring.

5. Adapt

Complete or extend BExercise.java in the private exercises module. Create a third independent interest (for example, analytics), each on its own connection, using the same topic. Start all three and confirm READY before publishing. Predict which future IDs each receives. Use a fresh exercise namespace; do not replace independent subscriptions with consumers sharing one queue. Rebuild with -Ptraining.

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.

I showed the complete first-batch set at billing and shipping.I explained the late subscriber’s two-event result and expected timeout.I added a third independent interest and predicted its future ID set.

Clean up this station

Terminals 2 and 3 — subscribers

Close remaining non-durable consumers

Lab root: the folder containing mvnw.cmd (source) or RUN.md (runtime ZIP).

The bounded subscribers should have exited. Stop any adaptation consumers still running with Ctrl+C. Keep the local broker in Terminal 1 for Station 3.

Observe: No subscriber process remains active. Non-durable subscription resources disappear with their connections; there is no durable identity to unsubscribe in S03.