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/11/10 23:17:28 UTC

[jira] Closed: (UIMA-1643) UIMA AS client does not recover correctly when the connection to a broker fails

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

Jerry Cwiklik closed UIMA-1643.
-------------------------------

    Resolution: Fixed

Modified UIMA AS client to detect broker connection failure and recover from it. Before sending a new request the client checks the state of its connection. If the connection is invalid, the client enters a loop where it tries to create a new connection every 5 seconds. The recovery is silent except for an initial notification. The recovery is terminated when all UIMA AS clients (sharing a connection) terminate or the the connection is recovered. While a new connection is retried, CASes submitted by an application client are either rejected immediately or timeout. If the application client uses sendAndReceive() synchronous API, the failure will be delivered by an exception. If the application client uses sendCAS() asynchronous API, the failure will be delivered via a listener the application registered with the UIMA AS client.

> UIMA AS client does not recover correctly when the connection to a broker fails
> -------------------------------------------------------------------------------
>
>                 Key: UIMA-1643
>                 URL: https://issues.apache.org/jira/browse/UIMA-1643
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout
>            Reporter: Jerry Cwiklik
>            Priority: Blocker
>             Fix For: 2.3AS
>
>
> When the connection to the broker is lost, the UIMA AS client does not attempt to reconnect as it is done in the UIMA AS service. When the jms send() fails due to a lost connection, the UIMA AS client notifies the application but in addition should log a single message that the connection was lost  and enter a recovery loop attempting to reconnect at regular intervals. Any failures during this recovery should be silently handled. If the application does not want to recover from a bad connection it should call stop() on the client API which will stop the recovery, cleanup resources and terminate the UIMA AS client.

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