[
https://issues.apache.org/jira/browse/CAMEL-17540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480735#comment-17480735
]
Ashutosh Vaish commented on CAMEL-17540:
----------------------------------------
[~davsclaus] I would really appreciate if you could help here, we are in a big
dilemma to continue using camel in-out pattern for our use case. As much I want
to use camel this could be a deal breaker :(. We are actually connecting to
mainframe IBM MQ and DefaultMessageListenerContainer polls the queue manager
every second and causes high mainframe CPU usage (upto 100%). If I set the
receiveTimeout greater than 1000L I do not get response fast, since the message
sits in the queue until the next poll. Attaching some other forums threads
explaining the same issue
[https://community.ibm.com/community/user/integration/viewdocument/top-tip-when-using-ibm-mq-and-the-s?CommunityKey=b382f2ab-42f1-4932-aa8b-8786ca722d55]
[https://stackoverflow.com/questions/14384038/spring-mdp-polling-interval]
> CamelJms Request Reply QueueReplyManager is coupled with
> DefaultMessageListenerContainer
> ----------------------------------------------------------------------------------------
>
> Key: CAMEL-17540
> URL: https://issues.apache.org/jira/browse/CAMEL-17540
> Project: Camel
> Issue Type: Improvement
> Components: camel-jms
> Affects Versions: 3.x
> Reporter: Ashutosh Vaish
> Priority: Minor
>
> We are using CamelJMS to connect with IBM MQ. We are doing request-reply over
> JMS. It was identified that our camel app is continuously polling the reply
> queues even when a unit of work was completed. I found that QueueReplyManager
> is coupled with DefaultMessageListenerContainer.
> CamelJMS allows consumerType for JMS consumer to be Simple/Default/Custom.
> Why was it decided to use DefaultMessageListenerContainer for
> QueueReplyManager? Can we give a consumerType choice for this pattern too ?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
