[
https://issues.apache.org/jira/browse/NIFI-4834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17018943#comment-17018943
]
ASF subversion and git services commented on NIFI-4834:
-------------------------------------------------------
Commit c1301e196c5be89819e702ec76912f3c426f3055 in nifi's branch
refs/heads/master from Gardella Juan Pablo
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=c1301e1 ]
NIFI-6915 This closes #3961. Jms Durable non shared subscription is broken
Revert NIFI-4834 enhancement for durable non shared consumers only.
Updated also AbstractJMSProcessor class to be public. The testing are not
working
without that change, as org.apache.nifi.jms.processors.PublishJMSIT and
org.apache.nifi.jms.processors.ConsumeJMSIT are not working, as @OnSchedule
method is not called (because it is not public).
The method org.apache.nifi.util.StandardProcessorTestRunner.run(int iterations,
boolean stopOnFinish, boolean initialize, long runWait) uses
ReflectionUtils.invokeMethodsWithAnnotation which does not call non public
methods.
Signed-off-by: Joe Witt <[email protected]>
> ConsumeJMS does not scale when given more than 1 thread
> -------------------------------------------------------
>
> Key: NIFI-4834
> URL: https://issues.apache.org/jira/browse/NIFI-4834
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
> Reporter: Mark Payne
> Assignee: Mark Payne
> Priority: Major
> Fix For: 1.6.0
>
>
> When I run ConsumeJMS against a local broker, the performance is great.
> However, if I run against a broker that is running remotely with a 75 ms
> round trip time (i.e., somewhat high latency), then the performance is pretty
> poor, allowing me to receive only about 30-40 msgs/sec (1-2 MB/sec).
> Increasing the number of threads should result in multiple connections to the
> JMS Broker, which would provide better throughput. However, when I increase
> the number of Concurrent Tasks to 10, I see 10 consumers but only a single
> connection being created, so the throughput is no better (in fact it's a bit
> slower due to added lock contention).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
