[
https://issues.apache.org/jira/browse/UIMA-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jerry Cwiklik updated UIMA-1133:
--------------------------------
Attachment: uimaj-as-jms-UIMA-1133-patch.txt
uimaj-as-core-UIMA-1133-patch.txt
uimaj-as-activemq-UIMA-1133-patch.txt
Modified timeout logic in both the UIMA AS client API and UIMA AS Aggregate.
There is only one timer used for timing requests. Before a request is send to a
remote service, the client (aggregate and client API) adds the id of the CAS to
the list of CASes pending reply. The timer is started when the list is empty.
While the list is not empty, adding a new CAS to the list does not result in
starting a new timer. When a reply is received for the oldest pending request,
the ID of the CAS is removed from the list and the timer is restarted for the
next oldest CAS. If the timeout occurs and there is no retry configured, the
CAS id is removed from the pending list and the timer is restarted for the next
oldest pending request. If the timeout occurs and there is a retry to do, the
oldest pending request is *not* removed and a new timer is started.
> 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
> Attachments: uimaj-as-activemq-UIMA-1133-patch.txt,
> uimaj-as-core-UIMA-1133-patch.txt, uimaj-as-jms-UIMA-1133-patch.txt
>
>
> 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.
