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