You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Tong Fin (JIRA)" <ui...@incubator.apache.org> on 2008/08/19 21:45:44 UTC
[jira] Created: (UIMA-1146) Setting the number of concurrent
listeners off a reply queue for Co-located Delegates
Setting the number of concurrent listeners off a reply queue for Co-located Delegates
-------------------------------------------------------------------------------------
Key: UIMA-1146
URL: https://issues.apache.org/jira/browse/UIMA-1146
Project: UIMA
Issue Type: Improvement
Components: Async Scaleout
Affects Versions: 2.2.2AS
Reporter: Tong Fin
Assignee: Tong Fin
JIRA-1130 has improved UIMA-AS to allow users to set the number of concurrent listeners of a reply queue for each "remote" delegate. The following is the syntax in the xml deployment descriptor (as an example):
<analysisEngine async="true">
<delegates>
<remoteAnalysisEngine key="RoomNumber">
<inputQueue brokerURL="tcp://localhost:61616" endpoint="RoomNumberAnnotatorQueue"/>
<replyQueue concurrentConsumers="2" location="remote"/>
...
</remoteAnalysisEngine>
</delegates>
...
</analysisEngine>
This JIRA will do the similar thing by allowing users to set the number of concurrent listeners of a reply queue for "co-located" delegates inside the UIMA-AS aggregate.
The following is the "proposed" syntax:
<analysisEngine async="true"> <!-- Top aggregate -->
<replyQueue concurrentConsumers="2">
...
<delegates>
<analysisEngine key="NamesAndPersonTitlesTAE" async="true"> <!-- co-located aggregate -->
<replyQueue concurrentConsumers="3">
...
</analysisEngine>
...
</delegates>
...
</analysisEngine>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Updated: (UIMA-1146) Setting the number of concurrent
listeners of a reply queue for Co-located Delegates
Posted by Marshall Schor <ms...@schor.com>.
No grant is needed, I think - you're not donating the screen shot :-).
-Marshall
Tong Fin wrote:
> When I try to attach the screen-shot, I cannot find the place to "grant" the
> licence.
> I may miss something.
>
> -- Tong
>
>
Re: [jira] Updated: (UIMA-1146) Setting the number of concurrent listeners of a reply queue for Co-located Delegates
Posted by Tong Fin <to...@gmail.com>.
When I try to attach the screen-shot, I cannot find the place to "grant" the
licence.
I may miss something.
-- Tong
Re: [jira] Commented: (UIMA-1146) Setting the number of concurrent
listeners of a reply queue for Co-located Delegates
Posted by Marshall Schor <ms...@schor.com>.
Thilo Goetz wrote:
> Marshall Schor wrote:
>
>> Thilo Goetz wrote:
>>
>>> I don't know about you guys, but my mail program
>>> doesn't handle wiki syntax. If we allow wiki
>>> syntax in Jira, can we make it spit out html
>>> mail instead of unformatted wiki syntax?
>>>
>> Apparantly yes. See
>> http://www.atlassian.com/software/jira/docs/v3.12/configurerenderers.html
>> and scroll down to Email Notifications.
>>
>
> Yes, I found that. You can enable this on an individual
> level, which I did for test purposes. I still don't get
> html mail, don't know why.
>
> So anyway, wdyt? I'd say either wiki + html mail, or
> plain text in both.
>
+1 for wiki + html mail, for me. -Marshall
> --Thilo
>
>
>
>
Re: [jira] Commented: (UIMA-1146) Setting the number of concurrent
listeners of a reply queue for Co-located Delegates
Posted by Thilo Goetz <tw...@gmx.de>.
Marshall Schor wrote:
>
> Thilo Goetz wrote:
>> I don't know about you guys, but my mail program
>> doesn't handle wiki syntax. If we allow wiki
>> syntax in Jira, can we make it spit out html
>> mail instead of unformatted wiki syntax?
> Apparantly yes. See
> http://www.atlassian.com/software/jira/docs/v3.12/configurerenderers.html
> and scroll down to Email Notifications.
Yes, I found that. You can enable this on an individual
level, which I did for test purposes. I still don't get
html mail, don't know why.
So anyway, wdyt? I'd say either wiki + html mail, or
plain text in both.
--Thilo
Re: [jira] Commented: (UIMA-1146) Setting the number of concurrent
listeners of a reply queue for Co-located Delegates
Posted by Marshall Schor <ms...@schor.com>.
Thilo Goetz wrote:
> I don't know about you guys, but my mail program
> doesn't handle wiki syntax. If we allow wiki
> syntax in Jira, can we make it spit out html
> mail instead of unformatted wiki syntax?
Apparantly yes. See
http://www.atlassian.com/software/jira/docs/v3.12/configurerenderers.html
and scroll down to Email Notifications.
That page says:
Email Notifications
JIRA allows for extensive configuration in relation to email
notifications
<http://www.atlassian.com/software/jira/docs/v3.12/notification_schemes.html>.
JIRA can be send out two types of emails, HTML and text (see 'Email
Formatting
<http://www.atlassian.com/software/jira/docs/v3.12/email.html>').
HTML Emails
When using the Atlassian Wiki Renderer, the rendered content (i.e.
exactly what you see on the 'View Issue' page) will be sent out in the
emails. This will create emails which are as rich as the content makes
it. If using the Atlassian Wiki Renderer this is the preferred type of
email since it is a real representation of the wiki markup.
Text Emails
When using the Atlassian Wiki Renderer, the actual wiki markup
(unrendered) will be displayed in text emails for fields that use the
Atlassian Wiki Renderer. This is obviously less readable than the
rendered version of the markup, but because the markup's syntax is quite
simple the text does remain easy to read.
> Any
> drawbacks to that?
>
Not sure - I've seen in other posts that spam filters sometimes kick in?
-Marshall
> --Thilo
>
> Eddie Epstein (JIRA) wrote:
>
>> [ https://issues.apache.org/jira/browse/UIMA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624973#action_12624973 ]
>>
>> Eddie Epstein commented on UIMA-1146:
>> -------------------------------------
>>
>> Resubmitting last comment with correct formatting marks, just in case they work here :)
>>
>> bq. I'm a little concerned that we are adding a lot of parameters that may be tricky to tune. Presumably most applications will take the default but for those that may benefit from scaleout it may be hard to determine which queue needs the extra threads.
>>
>> There are a lot of parameters which can be tuned with UIMA AS, but as you note, most applications will not need to. The real issue is to know when and how to tune them. Turns out that "when" is pretty easy to answer: is the CPU fully utilized? If not, the monitor function (see UIMA-1104) has been very successful in identifying bottlenecks in order to answer "how".
>>
>> {quote}
>> For an aggregate with N remote delegates and at least 1 co-located we'll have N+2 parameters to consider. Since these 3 types of queue consumers are all doing similar work, dispatching the CASes within the aggregate, wouldn't it be nice if we could have only 1 scaleout parameter for each aggregate.
>> <analysisEngine async="true" scaleout="n">
>> This would let users focus more on the aggregate as a dispatcher of work, and less on the subtleties of our implementation.
>> {quote}
>>
>> When used with Uima AS primitives, "scaleout" means to replicate instances of analysis components. Overloading "scaleout" to refer to replicating some threads in an aggregate will result in unnecessary confusion.
>>
>> {quote}
>> We could support this by using a Java queue for all replies (not just co-located ones as proposed elsewhere) and scale out the dispatch threads that consume this queue. The input queue and each remote queue would still have dedicated threads, but they would merely put the message on the Java queue along with the appropriate CAS, after blocking on the CasPool if necessary.
>>
>> One drawback is the extra thread switch but this may be small compared with the transport time for a remote. Another is that the extra consumers of remote queues are expected to replace the need for prefetch, but since this proposal separates the fetching from the dispatching the lightweight fetch thread may achieve the same effect as pretetch.
>> {quote}
>>
>> Individual remote reply queues still need to be scaled (see UIMA-1130), so we need exactly what Marshall has proposed above. UIMA-1140 advocates using a Java queue for colocated delegates. When that gets done we can consider if piping all replies through the java queue makes sense.
>>
>>
>>> Setting the number of concurrent listeners of a reply queue for Co-located Delegates
>>> ------------------------------------------------------------------------------------
>>>
>>> Key: UIMA-1146
>>> URL: https://issues.apache.org/jira/browse/UIMA-1146
>>> Project: UIMA
>>> Issue Type: Improvement
>>> Components: Async Scaleout
>>> Affects Versions: 2.2.2AS
>>> Reporter: Tong Fin
>>> Assignee: Tong Fin
>>>
>>> JIRA-1130 has improved UIMA-AS to allow users to set the number of concurrent listeners of a reply queue for each "remote" delegate. The following is the syntax in the xml deployment descriptor (as an example):
>>> <analysisEngine async="true">
>>> <delegates>
>>> <remoteAnalysisEngine key="RoomNumber">
>>> <inputQueue brokerURL="tcp://localhost:61616" endpoint="RoomNumberAnnotatorQueue"/>
>>> <replyQueue concurrentConsumers="2" location="remote"/>
>>> ...
>>> </remoteAnalysisEngine>
>>> </delegates>
>>> ...
>>> </analysisEngine>
>>> This JIRA will do the similar thing by allowing users to set the number of concurrent listeners of a reply queue for "co-located" delegates inside the UIMA-AS aggregate.
>>> The following is the "proposed" syntax:
>>> <analysisEngine async="true"> <!-- Top aggregate -->
>>> <replyQueue concurrentConsumers="2">
>>> ...
>>> <delegates>
>>> <analysisEngine key="NamesAndPersonTitlesTAE" async="true"> <!-- co-located aggregate -->
>>> <replyQueue concurrentConsumers="3">
>>> ...
>>> </analysisEngine>
>>> ...
>>> </delegates>
>>> ...
>>> </analysisEngine>
>>>
>
>
>
>
Re: [jira] Commented: (UIMA-1146) Setting the number of concurrent
listeners of a reply queue for Co-located Delegates
Posted by Thilo Goetz <tw...@gmx.de>.
I don't know about you guys, but my mail program
doesn't handle wiki syntax. If we allow wiki
syntax in Jira, can we make it spit out html
mail instead of unformatted wiki syntax? Any
drawbacks to that?
--Thilo
Eddie Epstein (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/UIMA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624973#action_12624973 ]
>
> Eddie Epstein commented on UIMA-1146:
> -------------------------------------
>
> Resubmitting last comment with correct formatting marks, just in case they work here :)
>
> bq. I'm a little concerned that we are adding a lot of parameters that may be tricky to tune. Presumably most applications will take the default but for those that may benefit from scaleout it may be hard to determine which queue needs the extra threads.
>
> There are a lot of parameters which can be tuned with UIMA AS, but as you note, most applications will not need to. The real issue is to know when and how to tune them. Turns out that "when" is pretty easy to answer: is the CPU fully utilized? If not, the monitor function (see UIMA-1104) has been very successful in identifying bottlenecks in order to answer "how".
>
> {quote}
> For an aggregate with N remote delegates and at least 1 co-located we'll have N+2 parameters to consider. Since these 3 types of queue consumers are all doing similar work, dispatching the CASes within the aggregate, wouldn't it be nice if we could have only 1 scaleout parameter for each aggregate.
> <analysisEngine async="true" scaleout="n">
> This would let users focus more on the aggregate as a dispatcher of work, and less on the subtleties of our implementation.
> {quote}
>
> When used with Uima AS primitives, "scaleout" means to replicate instances of analysis components. Overloading "scaleout" to refer to replicating some threads in an aggregate will result in unnecessary confusion.
>
> {quote}
> We could support this by using a Java queue for all replies (not just co-located ones as proposed elsewhere) and scale out the dispatch threads that consume this queue. The input queue and each remote queue would still have dedicated threads, but they would merely put the message on the Java queue along with the appropriate CAS, after blocking on the CasPool if necessary.
>
> One drawback is the extra thread switch but this may be small compared with the transport time for a remote. Another is that the extra consumers of remote queues are expected to replace the need for prefetch, but since this proposal separates the fetching from the dispatching the lightweight fetch thread may achieve the same effect as pretetch.
> {quote}
>
> Individual remote reply queues still need to be scaled (see UIMA-1130), so we need exactly what Marshall has proposed above. UIMA-1140 advocates using a Java queue for colocated delegates. When that gets done we can consider if piping all replies through the java queue makes sense.
>
>> Setting the number of concurrent listeners of a reply queue for Co-located Delegates
>> ------------------------------------------------------------------------------------
>>
>> Key: UIMA-1146
>> URL: https://issues.apache.org/jira/browse/UIMA-1146
>> Project: UIMA
>> Issue Type: Improvement
>> Components: Async Scaleout
>> Affects Versions: 2.2.2AS
>> Reporter: Tong Fin
>> Assignee: Tong Fin
>>
>> JIRA-1130 has improved UIMA-AS to allow users to set the number of concurrent listeners of a reply queue for each "remote" delegate. The following is the syntax in the xml deployment descriptor (as an example):
>> <analysisEngine async="true">
>> <delegates>
>> <remoteAnalysisEngine key="RoomNumber">
>> <inputQueue brokerURL="tcp://localhost:61616" endpoint="RoomNumberAnnotatorQueue"/>
>> <replyQueue concurrentConsumers="2" location="remote"/>
>> ...
>> </remoteAnalysisEngine>
>> </delegates>
>> ...
>> </analysisEngine>
>> This JIRA will do the similar thing by allowing users to set the number of concurrent listeners of a reply queue for "co-located" delegates inside the UIMA-AS aggregate.
>> The following is the "proposed" syntax:
>> <analysisEngine async="true"> <!-- Top aggregate -->
>> <replyQueue concurrentConsumers="2">
>> ...
>> <delegates>
>> <analysisEngine key="NamesAndPersonTitlesTAE" async="true"> <!-- co-located aggregate -->
>> <replyQueue concurrentConsumers="3">
>> ...
>> </analysisEngine>
>> ...
>> </delegates>
>> ...
>> </analysisEngine>
>
[jira] Commented: (UIMA-1146) Setting the number of concurrent
listeners of a reply queue for Co-located Delegates
Posted by "Eddie Epstein (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624973#action_12624973 ]
Eddie Epstein commented on UIMA-1146:
-------------------------------------
Resubmitting last comment with correct formatting marks, just in case they work here :)
bq. I'm a little concerned that we are adding a lot of parameters that may be tricky to tune. Presumably most applications will take the default but for those that may benefit from scaleout it may be hard to determine which queue needs the extra threads.
There are a lot of parameters which can be tuned with UIMA AS, but as you note, most applications will not need to. The real issue is to know when and how to tune them. Turns out that "when" is pretty easy to answer: is the CPU fully utilized? If not, the monitor function (see UIMA-1104) has been very successful in identifying bottlenecks in order to answer "how".
{quote}
For an aggregate with N remote delegates and at least 1 co-located we'll have N+2 parameters to consider. Since these 3 types of queue consumers are all doing similar work, dispatching the CASes within the aggregate, wouldn't it be nice if we could have only 1 scaleout parameter for each aggregate.
<analysisEngine async="true" scaleout="n">
This would let users focus more on the aggregate as a dispatcher of work, and less on the subtleties of our implementation.
{quote}
When used with Uima AS primitives, "scaleout" means to replicate instances of analysis components. Overloading "scaleout" to refer to replicating some threads in an aggregate will result in unnecessary confusion.
{quote}
We could support this by using a Java queue for all replies (not just co-located ones as proposed elsewhere) and scale out the dispatch threads that consume this queue. The input queue and each remote queue would still have dedicated threads, but they would merely put the message on the Java queue along with the appropriate CAS, after blocking on the CasPool if necessary.
One drawback is the extra thread switch but this may be small compared with the transport time for a remote. Another is that the extra consumers of remote queues are expected to replace the need for prefetch, but since this proposal separates the fetching from the dispatching the lightweight fetch thread may achieve the same effect as pretetch.
{quote}
Individual remote reply queues still need to be scaled (see UIMA-1130), so we need exactly what Marshall has proposed above. UIMA-1140 advocates using a Java queue for colocated delegates. When that gets done we can consider if piping all replies through the java queue makes sense.
> Setting the number of concurrent listeners of a reply queue for Co-located Delegates
> ------------------------------------------------------------------------------------
>
> Key: UIMA-1146
> URL: https://issues.apache.org/jira/browse/UIMA-1146
> Project: UIMA
> Issue Type: Improvement
> Components: Async Scaleout
> Affects Versions: 2.2.2AS
> Reporter: Tong Fin
> Assignee: Tong Fin
>
> JIRA-1130 has improved UIMA-AS to allow users to set the number of concurrent listeners of a reply queue for each "remote" delegate. The following is the syntax in the xml deployment descriptor (as an example):
> <analysisEngine async="true">
> <delegates>
> <remoteAnalysisEngine key="RoomNumber">
> <inputQueue brokerURL="tcp://localhost:61616" endpoint="RoomNumberAnnotatorQueue"/>
> <replyQueue concurrentConsumers="2" location="remote"/>
> ...
> </remoteAnalysisEngine>
> </delegates>
> ...
> </analysisEngine>
> This JIRA will do the similar thing by allowing users to set the number of concurrent listeners of a reply queue for "co-located" delegates inside the UIMA-AS aggregate.
> The following is the "proposed" syntax:
> <analysisEngine async="true"> <!-- Top aggregate -->
> <replyQueue concurrentConsumers="2">
> ...
> <delegates>
> <analysisEngine key="NamesAndPersonTitlesTAE" async="true"> <!-- co-located aggregate -->
> <replyQueue concurrentConsumers="3">
> ...
> </analysisEngine>
> ...
> </delegates>
> ...
> </analysisEngine>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1146) Setting the number of concurrent
listeners of a reply queue for Co-located Delegates
Posted by "Eddie Epstein (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624968#action_12624968 ]
Eddie Epstein commented on UIMA-1146:
-------------------------------------
.bq I'm a little concerned that we are adding a lot of parameters that may be tricky to tune. Presumably most applications will take the default but for those that may benefit from scaleout it may be hard to determine which queue needs the extra threads.
There are a lot of parameters which can be tuned with UIMA AS, but as you note, most applications will not need to. The real issue is to know when and how to tune them. Turns out that "when" is pretty easy to answer: is the CPU fully utilized? If not, the monitor function (see UIMA-1104) has been very successful in identifying bottlenecks in order to answer "how".
.bq For an aggregate with N remote delegates and at least 1 co-located we'll have N+2 parameters to consider. Since these 3 types of queue consumers are all doing similar work, dispatching the CASes within the aggregate, wouldn't it be nice if we could have only 1 scaleout parameter for each aggregate.
.bq <analysisEngine async="true" scaleout="n">
.bq This would let users focus more on the aggregate as a dispatcher of work, and less on the subtleties of our implementation.
When used with Uima AS primitives, "scaleout" means to replicate instances of analysis components. Overloading "scaleout" to refer to replicating some threads in an aggregate will result in unnecessary confusion.
.bq We could support this by using a Java queue for all replies (not just co-located ones as proposed elsewhere) and scale out the dispatch threads that consume this queue. The input queue and each remote queue would still have dedicated threads, but they would merely put the message on the Java queue along with the appropriate CAS, after blocking on the CasPool if necessary.
.bq One drawback is the extra thread switch but this may be small compared with the transport time for a remote. Another is that the extra consumers of remote queues are expected to replace the need for prefetch, but since this proposal separates the fetching from the dispatching the lightweight fetch thread may achieve the same effect as pretetch.
Individual remote reply queues still need to be scaled (see UIMA-1130), so we need exactly what Marshall has proposed above. UIMA-1140 advocates using a Java queue for colocated delegates. When that gets done we can consider if piping all replies through the java queue makes sense.
> Setting the number of concurrent listeners of a reply queue for Co-located Delegates
> ------------------------------------------------------------------------------------
>
> Key: UIMA-1146
> URL: https://issues.apache.org/jira/browse/UIMA-1146
> Project: UIMA
> Issue Type: Improvement
> Components: Async Scaleout
> Affects Versions: 2.2.2AS
> Reporter: Tong Fin
> Assignee: Tong Fin
>
> JIRA-1130 has improved UIMA-AS to allow users to set the number of concurrent listeners of a reply queue for each "remote" delegate. The following is the syntax in the xml deployment descriptor (as an example):
> <analysisEngine async="true">
> <delegates>
> <remoteAnalysisEngine key="RoomNumber">
> <inputQueue brokerURL="tcp://localhost:61616" endpoint="RoomNumberAnnotatorQueue"/>
> <replyQueue concurrentConsumers="2" location="remote"/>
> ...
> </remoteAnalysisEngine>
> </delegates>
> ...
> </analysisEngine>
> This JIRA will do the similar thing by allowing users to set the number of concurrent listeners of a reply queue for "co-located" delegates inside the UIMA-AS aggregate.
> The following is the "proposed" syntax:
> <analysisEngine async="true"> <!-- Top aggregate -->
> <replyQueue concurrentConsumers="2">
> ...
> <delegates>
> <analysisEngine key="NamesAndPersonTitlesTAE" async="true"> <!-- co-located aggregate -->
> <replyQueue concurrentConsumers="3">
> ...
> </analysisEngine>
> ...
> </delegates>
> ...
> </analysisEngine>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1146) Setting the number of concurrent
listeners of a reply queue for Co-located Delegates
Posted by "Tong Fin (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tong Fin updated UIMA-1146:
---------------------------
Attachment: queue-listeners.jpg
UI for queue listeners of an AS aggregate
> Setting the number of concurrent listeners of a reply queue for Co-located Delegates
> ------------------------------------------------------------------------------------
>
> Key: UIMA-1146
> URL: https://issues.apache.org/jira/browse/UIMA-1146
> Project: UIMA
> Issue Type: Improvement
> Components: Async Scaleout
> Affects Versions: 2.2.2AS
> Reporter: Tong Fin
> Assignee: Marshall Schor
> Attachments: DDE_Patch_1of2_JIRA-1146.txt, DDE_Patch_2of2_JIRA-1146.txt, queue-listeners.jpg
>
>
> JIRA-1130 has improved UIMA-AS to allow users to set the number of concurrent listeners of a reply queue for each "remote" delegate. The following is the syntax in the xml deployment descriptor (as an example):
> <analysisEngine async="true">
> <delegates>
> <remoteAnalysisEngine key="RoomNumber">
> <inputQueue brokerURL="tcp://localhost:61616" endpoint="RoomNumberAnnotatorQueue"/>
> <replyQueue concurrentConsumers="2" location="remote"/>
> ...
> </remoteAnalysisEngine>
> </delegates>
> ...
> </analysisEngine>
> This JIRA will do the similar thing by allowing users to set the number of concurrent listeners of a reply queue for "co-located" delegates inside the UIMA-AS aggregate.
> The following is the "proposed" syntax:
> <analysisEngine async="true"> <!-- Top aggregate -->
> <replyQueue concurrentConsumers="2">
> ...
> <delegates>
> <analysisEngine key="NamesAndPersonTitlesTAE" async="true"> <!-- co-located aggregate -->
> <replyQueue concurrentConsumers="3">
> ...
> </analysisEngine>
> ...
> </delegates>
> ...
> </analysisEngine>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (UIMA-1146) Setting the number of concurrent
listeners of a reply queue for Co-located Delegates
Posted by "Tong Fin (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tong Fin reassigned UIMA-1146:
------------------------------
Assignee: Marshall Schor (was: Tong Fin)
Marshall,
Please help to apply the patch.
If the work in DD2Spring is done, please re-assign back to me for testing.
-- Tong
> Setting the number of concurrent listeners of a reply queue for Co-located Delegates
> ------------------------------------------------------------------------------------
>
> Key: UIMA-1146
> URL: https://issues.apache.org/jira/browse/UIMA-1146
> Project: UIMA
> Issue Type: Improvement
> Components: Async Scaleout
> Affects Versions: 2.2.2AS
> Reporter: Tong Fin
> Assignee: Marshall Schor
> Attachments: DDE_Patch_1of2_JIRA-1146.txt, DDE_Patch_2of2_JIRA-1146.txt
>
>
> JIRA-1130 has improved UIMA-AS to allow users to set the number of concurrent listeners of a reply queue for each "remote" delegate. The following is the syntax in the xml deployment descriptor (as an example):
> <analysisEngine async="true">
> <delegates>
> <remoteAnalysisEngine key="RoomNumber">
> <inputQueue brokerURL="tcp://localhost:61616" endpoint="RoomNumberAnnotatorQueue"/>
> <replyQueue concurrentConsumers="2" location="remote"/>
> ...
> </remoteAnalysisEngine>
> </delegates>
> ...
> </analysisEngine>
> This JIRA will do the similar thing by allowing users to set the number of concurrent listeners of a reply queue for "co-located" delegates inside the UIMA-AS aggregate.
> The following is the "proposed" syntax:
> <analysisEngine async="true"> <!-- Top aggregate -->
> <replyQueue concurrentConsumers="2">
> ...
> <delegates>
> <analysisEngine key="NamesAndPersonTitlesTAE" async="true"> <!-- co-located aggregate -->
> <replyQueue concurrentConsumers="3">
> ...
> </analysisEngine>
> ...
> </delegates>
> ...
> </analysisEngine>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1146) Setting the number of concurrent
listeners of a reply queue for Co-located Delegates
Posted by "Tong Fin (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tong Fin updated UIMA-1146:
---------------------------
Attachment: queue-listeners.jpg
Screen-shot for supporting queue listeners for AS aggregate
BTW, I am testing the Wiki style markup for image.
> Setting the number of concurrent listeners of a reply queue for Co-located Delegates
> ------------------------------------------------------------------------------------
>
> Key: UIMA-1146
> URL: https://issues.apache.org/jira/browse/UIMA-1146
> Project: UIMA
> Issue Type: Improvement
> Components: Async Scaleout
> Affects Versions: 2.2.2AS
> Reporter: Tong Fin
> Assignee: Marshall Schor
> Attachments: DDE_Patch_1of2_JIRA-1146.txt, DDE_Patch_2of2_JIRA-1146.txt
>
>
> JIRA-1130 has improved UIMA-AS to allow users to set the number of concurrent listeners of a reply queue for each "remote" delegate. The following is the syntax in the xml deployment descriptor (as an example):
> <analysisEngine async="true">
> <delegates>
> <remoteAnalysisEngine key="RoomNumber">
> <inputQueue brokerURL="tcp://localhost:61616" endpoint="RoomNumberAnnotatorQueue"/>
> <replyQueue concurrentConsumers="2" location="remote"/>
> ...
> </remoteAnalysisEngine>
> </delegates>
> ...
> </analysisEngine>
> This JIRA will do the similar thing by allowing users to set the number of concurrent listeners of a reply queue for "co-located" delegates inside the UIMA-AS aggregate.
> The following is the "proposed" syntax:
> <analysisEngine async="true"> <!-- Top aggregate -->
> <replyQueue concurrentConsumers="2">
> ...
> <delegates>
> <analysisEngine key="NamesAndPersonTitlesTAE" async="true"> <!-- co-located aggregate -->
> <replyQueue concurrentConsumers="3">
> ...
> </analysisEngine>
> ...
> </delegates>
> ...
> </analysisEngine>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1146) Setting the number of concurrent
listeners of a reply queue for Co-located Delegates
Posted by "Tong Fin (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tong Fin closed UIMA-1146.
--------------------------
Verified
> Setting the number of concurrent listeners of a reply queue for Co-located Delegates
> ------------------------------------------------------------------------------------
>
> Key: UIMA-1146
> URL: https://issues.apache.org/jira/browse/UIMA-1146
> Project: UIMA
> Issue Type: Improvement
> Components: Async Scaleout
> Affects Versions: 2.2.2AS
> Reporter: Tong Fin
> Assignee: Tong Fin
> Fix For: 2.3AS
>
> Attachments: DDE_Patch_1of2_JIRA-1146.txt, DDE_Patch_2of2Modified08-25-2008_JIRA-1146.txt, queue-listeners.jpg
>
>
> JIRA-1130 has improved UIMA-AS to allow users to set the number of concurrent listeners of a reply queue for each "remote" delegate. The following is the syntax in the xml deployment descriptor (as an example):
> <analysisEngine async="true">
> <delegates>
> <remoteAnalysisEngine key="RoomNumber">
> <inputQueue brokerURL="tcp://localhost:61616" endpoint="RoomNumberAnnotatorQueue"/>
> <replyQueue concurrentConsumers="2" location="remote"/>
> ...
> </remoteAnalysisEngine>
> </delegates>
> ...
> </analysisEngine>
> This JIRA will do the similar thing by allowing users to set the number of concurrent listeners of a reply queue for "co-located" delegates inside the UIMA-AS aggregate.
> The following is the "proposed" syntax:
> <analysisEngine async="true"> <!-- Top aggregate -->
> <replyQueue concurrentConsumers="2">
> ...
> <delegates>
> <analysisEngine key="NamesAndPersonTitlesTAE" async="true"> <!-- co-located aggregate -->
> <replyQueue concurrentConsumers="3">
> ...
> </analysisEngine>
> ...
> </delegates>
> ...
> </analysisEngine>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1146) Setting the number of concurrent
listeners of a reply queue for Co-located Delegates
Posted by "Tong Fin (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tong Fin updated UIMA-1146:
---------------------------
Attachment: (was: DDE_Patch_2of2_JIRA-1146.txt)
> Setting the number of concurrent listeners of a reply queue for Co-located Delegates
> ------------------------------------------------------------------------------------
>
> Key: UIMA-1146
> URL: https://issues.apache.org/jira/browse/UIMA-1146
> Project: UIMA
> Issue Type: Improvement
> Components: Async Scaleout
> Affects Versions: 2.2.2AS
> Reporter: Tong Fin
> Assignee: Marshall Schor
> Attachments: DDE_Patch_1of2_JIRA-1146.txt, queue-listeners.jpg
>
>
> JIRA-1130 has improved UIMA-AS to allow users to set the number of concurrent listeners of a reply queue for each "remote" delegate. The following is the syntax in the xml deployment descriptor (as an example):
> <analysisEngine async="true">
> <delegates>
> <remoteAnalysisEngine key="RoomNumber">
> <inputQueue brokerURL="tcp://localhost:61616" endpoint="RoomNumberAnnotatorQueue"/>
> <replyQueue concurrentConsumers="2" location="remote"/>
> ...
> </remoteAnalysisEngine>
> </delegates>
> ...
> </analysisEngine>
> This JIRA will do the similar thing by allowing users to set the number of concurrent listeners of a reply queue for "co-located" delegates inside the UIMA-AS aggregate.
> The following is the "proposed" syntax:
> <analysisEngine async="true"> <!-- Top aggregate -->
> <replyQueue concurrentConsumers="2">
> ...
> <delegates>
> <analysisEngine key="NamesAndPersonTitlesTAE" async="true"> <!-- co-located aggregate -->
> <replyQueue concurrentConsumers="3">
> ...
> </analysisEngine>
> ...
> </delegates>
> ...
> </analysisEngine>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1146) Setting the number of concurrent
listeners of a reply queue for Co-located Delegates
Posted by "Tong Fin (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tong Fin updated UIMA-1146:
---------------------------
Attachment: DDE_Patch_2of2_JIRA-1146.txt
DDE_Patch_1of2_JIRA-1146.txt
This patch is also for JIRA-1130 since the syntax for the remote reply queue listeners has changes.
> Setting the number of concurrent listeners of a reply queue for Co-located Delegates
> ------------------------------------------------------------------------------------
>
> Key: UIMA-1146
> URL: https://issues.apache.org/jira/browse/UIMA-1146
> Project: UIMA
> Issue Type: Improvement
> Components: Async Scaleout
> Affects Versions: 2.2.2AS
> Reporter: Tong Fin
> Assignee: Tong Fin
> Attachments: DDE_Patch_1of2_JIRA-1146.txt, DDE_Patch_2of2_JIRA-1146.txt
>
>
> JIRA-1130 has improved UIMA-AS to allow users to set the number of concurrent listeners of a reply queue for each "remote" delegate. The following is the syntax in the xml deployment descriptor (as an example):
> <analysisEngine async="true">
> <delegates>
> <remoteAnalysisEngine key="RoomNumber">
> <inputQueue brokerURL="tcp://localhost:61616" endpoint="RoomNumberAnnotatorQueue"/>
> <replyQueue concurrentConsumers="2" location="remote"/>
> ...
> </remoteAnalysisEngine>
> </delegates>
> ...
> </analysisEngine>
> This JIRA will do the similar thing by allowing users to set the number of concurrent listeners of a reply queue for "co-located" delegates inside the UIMA-AS aggregate.
> The following is the "proposed" syntax:
> <analysisEngine async="true"> <!-- Top aggregate -->
> <replyQueue concurrentConsumers="2">
> ...
> <delegates>
> <analysisEngine key="NamesAndPersonTitlesTAE" async="true"> <!-- co-located aggregate -->
> <replyQueue concurrentConsumers="3">
> ...
> </analysisEngine>
> ...
> </delegates>
> ...
> </analysisEngine>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1146) Setting the number of concurrent
listeners of a reply queue for Co-located Delegates
Posted by "Tong Fin (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625483#action_12625483 ]
Tong Fin commented on UIMA-1146:
--------------------------------
The following is the UI for the queue listeners of an AS aggregate.
I used the Wiki markup. Does someone have the problem to see the screen-shot ?
!queue-listeners.jpg!
-- Tong
> Setting the number of concurrent listeners of a reply queue for Co-located Delegates
> ------------------------------------------------------------------------------------
>
> Key: UIMA-1146
> URL: https://issues.apache.org/jira/browse/UIMA-1146
> Project: UIMA
> Issue Type: Improvement
> Components: Async Scaleout
> Affects Versions: 2.2.2AS
> Reporter: Tong Fin
> Assignee: Marshall Schor
> Attachments: DDE_Patch_1of2_JIRA-1146.txt, DDE_Patch_2of2_JIRA-1146.txt, queue-listeners.jpg
>
>
> JIRA-1130 has improved UIMA-AS to allow users to set the number of concurrent listeners of a reply queue for each "remote" delegate. The following is the syntax in the xml deployment descriptor (as an example):
> <analysisEngine async="true">
> <delegates>
> <remoteAnalysisEngine key="RoomNumber">
> <inputQueue brokerURL="tcp://localhost:61616" endpoint="RoomNumberAnnotatorQueue"/>
> <replyQueue concurrentConsumers="2" location="remote"/>
> ...
> </remoteAnalysisEngine>
> </delegates>
> ...
> </analysisEngine>
> This JIRA will do the similar thing by allowing users to set the number of concurrent listeners of a reply queue for "co-located" delegates inside the UIMA-AS aggregate.
> The following is the "proposed" syntax:
> <analysisEngine async="true"> <!-- Top aggregate -->
> <replyQueue concurrentConsumers="2">
> ...
> <delegates>
> <analysisEngine key="NamesAndPersonTitlesTAE" async="true"> <!-- co-located aggregate -->
> <replyQueue concurrentConsumers="3">
> ...
> </analysisEngine>
> ...
> </delegates>
> ...
> </analysisEngine>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1146) Setting the number of concurrent
listeners of a reply queue for Co-located Delegates
Posted by "Burn Lewis (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624995#action_12624995 ]
Burn Lewis commented on UIMA-1146:
----------------------------------
>> When used with Uima AS primitives, "scaleout" means to replicate instances of analysis components. Overloading "scaleout" to refer to replicating some threads in an aggregate will result in unnecessary confusion.
What we're discussing here is scaling out the work done by the aggregate controller in dispatching CASes to its delegates ... probably the bulk of the work of an async aggregate. But I agree it is confusing since in the sync case the aggregate load is the aggregate of its delegates. So we would need to be clear that we're scaling out the controller dispatch work, just as in the proposal above we're scaling out work done when servicing the 3 types of queues.
>> Individual remote reply queues still need to be scaled (see UIMA-1130)
1130 solves the load problem when processing remote replies and has the nice side-effect of providing a type of pre-fetch. As Eddie has pointed out my suggestion of a single "fast" consumer of a remote queue would not be as good since each reply would still be delayed by the handshaking with the broker. Since the need for pre-fetch is somewhat separate from the load issue that originally motivated 1130 one (ugly) solution would be to restore the non-standard prefetch parameter, and implement it with multiple consumers on WebSphere. But there goes my hope for fewer tuning parameters! Ugh.
> Setting the number of concurrent listeners of a reply queue for Co-located Delegates
> ------------------------------------------------------------------------------------
>
> Key: UIMA-1146
> URL: https://issues.apache.org/jira/browse/UIMA-1146
> Project: UIMA
> Issue Type: Improvement
> Components: Async Scaleout
> Affects Versions: 2.2.2AS
> Reporter: Tong Fin
> Assignee: Tong Fin
>
> JIRA-1130 has improved UIMA-AS to allow users to set the number of concurrent listeners of a reply queue for each "remote" delegate. The following is the syntax in the xml deployment descriptor (as an example):
> <analysisEngine async="true">
> <delegates>
> <remoteAnalysisEngine key="RoomNumber">
> <inputQueue brokerURL="tcp://localhost:61616" endpoint="RoomNumberAnnotatorQueue"/>
> <replyQueue concurrentConsumers="2" location="remote"/>
> ...
> </remoteAnalysisEngine>
> </delegates>
> ...
> </analysisEngine>
> This JIRA will do the similar thing by allowing users to set the number of concurrent listeners of a reply queue for "co-located" delegates inside the UIMA-AS aggregate.
> The following is the "proposed" syntax:
> <analysisEngine async="true"> <!-- Top aggregate -->
> <replyQueue concurrentConsumers="2">
> ...
> <delegates>
> <analysisEngine key="NamesAndPersonTitlesTAE" async="true"> <!-- co-located aggregate -->
> <replyQueue concurrentConsumers="3">
> ...
> </analysisEngine>
> ...
> </delegates>
> ...
> </analysisEngine>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1146) Setting the number of concurrent
listeners of a reply queue for Co-located Delegates
Posted by "Burn Lewis (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624401#action_12624401 ]
Burn Lewis commented on UIMA-1146:
----------------------------------
I'm a little concerned that we are adding a lot of parameters that may be tricky to tune. Presumably most applications will take the default but for those that may benefit from scaleout it may be hard to determine which queue needs the extra threads. For an aggregate with N remote delegates and at least 1 co-located we'll have N+2 parameters to consider. Since these 3 types of queue consumers are all doing similar work, dispatching the CASes within the aggregate, wouldn't it be nice if we could have only 1 scaleout parameter for each aggregate.
<analysisEngine async="true" scaleout="n">
This would let users focus more on the aggregate as a dispatcher of work, and less on the subtleties of our implementation.
We could support this by using a Java queue for all replies (not just co-located ones as proposed elsewhere) and scale out the dispatch threads that consume this queue. The input queue and each remote queue would still have dedicated threads, but they would merely put the message on the Java queue along with the appropriate CAS, after blocking on the CasPool if necessary.
One drawback is the extra thread switch but this may be small compared with the transport time for a remote. Another is that the extra consumers of remote queues are expected to replace the need for prefetch, but since this proposal separates the fetching from the dispatching the lightweight fetch thread may achieve the same effect as pretetch.
> Setting the number of concurrent listeners of a reply queue for Co-located Delegates
> ------------------------------------------------------------------------------------
>
> Key: UIMA-1146
> URL: https://issues.apache.org/jira/browse/UIMA-1146
> Project: UIMA
> Issue Type: Improvement
> Components: Async Scaleout
> Affects Versions: 2.2.2AS
> Reporter: Tong Fin
> Assignee: Tong Fin
>
> JIRA-1130 has improved UIMA-AS to allow users to set the number of concurrent listeners of a reply queue for each "remote" delegate. The following is the syntax in the xml deployment descriptor (as an example):
> <analysisEngine async="true">
> <delegates>
> <remoteAnalysisEngine key="RoomNumber">
> <inputQueue brokerURL="tcp://localhost:61616" endpoint="RoomNumberAnnotatorQueue"/>
> <replyQueue concurrentConsumers="2" location="remote"/>
> ...
> </remoteAnalysisEngine>
> </delegates>
> ...
> </analysisEngine>
> This JIRA will do the similar thing by allowing users to set the number of concurrent listeners of a reply queue for "co-located" delegates inside the UIMA-AS aggregate.
> The following is the "proposed" syntax:
> <analysisEngine async="true"> <!-- Top aggregate -->
> <replyQueue concurrentConsumers="2">
> ...
> <delegates>
> <analysisEngine key="NamesAndPersonTitlesTAE" async="true"> <!-- co-located aggregate -->
> <replyQueue concurrentConsumers="3">
> ...
> </analysisEngine>
> ...
> </delegates>
> ...
> </analysisEngine>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1146) Setting the number of concurrent
listeners of a reply queue for Co-located Delegates
Posted by "Tong Fin (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624966#action_12624966 ]
Tong Fin commented on UIMA-1146:
--------------------------------
It looks like the following is the preferred syntax:
attributes on <analysisEngine> itself:
<analysisEngine async="true" internalReplyQueueScaleout="nn1"
inputQueueScaleout="nn2">
....
</analysisEngine>
And, for JIRA-1130:
<remoteAnalysisEngine remoteReplyQueueScaleout="nn1" >
....
</remoteAnalysisEngine>
I will start to do the work based on the above syntax if there is no objection :)
-- Tong
> Setting the number of concurrent listeners of a reply queue for Co-located Delegates
> ------------------------------------------------------------------------------------
>
> Key: UIMA-1146
> URL: https://issues.apache.org/jira/browse/UIMA-1146
> Project: UIMA
> Issue Type: Improvement
> Components: Async Scaleout
> Affects Versions: 2.2.2AS
> Reporter: Tong Fin
> Assignee: Tong Fin
>
> JIRA-1130 has improved UIMA-AS to allow users to set the number of concurrent listeners of a reply queue for each "remote" delegate. The following is the syntax in the xml deployment descriptor (as an example):
> <analysisEngine async="true">
> <delegates>
> <remoteAnalysisEngine key="RoomNumber">
> <inputQueue brokerURL="tcp://localhost:61616" endpoint="RoomNumberAnnotatorQueue"/>
> <replyQueue concurrentConsumers="2" location="remote"/>
> ...
> </remoteAnalysisEngine>
> </delegates>
> ...
> </analysisEngine>
> This JIRA will do the similar thing by allowing users to set the number of concurrent listeners of a reply queue for "co-located" delegates inside the UIMA-AS aggregate.
> The following is the "proposed" syntax:
> <analysisEngine async="true"> <!-- Top aggregate -->
> <replyQueue concurrentConsumers="2">
> ...
> <delegates>
> <analysisEngine key="NamesAndPersonTitlesTAE" async="true"> <!-- co-located aggregate -->
> <replyQueue concurrentConsumers="3">
> ...
> </analysisEngine>
> ...
> </delegates>
> ...
> </analysisEngine>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (UIMA-1146) Setting the number of concurrent
listeners of a reply queue for Co-located Delegates
Posted by "Marshall Schor (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marshall Schor resolved UIMA-1146.
----------------------------------
Resolution: Fixed
Fix Version/s: 2.3AS
Assignee: Tong Fin (was: Marshall Schor)
Assiging to Tong to verify
> Setting the number of concurrent listeners of a reply queue for Co-located Delegates
> ------------------------------------------------------------------------------------
>
> Key: UIMA-1146
> URL: https://issues.apache.org/jira/browse/UIMA-1146
> Project: UIMA
> Issue Type: Improvement
> Components: Async Scaleout
> Affects Versions: 2.2.2AS
> Reporter: Tong Fin
> Assignee: Tong Fin
> Fix For: 2.3AS
>
> Attachments: DDE_Patch_1of2_JIRA-1146.txt, DDE_Patch_2of2Modified08-25-2008_JIRA-1146.txt, queue-listeners.jpg
>
>
> JIRA-1130 has improved UIMA-AS to allow users to set the number of concurrent listeners of a reply queue for each "remote" delegate. The following is the syntax in the xml deployment descriptor (as an example):
> <analysisEngine async="true">
> <delegates>
> <remoteAnalysisEngine key="RoomNumber">
> <inputQueue brokerURL="tcp://localhost:61616" endpoint="RoomNumberAnnotatorQueue"/>
> <replyQueue concurrentConsumers="2" location="remote"/>
> ...
> </remoteAnalysisEngine>
> </delegates>
> ...
> </analysisEngine>
> This JIRA will do the similar thing by allowing users to set the number of concurrent listeners of a reply queue for "co-located" delegates inside the UIMA-AS aggregate.
> The following is the "proposed" syntax:
> <analysisEngine async="true"> <!-- Top aggregate -->
> <replyQueue concurrentConsumers="2">
> ...
> <delegates>
> <analysisEngine key="NamesAndPersonTitlesTAE" async="true"> <!-- co-located aggregate -->
> <replyQueue concurrentConsumers="3">
> ...
> </analysisEngine>
> ...
> </delegates>
> ...
> </analysisEngine>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1146) Setting the number of concurrent
listeners of a reply queue for Co-located Delegates
Posted by "Tong Fin (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tong Fin updated UIMA-1146:
---------------------------
Summary: Setting the number of concurrent listeners of a reply queue for Co-located Delegates (was: Setting the number of concurrent listeners off a reply queue for Co-located Delegates)
Correct spelling
> Setting the number of concurrent listeners of a reply queue for Co-located Delegates
> ------------------------------------------------------------------------------------
>
> Key: UIMA-1146
> URL: https://issues.apache.org/jira/browse/UIMA-1146
> Project: UIMA
> Issue Type: Improvement
> Components: Async Scaleout
> Affects Versions: 2.2.2AS
> Reporter: Tong Fin
> Assignee: Tong Fin
>
> JIRA-1130 has improved UIMA-AS to allow users to set the number of concurrent listeners of a reply queue for each "remote" delegate. The following is the syntax in the xml deployment descriptor (as an example):
> <analysisEngine async="true">
> <delegates>
> <remoteAnalysisEngine key="RoomNumber">
> <inputQueue brokerURL="tcp://localhost:61616" endpoint="RoomNumberAnnotatorQueue"/>
> <replyQueue concurrentConsumers="2" location="remote"/>
> ...
> </remoteAnalysisEngine>
> </delegates>
> ...
> </analysisEngine>
> This JIRA will do the similar thing by allowing users to set the number of concurrent listeners of a reply queue for "co-located" delegates inside the UIMA-AS aggregate.
> The following is the "proposed" syntax:
> <analysisEngine async="true"> <!-- Top aggregate -->
> <replyQueue concurrentConsumers="2">
> ...
> <delegates>
> <analysisEngine key="NamesAndPersonTitlesTAE" async="true"> <!-- co-located aggregate -->
> <replyQueue concurrentConsumers="3">
> ...
> </analysisEngine>
> ...
> </delegates>
> ...
> </analysisEngine>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1146) Setting the number of concurrent
listeners of a reply queue for Co-located Delegates
Posted by "Marshall Schor (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624031#action_12624031 ]
Marshall Schor commented on UIMA-1146:
--------------------------------------
The need for this became apparent when Adam found the next bottleneck in scaleout using UIMA-AS. He found that the work of the UIMA Aggregate controller: running the flow controller code, serializing the CAS back to the sender (if remote) or out to remote delegates) could be a bottleneck. The framework already supports multiple threads for this work, but only one is being used.
Here is a summary of discussions about this with Eddie, Burn, and Tong.
This issue is about threads for doing the work of an aggregate.
Threads for doing the work of a primitive are specified using <scaleout numberOfInstances="nnn"/>
The work of an aggregate, done on a thread, is:
1) deserializing (not needed for communication within co-located components)
2) running the Flow Controller
3) serializing a CAS (not always needed)
either back to a caller (if not co-located) or out to a remote
This work applies both to top-level aggregates, as well as contained, co-located aggregates.
The threads for doing the work are associated with the queues involved. Each queue could have a different number of threads.
There are 3 queues for an aggregate (top level, or inner, co-located), some of which may not be present in any given deployment. The three are:
1) the input queue for this aggregate. Note: inner aggregates have their own input queue
2) local reply q for co-located delegates
3) remote reply q for remote delegates
UIMA-1130 allowed specifying the scaleout for queue # 3.
This Jira is to allow specifying the scaleouts for queue # 1 and 2.
This specification is needed at multiple levels of aggregation (for those analysisEngines having async="true"; analysisEngines with async="false" are treated by UIMA-AS as "primitives")
There are two specifications needed in general:
1) one for the internal reply queue (in addition to the existing remote reply queues), and
2) one for the input queue.
I think it would be less confusing if we avoided overloading the same element name (i.e., replyQueue) with different meanings, depending on context.
I would propose the following:
Each <analysisEngine async="true"> element would have a spec for these two scaleout numbers. This could be done as attributes on the <analysisEngine... > spec itself, or as one or two nested elements. Here's 3 proposals:
attributes on <analysisEngine> itself:
<analysisEngine async="true" internalReplyQueueScaleout="nn1" inputQueueScaleout="nn2">
one nested element:
<analysisEngine async="true">
<aggregateWorkScaleout internalReplyQueue='nn1" inputQueue="nn2"/>
two nested elements:
<analysisEngine async="true">
<internalReplyQueue scaleout="nn1"/>
<inputQueue scaleout="nn2"/>
I prefer the first alternative, but not strongly. If we did this, I would also propose changing what we did for UIMA-1130 to follow this same syntax, adding a remoteReplyQueueScaleout="nn1" to the <remoteAnalysisEngine> element. We still have time to change that, I think, if we want to.
Other opinions?
> Setting the number of concurrent listeners of a reply queue for Co-located Delegates
> ------------------------------------------------------------------------------------
>
> Key: UIMA-1146
> URL: https://issues.apache.org/jira/browse/UIMA-1146
> Project: UIMA
> Issue Type: Improvement
> Components: Async Scaleout
> Affects Versions: 2.2.2AS
> Reporter: Tong Fin
> Assignee: Tong Fin
>
> JIRA-1130 has improved UIMA-AS to allow users to set the number of concurrent listeners of a reply queue for each "remote" delegate. The following is the syntax in the xml deployment descriptor (as an example):
> <analysisEngine async="true">
> <delegates>
> <remoteAnalysisEngine key="RoomNumber">
> <inputQueue brokerURL="tcp://localhost:61616" endpoint="RoomNumberAnnotatorQueue"/>
> <replyQueue concurrentConsumers="2" location="remote"/>
> ...
> </remoteAnalysisEngine>
> </delegates>
> ...
> </analysisEngine>
> This JIRA will do the similar thing by allowing users to set the number of concurrent listeners of a reply queue for "co-located" delegates inside the UIMA-AS aggregate.
> The following is the "proposed" syntax:
> <analysisEngine async="true"> <!-- Top aggregate -->
> <replyQueue concurrentConsumers="2">
> ...
> <delegates>
> <analysisEngine key="NamesAndPersonTitlesTAE" async="true"> <!-- co-located aggregate -->
> <replyQueue concurrentConsumers="3">
> ...
> </analysisEngine>
> ...
> </delegates>
> ...
> </analysisEngine>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1146) Setting the number of concurrent
listeners of a reply queue for Co-located Delegates
Posted by "Tong Fin (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tong Fin updated UIMA-1146:
---------------------------
Attachment: (was: queue-listeners.jpg)
> Setting the number of concurrent listeners of a reply queue for Co-located Delegates
> ------------------------------------------------------------------------------------
>
> Key: UIMA-1146
> URL: https://issues.apache.org/jira/browse/UIMA-1146
> Project: UIMA
> Issue Type: Improvement
> Components: Async Scaleout
> Affects Versions: 2.2.2AS
> Reporter: Tong Fin
> Assignee: Marshall Schor
> Attachments: DDE_Patch_1of2_JIRA-1146.txt, DDE_Patch_2of2_JIRA-1146.txt
>
>
> JIRA-1130 has improved UIMA-AS to allow users to set the number of concurrent listeners of a reply queue for each "remote" delegate. The following is the syntax in the xml deployment descriptor (as an example):
> <analysisEngine async="true">
> <delegates>
> <remoteAnalysisEngine key="RoomNumber">
> <inputQueue brokerURL="tcp://localhost:61616" endpoint="RoomNumberAnnotatorQueue"/>
> <replyQueue concurrentConsumers="2" location="remote"/>
> ...
> </remoteAnalysisEngine>
> </delegates>
> ...
> </analysisEngine>
> This JIRA will do the similar thing by allowing users to set the number of concurrent listeners of a reply queue for "co-located" delegates inside the UIMA-AS aggregate.
> The following is the "proposed" syntax:
> <analysisEngine async="true"> <!-- Top aggregate -->
> <replyQueue concurrentConsumers="2">
> ...
> <delegates>
> <analysisEngine key="NamesAndPersonTitlesTAE" async="true"> <!-- co-located aggregate -->
> <replyQueue concurrentConsumers="3">
> ...
> </analysisEngine>
> ...
> </delegates>
> ...
> </analysisEngine>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1146) Setting the number of concurrent
listeners of a reply queue for Co-located Delegates
Posted by "Tong Fin (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tong Fin updated UIMA-1146:
---------------------------
Attachment: DDE_Patch_2of2Modified08-25-2008_JIRA-1146.txt
Marshall,
I replaced the 2nd patch file to add some additional wording for the hover text.
It is safer to apply my 2 patches one more time.
Thanks,
Tong
> Setting the number of concurrent listeners of a reply queue for Co-located Delegates
> ------------------------------------------------------------------------------------
>
> Key: UIMA-1146
> URL: https://issues.apache.org/jira/browse/UIMA-1146
> Project: UIMA
> Issue Type: Improvement
> Components: Async Scaleout
> Affects Versions: 2.2.2AS
> Reporter: Tong Fin
> Assignee: Marshall Schor
> Attachments: DDE_Patch_1of2_JIRA-1146.txt, DDE_Patch_2of2Modified08-25-2008_JIRA-1146.txt, queue-listeners.jpg
>
>
> JIRA-1130 has improved UIMA-AS to allow users to set the number of concurrent listeners of a reply queue for each "remote" delegate. The following is the syntax in the xml deployment descriptor (as an example):
> <analysisEngine async="true">
> <delegates>
> <remoteAnalysisEngine key="RoomNumber">
> <inputQueue brokerURL="tcp://localhost:61616" endpoint="RoomNumberAnnotatorQueue"/>
> <replyQueue concurrentConsumers="2" location="remote"/>
> ...
> </remoteAnalysisEngine>
> </delegates>
> ...
> </analysisEngine>
> This JIRA will do the similar thing by allowing users to set the number of concurrent listeners of a reply queue for "co-located" delegates inside the UIMA-AS aggregate.
> The following is the "proposed" syntax:
> <analysisEngine async="true"> <!-- Top aggregate -->
> <replyQueue concurrentConsumers="2">
> ...
> <delegates>
> <analysisEngine key="NamesAndPersonTitlesTAE" async="true"> <!-- co-located aggregate -->
> <replyQueue concurrentConsumers="3">
> ...
> </analysisEngine>
> ...
> </delegates>
> ...
> </analysisEngine>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.