I updated the description with a (hopefully) more expansive (and correct -
please fix if incorrect) description.  I had trouble following the previous
short description.

-Marshall


On 5/2/2017 9:53 AM, Marshall Schor (JIRA) wrote:
>      [ 
> https://issues.apache.org/jira/browse/UIMA-5417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>  ]
>
> Marshall Schor updated UIMA-5417:
> ---------------------------------
>     Description: 
> This is about dd2spring treatment of the scaleout element, in one particular 
> unusual use case.  DD2Spring already has code to ignore the scaleout value, 
> if the top-level-aggregate is marked "async=true".  This is because that 
> scaleout is only applicable for the case where async=false, and uima-as is 
> scaling the top-level-aggregate by having multiple threads (= pipelines) 
> replicating the top level aggregate.  
>
> When async=true, the scaleout element is ignored, because uima-as will be 
> (potentially) scaling out each async delegate separately. 
>
> The use case here is all about "defaulting" the async=true/false.  The 
> current dd2spring code, if no specification is made for async=, defaults to 
> async=false, unless the deployment descriptor has individual specs for the 
> delgates, in which case it defaults to async=true.  For this last case, 
> dd2spring is missing the the code to ignore the scaleout parameter (if set > 
> 1).  This Jira is to add that check for that use case.
>
> It lets the scaleout value change the caspool size when the async attribute 
> is defaulted to true (because the delegates element is specified, which 
> implies async="true")
> .
> The current dd2spring code correctly ignores the scaleout element when the 
> async attribute is explicitly set to "true" ... and it needs to do the same 
> when the default is "true". 
>
>   was:
> It lets the scaleout value change the caspool size when the async attribute 
> is defaulted while the delegates element is specified, which implies 
> async="true".
> The scaleout element is ignored when the async attribute is explicitly set to 
> "true" ... should do the same when the default is "true". 
>
>
>> dd2spring should always ignore the scaleout value for sync UIMA-AS DDs
>> ----------------------------------------------------------------------
>>
>>                 Key: UIMA-5417
>>                 URL: https://issues.apache.org/jira/browse/UIMA-5417
>>             Project: UIMA
>>          Issue Type: Bug
>>          Components: Async Scaleout
>>            Reporter: Burn Lewis
>>            Priority: Minor
>>             Fix For: 2.10.0AS
>>
>>
>> This is about dd2spring treatment of the scaleout element, in one particular 
>> unusual use case.  DD2Spring already has code to ignore the scaleout value, 
>> if the top-level-aggregate is marked "async=true".  This is because that 
>> scaleout is only applicable for the case where async=false, and uima-as is 
>> scaling the top-level-aggregate by having multiple threads (= pipelines) 
>> replicating the top level aggregate.  
>> When async=true, the scaleout element is ignored, because uima-as will be 
>> (potentially) scaling out each async delegate separately. 
>> The use case here is all about "defaulting" the async=true/false.  The 
>> current dd2spring code, if no specification is made for async=, defaults to 
>> async=false, unless the deployment descriptor has individual specs for the 
>> delgates, in which case it defaults to async=true.  For this last case, 
>> dd2spring is missing the the code to ignore the scaleout parameter (if set > 
>> 1).  This Jira is to add that check for that use case.
>> It lets the scaleout value change the caspool size when the async attribute 
>> is defaulted to true (because the delegates element is specified, which 
>> implies async="true")
>> .
>> The current dd2spring code correctly ignores the scaleout element when the 
>> async attribute is explicitly set to "true" ... and it needs to do the same 
>> when the default is "true". 
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.15#6346)
>

Reply via email to