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 2008/03/04 19:15:40 UTC

[jira] Created: (UIMA-844) Add connection recovery for temp queues in the JMS Listener object

Add connection recovery for temp queues in the JMS Listener object
------------------------------------------------------------------

                 Key: UIMA-844
                 URL: https://issues.apache.org/jira/browse/UIMA-844
             Project: UIMA
          Issue Type: Improvement
          Components: Async Scaleout
    Affects Versions: 2.2.1
            Reporter: Jerry Cwiklik


When a connection to a temp queue is broken, the JMS listener is not set up to recover it. Part of the recovery should be a creation of a new queue. 

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


[jira] Commented: (UIMA-844) Add connection recovery for temp queues in the JMS Listener object

Posted by "Burn Lewis (JIRA)" <ui...@incubator.apache.org>.
    [ https://issues.apache.org/jira/browse/UIMA-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624494#action_12624494 ] 

Burn Lewis commented on UIMA-844:
---------------------------------

What's the plan for this?  When a network glitch causes us to lose the connection uima doesn't report the error but generates error messages for the rest of the run.  We eventually get a timeout error and disable the component, which tempts us to falsely blame the service provider.

> Add connection recovery for temp queues in the JMS Listener object
> ------------------------------------------------------------------
>
>                 Key: UIMA-844
>                 URL: https://issues.apache.org/jira/browse/UIMA-844
>             Project: UIMA
>          Issue Type: Improvement
>          Components: Async Scaleout
>    Affects Versions: 2.2.1
>            Reporter: Jerry Cwiklik
>
> When a connection to a temp queue is broken, the JMS listener is not set up to recover it. Part of the recovery should be a creation of a new queue. 

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


[jira] Updated: (UIMA-844) Add connection recovery for temp queues in the JMS Listener object

Posted by "Jerry Cwiklik (JIRA)" <ui...@incubator.apache.org>.
     [ https://issues.apache.org/jira/browse/UIMA-844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jerry Cwiklik updated UIMA-844:
-------------------------------

    Attachment: uimaj-as-jms-UIMA-844-patch.txt
                uimaj-as-core-UIMA-844-patch.txt
                uimaj-as-activemq-UIMA-844-patch.txt

Added support to recover a lost connection to a remote temp queue. If a connection to a temp queue is lost, a listener to the queue is stopped and an endpoint to a remote delegate is marked as failed. Before sending a CAS to the delegate, the code checks the state of the Endpoint. If the state=FAILED, a new temp queue for replies is created along with a new listener for that queue. Once the listener is successfully created and initialized the CAS is sent to the remote delegate. The outgoing message will contain a new replyTo temp queue.

Removed hard-coded retry logic from JmsEndpointConnection_impl. This logic tried to to auto-recover lost connection 10 times. Retries are now subject to error handling and thresholds defined in the deployment descriptor for each delegate.

Reduced Spring recovery delay from 60000ms to 5ms. When a connection fails, Spring notifies UIMA-As listener code immediately instead of waiting for 60000ms.

> Add connection recovery for temp queues in the JMS Listener object
> ------------------------------------------------------------------
>
>                 Key: UIMA-844
>                 URL: https://issues.apache.org/jira/browse/UIMA-844
>             Project: UIMA
>          Issue Type: Improvement
>          Components: Async Scaleout
>    Affects Versions: 2.2.1
>            Reporter: Jerry Cwiklik
>         Attachments: uimaj-as-activemq-UIMA-844-patch.txt, uimaj-as-core-UIMA-844-patch.txt, uimaj-as-jms-UIMA-844-patch.txt
>
>
> When a connection to a temp queue is broken, the JMS listener is not set up to recover it. Part of the recovery should be a creation of a new queue. 

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


[jira] Commented: (UIMA-844) Add connection recovery for temp queues in the JMS Listener object

Posted by "Jerry Cwiklik (JIRA)" <ui...@incubator.apache.org>.
    [ https://issues.apache.org/jira/browse/UIMA-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612953#action_12612953 ] 

Jerry Cwiklik commented on UIMA-844:
------------------------------------

Also as part of this work, address connect retries in the JmsOutputChannel. When a connection to a temp queue fails while sending a reply, dont do retries. 

> Add connection recovery for temp queues in the JMS Listener object
> ------------------------------------------------------------------
>
>                 Key: UIMA-844
>                 URL: https://issues.apache.org/jira/browse/UIMA-844
>             Project: UIMA
>          Issue Type: Improvement
>          Components: Async Scaleout
>    Affects Versions: 2.2.1
>            Reporter: Jerry Cwiklik
>
> When a connection to a temp queue is broken, the JMS listener is not set up to recover it. Part of the recovery should be a creation of a new queue. 

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


[jira] Commented: (UIMA-844) Add connection recovery for temp queues in the JMS Listener object

Posted by "Eddie Epstein (JIRA)" <ui...@incubator.apache.org>.
    [ https://issues.apache.org/jira/browse/UIMA-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617055#action_12617055 ] 

Eddie Epstein commented on UIMA-844:
------------------------------------

The recovery operation should only be done on the next request, not before. On the next request, if a new session with the delegate input queue cannot be established, the request immediately fails. If the session succeeds, then a new reply queue is created and the request sent.

> Add connection recovery for temp queues in the JMS Listener object
> ------------------------------------------------------------------
>
>                 Key: UIMA-844
>                 URL: https://issues.apache.org/jira/browse/UIMA-844
>             Project: UIMA
>          Issue Type: Improvement
>          Components: Async Scaleout
>    Affects Versions: 2.2.1
>            Reporter: Jerry Cwiklik
>
> When a connection to a temp queue is broken, the JMS listener is not set up to recover it. Part of the recovery should be a creation of a new queue. 

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


[jira] Closed: (UIMA-844) Add connection recovery for temp queues in the JMS Listener object

Posted by "Jerry Cwiklik (JIRA)" <ui...@incubator.apache.org>.
     [ https://issues.apache.org/jira/browse/UIMA-844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jerry Cwiklik closed UIMA-844.
------------------------------

    Resolution: Fixed

> Add connection recovery for temp queues in the JMS Listener object
> ------------------------------------------------------------------
>
>                 Key: UIMA-844
>                 URL: https://issues.apache.org/jira/browse/UIMA-844
>             Project: UIMA
>          Issue Type: Improvement
>          Components: Async Scaleout
>    Affects Versions: 2.2.1
>            Reporter: Jerry Cwiklik
>         Attachments: uimaj-as-activemq-UIMA-844-patch.txt, uimaj-as-core-UIMA-844-patch.txt, uimaj-as-jms-UIMA-844-patch.txt
>
>
> When a connection to a temp queue is broken, the JMS listener is not set up to recover it. Part of the recovery should be a creation of a new queue. 

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