[jira] Commented: (UIMA-1133) Timeout needs different implementation to eliminate interaction with CAS pool size

["Jerry Cwiklik (JIRA)" <ui...@incubator.apache.org>]

    [ https://issues.apache.org/jira/browse/UIMA-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12641560#action_12641560 ] 

Jerry Cwiklik commented on UIMA-1133:
-------------------------------------

If I understand you correctly this dynamic timeout logic would work as follows:

First, if the timeout occurs the first thing that needs to be done is to send a GetMeta request to test if the service is alive. Only if the service responds we take additional actions as described below.

Uima AS client would maintain a number of outstanding requests for each remote delegate. If there are no outstanding requests, the next outgoing request will have a timeout equal to what the DD specifies for a given delegate. Once the request is sent, the number of outstanding requests will be incremented by one. For each subsequent request, the code will multiply the timeout by the number of outstanding requests. As indicated a Time To Live will have to be updated as well.

Each reply will decrement the number of outstanding requests.

Is this more or less the desired approach?

> Timeout needs different implementation to eliminate interaction with CAS pool size
> ----------------------------------------------------------------------------------
>
>                 Key: UIMA-1133
>                 URL: https://issues.apache.org/jira/browse/UIMA-1133
>             Project: UIMA
>          Issue Type: Improvement
>          Components: Async Scaleout
>            Reporter: Eddie Epstein
>            Assignee: Jerry Cwiklik
>
> When a timeout value is specified for process calls, a timer is set for each processCas request. If an aggregate controller (or client API) sends multiple process requests to the same service, the timeout must be increased to account for the potential processing delay of the earlier requests. Currently the timeout value is static, specified in the deployment descriptor; if a user changes the CAS pools size, they may have to change the timeout to compensate.
> A better design would decouple these things by changing the implementation of timeout. For example, the timeout value could be dynamic, taking into account the number of outstanding requests sent by the same client. The new implementation should take into account the need to set appropriate time-to-live values for the request messages.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.