1 Aug 14:46
[jira] Commented: (UIMA-1130) Deployment Descriptor should allow setting the number of concurrent listeners for a reply queue
[
https://issues.apache.org/jira/browse/UIMA-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619006#action_12619006
]
Marshall Schor commented on UIMA-1130:
--------------------------------------
Good points, Adam, to consider.
Here are a couple of others (from reading our docs): are there use cases where the remote delegate would be
able to get requests from the remote broker, but possibly not be able to send it replies? (e.g., due to
firewall issues?)
Would it be possible to set the prefetch value for reply queues to be some fixed number (e.g., 1 or 10 or ... ?)
There should only ever be one listener pulling messages off of the reply queue. Is there a penalty for
setting up the prefetch value to something high?
> Deployment Descriptor should allow setting the number of concurrent listeners for a reply queue
> -----------------------------------------------------------------------------------------------
>
> Key: UIMA-1130
> URL: https://issues.apache.org/jira/browse/UIMA-1130
> Project: UIMA
> Issue Type: Improvement
> Components: Async Scaleout
> Affects Versions: 2.2.2
> Reporter: Adam Lally
>
> The Spring XML allows setting a concurrentConsumers property for a reply queue (either an aggregate's
(Continue reading)
...
>>>The capability to add listeners for a remote reply queue should give equal or better performance than
setting a prefetch value in most cases. Can we see if a single tuning parameter is enough before adding more
complexity? Note that prefetch is not part of the JMS standard and is not available in all JMS
implementations.
+1 to avoiding more tweaking/tuning parameters whenever possible, in favor of something that just always
works well.
>>>> are there use cases where the remote delegate would be able to get requests from the remote broker, but
possibly not be able to send it replies? (e.g., due to firewall issues?)
>>>Yes, when the client is behind a firewall, but the remote delegate [service] and it's broker are outside
the firewall. This is one of the motivations for always allocating the reply queue on the service's broker
(the other main one being to eliminate the need for a colocated broker to instantiate a local reply queue,
again something not possible with many JMS implementations).
Well, I meant the other way 'round. So let me try again - are there use cases where the remote broker serves the
remote delegate new work OK, but for some reason can't host the reply queue?
>>>>>There should only ever be one listener pulling messages off of the reply queue.
>>>It is sometimes desirable to have more than one thread doing deserialization of reply messages, which
RSS Feed