uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eddie Epstein (JIRA)" <uima-...@incubator.apache.org>
Subject [jira] Commented: (UIMA-1133) Timeout needs different implementation to eliminate interaction with CAS pool size
Date Tue, 21 Oct 2008 21:42:44 GMT

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

Eddie Epstein commented on UIMA-1133:

The use of GetMeta to quickly test a questionable service is associated 
with jira 1127.

This issue is just dealing with the current undesirable connection between
cas pool size and timeout value.

Your description of increasing the timeout by the number of outstanding requests
sounds reasonable for setting the timeToLive value for the request message.
TimeToLive values do not have to be so precise as they are there to clean up
requests that would otherwise be left in a service queue.

However, for timeout detection these values could be too large and lead to
poor responsiveness for interactive systems. Consider the following

 - Use a single timer for a service
 - keep an ordered list of outstanding requests
 - When receiving a reply, restart the timer with DD-time only if this reply was
   for the oldest request
 - of course, don't restart timer if no more outstanding requests :)

With this scheme the actual timeout value for a request would never be greater
than 2x the DD-time.


> 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.

View raw message