[
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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
