Currently, in the base aggregate descriptor, you can add the same
delegate to an aggregate multiple times, as long as each one has a
unique key. The Component Descriptor Editor supports this.
Therefore, it seems that the deployment descriptor should handle
this case.
This is *not* the case where the same delegate key is put in twice in
some flow specification. Note that a custom flow controller *could*
re-route a CAS through the same key-specific delegate, multiple times -
however this would be quite unusual, and would make (error and other)
reporting which distinguishes delegates by their (unique) key names more
ambiguous - this should be discouraged, I think.
-Marshall
Burn Lewis (JIRA) wrote:
[ https://issues.apache.org/jira/browse/UIMA-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617672#action_12617672 ]
Burn Lewis commented on UIMA-1124:
----------------------------------
The example I was thinking of was only one service but invoked twice in the flow. Presumably we can do that now by putting the delegate key twice in the flow constraints. This may be weird but not something we should or could prevent, especially since the user can provide a custom flow controller.
But a user might try to achieve this by overriding 2 delegate keys with the same
broker & queue ... should we support this or call it a mis-configuration? It is
somewhat analogous to associating the same annotator with 2 different delegate keys
in core UIMA, which I don't think is treated as a mis-configuration.
If 2 delegates use the same queue name getMeta will time out on one of them
---------------------------------------------------------------------------
Key: UIMA-1124
URL: https://issues.apache.org/jira/browse/UIMA-1124
Project: UIMA
Issue Type: Bug
Components: Async Scaleout
Reporter: Burn Lewis
Fix For: 2.2.2AS
It should be possible (if unusual) to send a CAS to the same queue from
different stages in its flow. Or at least to a queue with the same name on a
different broker. Alternatively if we insist that aggregates must have unique
queue names then we should enforce it. The problem may be related to the fact
that most log messages refer to queue names instead of delegate keys, e.g. when
key UMA_TL uses queue TopicLabellerAnnotatorQueue we get:
UMA_TL Remote Service Registered Successfully
Merging Typesystem From Delegate: TopicLabellerAnnotatorQueue
