You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Jerry Cwiklik (JIRA)" <ui...@incubator.apache.org> on 2009/02/05 16:33:59 UTC

[jira] Reopened: (UIMA-1127) Services that timeout should be handled differently on subsequent requests

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