[
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
algorithm:
- 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.
Eddie
> 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.
