CAMEL-24619: Default to Simple consumer type for topic endpoints - #26107
CAMEL-24619: Default to Simple consumer type for topic endpoints#26107gnodet wants to merge 2 commits into
Conversation
When consuming from a JMS topic (pubSubDomain=true) and the user has not explicitly set a consumerType, the consumer type is now automatically set to Simple instead of Default. The Default consumer type uses DefaultMessageListenerContainer which repeatedly calls session.createConsumer() on each poll cycle. On some brokers (e.g. Artemis), this creates a new non-durable queue for each call that accumulates until the connection is closed, causing OOM on the broker. The Simple consumer type uses SimpleMessageListenerContainer which creates a single persistent consumer, avoiding this issue. Users can still explicitly set consumerType=Default on topic endpoints if they need the polling behavior.
3c86f53 to
780e07a
Compare
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 🐫 Apache Camel Committers, please review the following items:
|
✅ Generated files are up to dateAn earlier CI run reported uncommitted generated changes; the latest run no longer does. |
davsclaus
left a comment
davsclaus
left a comment
There was a problem hiding this comment.
Hmm have you reported this to ActiveMQ Artemis instead, it feels like its more a problem on their side than Spring JMS or Camel.
I dont think we should add "hacks" in Camel for this with a component that has been like this for 15+ years and Spring JMS is widely in use as well, and its default behaviour there also.
|
🧪 CI tested the following changed modules:
🔬 Scalpel shadow comparison — Scalpel: 15 tested, 24 compile-only — current: 12 all testedMaveniverse Scalpel detected 39 affected modules (current approach: 12).
|
|
Closing this PR — after investigation with Torsten Mielke and the reporter on CAMEL-24619, the root cause is a misconfigured Artemis broker (missing With the default No change needed in Camel. |
2 participants
Summary
When consuming from a JMS topic (
pubSubDomain=true) and the user has not explicitly set aconsumerType, the consumer type is now automatically set toSimpleinstead ofDefault.Problem
The
Defaultconsumer type uses Spring'sDefaultMessageListenerContainerwhich repeatedly callssession.createConsumer()on each poll cycle. On some brokers (e.g. Apache Artemis), this creates a new non-durable queue for each call on multicast addresses (topics). These queues accumulate until the connection is closed, causing OutOfMemoryError on the broker.The workaround was to explicitly set
consumerType=Simplein the URI, but the default behavior was dangerous for topic consumers.Fix
JmsConfiguration.createMessageListenerContainer(), when the endpoint is a topic andconsumerTypewas not explicitly set by the user, automatically useSimpleinstead ofDefaultconsumerTypewas explicitly set via aconsumerTypeExplicitlySetflagconsumerType=Defaulton topic endpoints if they need the polling behavior@UriParamdescription to document this topic-aware defaultingChanges
JmsConfiguration.java: AddedconsumerTypeExplicitlySettracking flag, topic-aware logic increateMessageListenerContainer(), updated descriptionJmsEndpointConfigurationTest.java: UpdatedtestCacheConsumerEnabledForTopicto reflect new behavior, added 4 new tests:testTopicConsumerDefaultsToSimple- topic with no explicit type → SimpletestQueueConsumerStillDefaultsToDefault- queue unchanged → DefaulttestTopicConsumerExplicitDefault- topic with explicit Default → Default (respected)testTopicConsumerExplicitSimple- topic with explicit Simple → SimpleBackward Compatibility
Defaultconsumer typeSimple(behavioral change, but fixes a bug that caused OOM)consumerType=Default: Unchanged — explicit user setting is respectedFixes: https://issues.apache.org/jira/browse/CAMEL-24619