Non-durable subscriptions are the lightweight, session-scoped cousin of durable IBM MQ pub/sub. They exist while the subscribing application maintains its connection (or for administrative definitions explicitly marked DURSUB(NO)), and they disappear when that session ends—taking with them the queue manager’s obligation to deliver future publications to that registration. That is ideal when you only care about live data: a trading blotter showing current prices, a monitoring tile updating every second, or a browser session listening for notifications. It is wrong when payroll must process every HR event published over the weekend. Beginners sometimes enable non-durable JMS subscribers by default and wonder why Monday’s batch found no messages. This tutorial contrasts DURSUB(NO) with YES, explains dynamic subscription APIs, covers message loss semantics precisely, documents when non-durable plus non-persistent is appropriate, and gives operations checks to find accidental non-durable use in production.
Application starts, registers interest in retail/price/# with DURSUB(NO) or equivalent API flag. Publications match and copy to DEST while connected. Application stops or crashes—TCP and MQDISC tear down the session. Queue manager removes the non-durable subscription record. New publications no longer create copies for that registration. Another application instance must create a new subscription; there is no backlog unless you also used a durable sub on a different DEST by mistake.
| Aspect | Non-durable | Durable |
|---|---|---|
| After disconnect | Subscription removed (typical) | Subscription kept |
| Missed while offline | Lost for that sub | Queued on DEST |
| Repository ADMIN sub | Rare in prod | Common pattern |
| Resource use | Lower long-term | DEST may grow |
| Use case | Live-only consumers | Guaranteed catch-up |
DEFINE SUB('SUB.LIVE.TICKER') DURSUB(NO) TOPICSTR('market/price/#') DEST('LIVE.TICKER.Q') SUBTYPE(ADMIN) is valid for a permanently defined registration that is still non-durable in the IBM sense of subscription durability flags—read IBM docs carefully because SUBTYPE(ADMIN) permanence differs from DURSUB semantics. Most teams use ADMIN with DURSUB(YES) for server consumers and reserve NO for deliberate ephemeral patterns. Mislabeling a production audit sub as DURSUB(NO) is a severity-1 configuration defect.
123DEFINE SUB('SUB.LIVE.ONLY') TOPICSTR('telemetry/cpu/#') + DEST('TELEMETRY.LIVE.Q') DURSUB(NO) SUBTYPE(ADMIN) * Consumer must stay connected; stop amqsget — publish — no buildup after disconnect
Session.createConsumer(topic) without durable subscriber APIs creates non-durable interest. Every microservice replica may create its own non-durable sub at startup—fine for competing consumers on one DEST if designed, wasteful if each replica should share one durable backlog. Standardize patterns in your enterprise coding guidelines: durable for commands and audit; non-durable for metrics streams.
Non-durable plus non-persistent publish is the fastest, least reliable path—messages may vanish on restart even while connected. Use only for discardable telemetry. Any compliance tag on the data disqualifies this combination without explicit risk acceptance.
Non-durable is like a walkie-talkie channel while you hold the button—you only hear what is said when you are listening. Hang up and you miss everything until you tune in again with a new session.
You only hear the teacher when you are in the classroom. If you go home, nobody saves the announcements for you—you have to be there to hear them.
Pick durable or non-durable: fraud alert engine, live CPU chart, monthly statement batch.
Consumer disconnects 10 minutes—explain message fate for each durability choice.
Write a code review checklist item for JMS pub/sub durability.
1. Non-durable sub when app disconnects:
2. Best for live ticker UI:
3. DURSUB(NO) in MQSC means:
4. Publications while sub inactive: