shashank created CAMEL-26082:
--------------------------------
Summary: camel-sjms - preserveMessageQos=true has no effect for
InOnly sends (JMSPriority, JMSDeliveryMode and JMSExpiration headers ignored)
Key: CAMEL-26082
URL: https://issues.apache.org/jira/browse/CAMEL-26082
Project: Camel
Issue Type: Bug
Components: camel-sjms
Reporter: shashank
Assignee: shashank
{{SjmsEndpoint.createInOnlyTemplate}} never calls
{{template.setPreserveMessageQos(...)}}; only {{createInOutTemplate}} does,
since CAMEL-17912 added the option (main 6a2f66ddec3e). So with
{{preserveMessageQos=true}} an InOnly send takes the plain
{{producer.send(message)}} branch of {{SjmsTemplate.send}}: the binding sets
{{JMSPriority}}, {{JMSDeliveryMode}} and {{JMSExpiration}} on the JMS message,
but {{MessageProducer.send(Message)}} overrides them with the producer defaults
(or the endpoint QoS with {{explicitQosEnabled}}). The documented option ("send
message using the QoS settings specified on the message") does nothing for
InOnly: a message whose {{JMSExpiration}} is in the past is delivered and
processed, {{JMSPriority}} is ignored (Artemis receives 4 instead of 8), and a
NON_PERSISTENT message is sent persistent. camel-jms and camel-amqp pass the
option to both templates and honour the headers (same scenario against all
three with an embedded Artemis broker). The same InOnly template sends the
replies of a consumer endpoint.
*Fix*: {{createInOnlyTemplate}} passes {{preserveMessageQos}} to the template.
In the {{preserveMessageQos}} branch of {{SjmsTemplate.send}}, a message
without {{JMSExpiration}} gets the time to live of the endpoint
({{timeToLive}}, or {{requestTimeout}} for request/reply), as CAMEL-25724 did
for camel-jms; without it, InOnly endpoints that set both {{timeToLive}} and
{{preserveMessageQos}} would lose their time to live. Without a {{JMSPriority}}
or {{JMSDeliveryMode}} header the branch now uses the {{priority}} and
{{deliveryPersistent}}/{{deliveryMode}} of the endpoint, as the option
description says, instead of the values of the new JMS message (the binding
always sets PERSISTENT; the priority is the client default, 4 with Artemis, 0
with the ActiveMQ Classic client), which would have sent the messages of an
endpoint with {{deliveryPersistent=false}}/{{priority=7}} persistent with
priority 4 or 0. {{SjmsTemplate.send}} gets the Camel message to tell whether
the route set the header. camel-sjms2 inherits the change. Upgrade guide entry
(the headers now apply to InOnly sends and replies; a header that is not set
falls back to the endpoint, also for request/reply; a request without
{{JMSExpiration}} now expires after {{requestTimeout}}).
*Tests*: new {{InOnlyPreserveMessageQosTest}} (embedded Artemis), 9 tests; 7
fail on main, for example {{header(JMSPriority) == 8 evaluated as: 4 == 8}},
{{Expected: <Fresh> but was: <Stale>}} and, for the reply of a consumer,
{{expected: <9> but was: <4>}}; the two controls (endpoint {{timeToLive}};
endpoint priority and delivery mode without headers) pass on main and fail with
only the template line or without the fallback. Unit tests with the fix:
camel-sjms 148 run, 0 failures, 5 skipped; camel-sjms2 23 run, 0 failures.
*Not changed*: camel-jms has the same gap in its {{preserveMessageQos}} branch
(without a {{JMSDeliveryMode}}/{{JMSPriority}} header it uses the values of the
JMS message, priority 0 for a new message with the ActiveMQ Classic client).
Separate follow-up.
*How it was found*: differential testing of camel-jms, camel-sjms and
camel-amqp with the same inputs.
*Affected*: main, camel-4.22.x, camel-4.18.x and camel-4.14.x (same method).
Read, not run.
_Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
