You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Eddie Epstein (JIRA)" <ui...@incubator.apache.org> on 2008/07/25 23:07:31 UTC
[jira] Created: (UIMA-1127) Services that timeout should be handled
differently on subsequent requests
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
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.
[jira] Commented: (UIMA-1127) Services that timeout should be
handled differently on subsequent requests
Posted by "Jerry Cwiklik (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645053#action_12645053 ]
Jerry Cwiklik commented on UIMA-1127:
-------------------------------------
If the client is an aggregate and the getMeta PING msg fails (due to timeout), should the aggregate apply an action (disable/terminate/none) as defined in the DD for the delegate before returning exception back to its client?
> 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
>
> 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.
[jira] Reopened: (UIMA-1127) Services that timeout should be
handled differently on subsequent requests
Posted by "Jerry Cwiklik (JIRA)" <ui...@incubator.apache.org>.
[ 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.
[jira] Updated: (UIMA-1127) Services that timeout should be handled
differently on subsequent requests
Posted by "Jerry Cwiklik (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jerry Cwiklik updated UIMA-1127:
--------------------------------
Attachment: uimaj-as-jms-UIMA-1127-patch-PingTimeoutEH.txt
uimaj-as-core-UIMA-1127-patch-PingTimeoutEH.txt
Modified how ping timeout is handled. When the ping times out, the CasProcessErrorHandler is called instead of GetMetaErrorHandler. The CasProcessErrorHandler is given an id of the oldest CAS found in the list of CASes pending reply. Apply all previous patches before applying ones that end with -PingTimeoutEH.txt
> 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.txt, uimaj-as-core-UIMA-1127-patch-PingTimeoutEH.txt, uimaj-as-core-UIMA-1127-patch.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.
[jira] Updated: (UIMA-1127) Services that timeout should be handled
differently on subsequent requests
Posted by "Jerry Cwiklik (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jerry Cwiklik updated UIMA-1127:
--------------------------------
Attachment: uimaj-as-jms-UIMA-1127-patch-FixesClientApiPing.txt
uimaj-as-core-UIMA-1127-patch-FixesClientApiPing.txt
uimaj-as-activemq-UIMA-1127-patch-FixesClientApiPing.txt
Removed method level synchronization on sendCAS and replaced it with a dedicated mux object.
Fixed a bug in a client API that was causing a Ping message to be sent immediately after Process timeout. The new code sends a Ping on a subsequent CAS process request.
Modified testcase error handler to stop the client api on Ping Timeout.
> 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.
[jira] Updated: (UIMA-1127) Services that timeout should be handled
differently on subsequent requests
Posted by "Jerry Cwiklik (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jerry Cwiklik updated UIMA-1127:
--------------------------------
Attachment: uimaj-as-jms-UIMA-1127-patch-PingTimeoutAbort.txt
Modified sendAndReceive() code to check the 'abort' flag and return exception if the flag is set. This is done to prevent the send thread from processing a reply *while* the client API is trying to shutdown.
> 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.txt, uimaj-as-core-UIMA-1127-patch-PingTimeoutEH.txt, uimaj-as-core-UIMA-1127-patch.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.
[jira] Closed: (UIMA-1127) Services that timeout should be handled
differently on subsequent requests
Posted by "Jerry Cwiklik (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jerry Cwiklik closed UIMA-1127.
-------------------------------
Resolution: Fixed
> 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.
[jira] Closed: (UIMA-1127) Services that timeout should be handled
differently on subsequent requests
Posted by "Jerry Cwiklik (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jerry Cwiklik closed UIMA-1127.
-------------------------------
Resolution: Fixed
On ping timeout the current code uses action associated with the Process not GetMeta as the comment states. Nothing else needed.
> 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.
[jira] Updated: (UIMA-1127) Services that timeout should be handled
differently on subsequent requests
Posted by "Jerry Cwiklik (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jerry Cwiklik updated UIMA-1127:
--------------------------------
Attachment: uimaj-as-jms-UIMA-1127-patch.txt
uimaj-as-core-UIMA-1127-patch.txt
uimaj-as-activemq-UIMA-1127-patch.txt
When a UIMA-AS client gets a timeout while waiting for a process reply, it marks the internal state of a service as TimedOut. The client will send a GetMeta request to the service as a sort of a PING to check if the service is available. While the client is awaiting a reply from the PING any CASes that are destined for this service will be delayed and placed on a list of CASes pending dispatch. When the service replies to the PING, its state is reset to normal and all pending CASes are immediately dispatched. When the PING times out its an indication that the service is no longer available. The client API will stop sending CASes. In case of Aggregate client, the PING timeout is subject to the same error handling as the GetMeta timeout. If the delegate is to be disabled on getMeta timeout, all CASes that were delayed and all CASes that are outstanding (waiting for a reply) will be sent through an Error Handler with explicit TimeoutException.
> 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.txt, uimaj-as-core-UIMA-1127-patch.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.