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] Reopened: (UIMA-1127) Services that timeout should be handled differently on subsequent requests
Date Thu, 05 Feb 2009 15:33:59 GMT

     [ https://issues.apache.org/jira/browse/UIMA-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jerry Cwiklik reopened UIMA-1127:
---------------------------------


When the ping times out, the current code applies action associated with a failed GetMeta
call. The current choices are disable or terminate. We need to add a third choice - ignore.
This would enable starting an aggregate service without requiring that all of its delegates
are available. All of the delegates that fail to respond to GetMeta during initialization
would be specially tagged. The aggregate would first send a ping to a tagged delegate before
sending a CAS. A CAS would be placed in the pending queue until the delegate becomes available.
I see a potential for a hang here if the delegate *doesnt* become available. The CAS Pool
will be drained and all CASes will pile up in the pending queue of the delegate that is not
available
Also, the assumption is that a delegate joining late has a compatible time system. By the
time the delegate becomes available the aggregate has already initialized and created a Cas
Pool. What is a mechanism for validating a typesystem that is send back by a delegated that
uses XMI?


> Services that timeout should be handled differently on subsequent requests
> --------------------------------------------------------------------------
>
>                 Key: UIMA-1127
>                 URL: https://issues.apache.org/jira/browse/UIMA-1127
>             Project: UIMA
>          Issue Type: Improvement
>          Components: Async Scaleout
>    Affects Versions: 2.2.2
>            Reporter: Eddie Epstein
>            Assignee: Jerry Cwiklik
>         Attachments: uimaj-as-activemq-UIMA-1127-patch-FixesClientApiPing.txt, uimaj-as-activemq-UIMA-1127-patch.txt,
uimaj-as-core-UIMA-1127-patch-FixesClientApiPing.txt, uimaj-as-core-UIMA-1127-patch-PingTimeoutEH.txt,
uimaj-as-core-UIMA-1127-patch.txt, uimaj-as-jms-UIMA-1127-patch-FixesClientApiPing.txt, uimaj-as-jms-UIMA-1127-patch-PingTimeoutAbort.txt,
uimaj-as-jms-UIMA-1127-patch-PingTimeoutEH.txt, uimaj-as-jms-UIMA-1127-patch.txt
>
>
> When a request times out, the service should be put into a "questionable" state. Requests
to a service in questionable state will then use a different logic: first send a getMeta request
with a short timeout; if the getMeta succeeds, the questionable state is removed and the normal
request is sent; if getMeta fails, an error is returned for the request with the state unchanged.
> This logic should be used for both API and aggregate clients.

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


Mime
View raw message