Missing feature Delivery Delay (#1717) causes messaginghub/pooled-jms library to fail with ActiveMQ 6.3.0

[graben]

ActiveMQ 6.3.0 specified itself as 3.1 compliant but it isn't, yet! Thats causing Exceptions at least with messaginghub/pooled-jms.

java.lang.UnsupportedOperationException: getDeliveryDelay() is not supported
	at org.apache.activemq.ActiveMQMessageProducerSupport.getDeliveryDelay(ActiveMQMessageProducerSupport.java:71) ~[activemq-client-6.3.0.jar:6.3.0]
	at org.messaginghub.pooled.jms.JmsPoolMessageProducer.<init>(JmsPoolMessageProducer.java:64) ~[pooled-jms-3.2.2.jar:?]
	at org.messaginghub.pooled.jms.pool.PooledSessionHolder.getOrCreateProducer(PooledSessionHolder.java:187) ~[pooled-jms-3.2.2.jar:?]
	at org.messaginghub.pooled.jms.JmsPoolSession.createProducer(JmsPoolSession.java:454) ~[pooled-jms-3.2.2.jar:?]
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) ~[?:?]
	at java.base/java.lang.reflect.Method.invoke(Method.java:565) ~[?:?]

[jbonofre]

@graben if you take a look on https://activemq.apache.org/components/classic/documentation/jms2 you can see that we clearly say that ActiveMQ 6.3.0 is not fully 3.1 compliant (still a work in progress).
The full 3.1 supports is planned for 6.5.0.

DeliveryDelay and receiveBody are already a work in progress.

[graben]

Well, but the truth is in the code ActiveMQConnectionMetaData.java. This should not have been updated until really 3.1 compliant IMHO.

[mattrpav]

@graben the path to full Jakarta 3.1 is within view. The 6.3.0 release was critical as it unblocks a large dependency set (Jetty and Spring).

My Shared Topic Subscription patch includes the OpenWire protocol changes to support deliveryDelay and the project is going forward with a branch strategy to wrap up Jakarta 3.1 features. That set of changes takes us to ~91% TCK compliance and with async/CompletionListener and receiveBody are the majority of the gaps.

ref: #2229

As far as the ConnectionMetaData info goes, it was a choice to unblock other use cases that are able to move forward with the partial support approach.

[graben]

@mattrpav, I understand your point but not working with pooled-jms will be blocker for a big ecosystem like Spring Boot for example to migrate to 6.3.x until this is solved. That's why it is important to keep a 6.2.x maintained until 6.3 is mature. I know that several librarys in 6.2 are quite old and unmaintained for non enterprise users (Spring Framework 6.2). But it's better to have this version still getting partly supported than having nothing working at all. :-)

[mattrpav]

@graben what is the nature of the 'breakage'? Is it preventing all usage of the pooled-jms, even when deliveryDelay is not in use?

Spring Boot apps are able to continue to use activemq-pool and activemq-pool-jms using the JMS 1.1 operations (non-JMSContext) without any problem.

[graben]

Well, at least producing messages isn't working any more. Consumer seems not affected.

[mattrpav]

@graben ALL sends are broken or only ones that specify a deliveryDelay?

If it is all sends, that sounds like a bug in the messagehub pool. I don't see why one would always set deliveryDelay if its not in use.

If it is only ones that use deliveryDelay, there is an easy temporary work around to write a wrapper stub that maps the deliveryDelay to the ActiveMQ Scheduled Message property.

[PaulGale]

Note: this comment was generated by Claude Code after troubleshooting this issue.

Additional diagnosis: the regression is the advertised JMS version, not the missing feature

I hit this independently and dug into why it appears only in 6.3.0.

Short version: delivery delay was never implemented, in 6.2.x either.

What changed in 6.3.0 is what ActiveMQ claims about itself, and pooled-jms is behaving correctly in response to that claim. That means this can be fixed without implementing #1717 at all.

getDeliveryDelay() is byte-for-byte identical in 6.2.8 and 6.3.0

A full javap -c diff of ActiveMQMessageProducerSupport between activemq-client 6.2.8 and 6.3.0 shows no differences whatsoever. Both throw:

public long getDeliveryDelay() throws jakarta.jms.JMSException;
   0: new           #33   // class java/lang/UnsupportedOperationException
   4: ldc           #40   // String getDeliveryDelay() is not supported
   6: invokespecial #37   // UnsupportedOperationException."<init>":(String)V
   9: athrow

So the method is not the variable. Bisecting activemq-client against an otherwise fixed dependency set:

activemq-client	Result
6.2.6	passes
6.2.8	passes
6.3.0	fails on the first send

What actually changed: ActiveMQConnectionMetaData

	getJMSVersion()	getJMSMajorVersion()
6.2.8	"1.1"	1
6.3.0	"3.1"	3

