[
https://issues.apache.org/jira/browse/UIMA-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619008#action_12619008
]
Eddie Epstein commented on UIMA-1130:
-------------------------------------
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.
>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).
>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 is the original point of this issue.
>Is there a penalty for setting up the prefetch value to something high?
The main problem for UIMA is memory management, as serialized XmiCas messages
can be quite large.
> 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 collocated reply queue or a remote reply queue):
> <property name="concurrentConsumers" value="1"/>
> The deployment descriptor should allow setting this property. In some
> deployments where remote delegates are scaled out many times, the bottleneck
> can become the aggregate deserializing CASes from the reply queue. If the
> aggregate is running on a multicore machine it helps to increase the number
> of threads that can process the reply queue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
