uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jerry Cwiklik (JIRA)" <uima-...@incubator.apache.org>
Subject [jira] Updated: (UIMA-1133) Timeout needs different implementation to eliminate interaction with CAS pool size
Date Mon, 12 Jan 2009 15:10:06 GMT

     [ 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-patch2.txt

Modified client API to use the new Timeout logic that uses single timer to time requests.
The timeout is canceled when the oldest reply is received. The timer is subsequently restarted
for the second oldest CAS. The client adds each outgoing CAS to a list of CASes pending reply
to keep track of CASes outstanding. 

> 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-patch2.txt, uimaj-as-core-UIMA-1133-patch2.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.

View raw message