Introduced by commit 6871226ff1 — "feat(tck): Add Jakarta Messaging 3.1 TCK with some fixes" (PR #1712, sub-PR #1718). Its stated rationale:

ActiveMQ reports JMS version as 1.1 (JMS 1.1 era). Since the project now uses jakarta.jms
(Jakarta Messaging 3.1), the metadata must match.

Respectfully, this conflates two different things: the API artifact namespace
(javax.jms → jakarta.jms) and the specification level implemented. Compiling against the jakarta.jms 3.1 API says nothing about implementing JMS 2.0 semantics — and ConnectionMetaData is not documentation, it is a capability-negotiation API that libraries branch on at runtime.

Why that breaks pooled-jms specifically

JmsPoolMessageProducer's constructor snapshots producer defaults, but guards the JMS 2.0 getters behind the provider's own claim:

101: iconst_2                                   // major = 2
102: iconst_0                                   // minor = 0
103: invokevirtual isJMSVersionSupported:(II)Z  // does the provider support JMS 2.0?
106: ifeq          119                          // NO  -> skip, return
109: getDeliveryDelay()                         // YES -> call it
119: return

isJMSVersionSupported resolves from connection.getMetaData(). So:

• Against 6.2.8: provider answers major = 1, 1 >= 2 is false, the call is never made.
• Against 6.3.0: provider answers major = 3, 3 >= 2 is true, the call is made and throws.

pooled-jms is doing exactly the right thing — asking before calling an optional API. The regression is that ActiveMQ now answers "yes" to a question it cannot honour.

For contrast, TIBCO EMS advertises JMS 3.0 and implements deliveryDelay, so the identical pooled-jms code path works there. Two ways to be safe: implement it, or don't claim it. 6.3.0 does neither.

Two things that make this worse in practice

The secondary symptom is badly misleading. Because producer creation fails, pooled sessions are never returned to the pool, so after a short while the visible error becomes java.util.NoSuchElementException: Pool exhausted. Anyone debugging from that symptom will be looking at pool sizing, not at JMS capability metadata. It cost me a while.

UnsupportedOperationException is unchecked, while the JMS interface declares these methods throws JMSException. Client code written to the interface contract cannot catch it, so it propagates as a raw runtime failure through pooling, JmsTemplate and framework error handling alike.

Scope note: because pooled-jms is managed by spring-boot-dependencies, this reaches ordinary Spring Boot + ActiveMQ applications with JMS pooling enabled. It reproduces with no application code referencing delivery delay anywhere — pooled-jms calls it on its own initiative.

The claim is also contradicted inside this repository

• activemq-unit-tests/.../jms2/ActiveMQJMS2ContextTest.java (lines 282–314) asserts that
  get/setDeliveryDelay, createSharedConsumer, createSharedDurableConsumer and async send
  with a CompletionListener all throw UnsupportedOperationException.
• The Classic documentation describes support as "Partial Jakarta Messaging 3.1", and states clients "will not support all JMS 2.0 functionality and will throw an UnsupportedOperationException … such as those for async send with a CompletionListener, sending messages with a delivery delay, and using shared topic consumers."
• On that page AMQ-8320 (Delivery Delay), targeted at 6.3.0, is still open — so 6.3.0 shipped the claim while the implementation it was targeted alongside did not land.

Worth noting the TCK module added in 6871226ff1 runs only behind an opt-in -Prun-tck profile and is not part of the default build, so the 3.1 claim is not continuously verified. Its exclusion list (ts.jtx) contains a single entry, attributed to a TCK bug — nothing acknowledging delivery delay or shared consumers. I could not run the TCK myself, so I am inferring rather than asserting that these were never exercised.

The claim covers more than delivery delay

Eight methods still throw on main, all now advertised as supported:

• getDeliveryDelay, setDeliveryDelay — in both ActiveMQMessageProducerSupport
  (lines 58–71) and ActiveMQProducer (lines 248–254, the JMS 2.0 simplified JMSProducer API)
• createSharedConsumer ×2, createSharedDurableConsumer ×2, createSharedConnectionConsumer, createSharedDurableConnectionConsumer — AMQ-8323

Delivery delay is simply the first one a library happened to probe. The shared-consumer methods are armed behind the same claim and will surface the same way for any consumer that gates on advertised version.

Suggested resolutions

Listed cheapest first. Any one resolves the regression; none requires implementing #1717.

1. Degrade delivery delay to its documented default instead of throwing. JMS defines the default delivery delay as 0, meaning "no delay", so a provider that only supports immediate delivery can report 0 truthfully. Concretely: have getDeliveryDelay() return the stored value (default 0); accept setDeliveryDelay(0) as a no-op; and continue to throw only for a non-zero delay, so a delay a caller genuinely requested is never silently dropped. This unblocks every capability-probing consumer while keeping the honest failure where it matters. It needs the same treatment in ActiveMQProducer for the simplified API, and two existing assertions in ActiveMQJMS2ContextTest would need updating to match.

2. Narrow the advertised capability until AMQ-8320 / AMQ-8323 land — i.e. report the level actually implemented. Lowest risk and it restores 6.2.x behaviour exactly, but it puts ActiveMQ back to advertising JMS 1.1 while shipping the jakarta.jms 3.1 API, which is what motivated #1718 in the first place.

3. Complete AMQ-8320 and AMQ-8323 before advertising 3.1. Correct, but by far the largest piece of work, and unnecessary to unblock affected users now.

My own preference is (1), because it is small, spec-defensible, keeps the 3.1 claim that #1718 wanted, and fixes the whole class of capability-probing consumers rather than just pooled-jms.

I'm happy to open a PR with a failing test plus the fix for whichever direction you prefer — I didn't want to send code before there was agreement on the approach.

Reproducer

No application code touches delivery delay:

1. Wrap an ActiveMQConnectionFactory in a pooled-jms JmsPoolConnectionFactory.
2. Send any message through it (directly, or via Spring's JmsTemplate).
3. With activemq-client 6.2.8 the send succeeds. With 6.3.0 it throws
   UnsupportedOperationException: getDeliveryDelay() is not supported at producer construction,
   and every subsequent send fails until the pool reports exhaustion.

One suggestion for pooled-jms (separate project)

Independently of the above, JmsPoolMessageProducer could treat these optional getters defensively — catch UnsupportedOperationException and fall back to 0 rather than letting producer creation fail. That would harden it against any provider that advertises a JMS level without implementing every optional API. Happy to raise that upstream if useful.

[PaulGale]

@mattrpav — direct answer to your question: ALL sends are broken, not only ones that specify a delivery delay.

The key detail is that nothing sets deliveryDelay. Neither application code nor pooled-jms does. pooled-jms reads it, once per producer construction, to snapshot the producer's default state so it can be restored when that pooled producer is handed to the next borrower. That is ordinary pooling hygiene rather than delivery-delay usage.

Crucially, pooled-jms does not call the JMS 2.0 getter blindly. It guards the call behind the provider's own capability answer, in JmsPoolMessageProducer.<init>:

101: iconst_2                                   // major = 2                                                                                                                                                                                                                   
102: iconst_0                                   // minor = 0                                                                                                                                                                                                                   
103: invokevirtual isJMSVersionSupported:(II)Z  // does the provider support JMS 2.0?                                                                                                                                                                                          
106: ifeq          119                          // NO  -> skip, return                                                                                                                                                                                                         
109: getDeliveryDelay()                         // YES -> call it                                                                                                                                                                                                              
119: return                                                                                                                                                                                                                                                                    

isJMSVersionSupported resolves from connection.getMetaData(). So against 6.2.8 the provider answers major=1, the guard is false, and the call never happens. Against 6.3.0 it answers major=3, the guard passes, getDeliveryDelay() throws, and every producer creation fails. So I would put this slightly differently than "a bug in the messaginghub pool": pooled-jms asks before calling an optional API, which is the right thing to do. What changed is the answer it gets.

That said, I do agree pooled-jms should be more defensive here. Calling an optional JMS 2.0 accessor from a constructor without catching UnsupportedOperationException is fragile regardless of what any provider advertises, and I am happy to raise that with them in parallel. I suspect the ideal outcome is a change in both projects.

Two corrections on the suggested workarounds, both of which I think matter for prioritisation:

• This is already the JMS 1.1 path. The failing frame is ActiveMQMessageProducerSupport, the classic MessageProducer base class, reached via JmsPoolSession.createProducer from JmsTemplate.doCreateProducer. The JMSContext/JMSProducer implementation is a separate class (ActiveMQProducer). Avoiding JMSContext and staying on JMS 1.1 operations therefore does not avoid this.

• activemq-pool is not a Spring Boot fallback. spring-boot-dependencies manages org.messaginghub:pooled-jms and only that. Neither activemq-pool nor activemq-jms-pool is managed by Boot, and neither is the auto-configured pooling path. They can still be wired manually, but there is no supported Spring Boot configuration that routes around this.

On sequencing, one detail from your own description of #2229 seems decisive: the delivery delay support there depends on OpenWire protocol changes (v13). A wire-protocol bump cannot ship in a 6.3.x patch release, and #2229 is currently WIP against
activemq-wip-jakarta-3.1 with full 3.1 targeted at 6.5.0. So "wait for the real implementation" and "unbreak 6.3.x users" are not the same timeline.

That is really why I think a small interim change is worth considering for 6.3.1, independent of #2229: have getDeliveryDelay() return 0 (the JMS default, meaning no delay, which a provider supporting only immediate delivery can report truthfully), accept
setDeliveryDelay(0) as a no-op, and continue to throw for a non-zero delay so a genuinely requested delay is never silently dropped. That needs no protocol change, keeps the 3.1 metadata claim that #1718 wanted, and fixes the whole class of capability-probing consumers rather than pooled-jms alone.

Fully understood that the 6.3.0 metadata change was a deliberate call to unblock the Jetty and Spring dependency set. That unblocking is genuinely valuable, and it is the reason I wanted 6.3.0 as well. The narrower point I would make is that ConnectionMetaData is consumed programmatically at runtime, so a caveat documented on the website cannot reach a library that asks the provider directly. Happy to open a PR for whichever direction you prefer.

[mattrpav]

PR pending: [#2272]