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/07/12 20:37:15 UTC

[jira] Created: (UIMA-1433) UIMA AS service creates too many JMS connections

UIMA AS service creates too many JMS connections 
-------------------------------------------------

                 Key: UIMA-1433
                 URL: https://issues.apache.org/jira/browse/UIMA-1433
             Project: UIMA
          Issue Type: Bug
          Components: Async Scaleout
            Reporter: Jerry Cwiklik
            Assignee: Jerry Cwiklik


UIMA AS service maintains connections to client's reply queue. These connections are cached and reused. When the connection becomes idle for too long, it is closed. Current default connection timeout is set to 30 minutes. This value can be changed via System property -DSessionTimeoutOverride=n.
JMS Connections are expensive, and if too many are created the broker may become unstable. As optimization, the service should create a single JMS connection (per broker) and use it to create jms sessions and message producers for each client. This change will  reduce number of threads the broker needs to manage in deployments where clients and services use a single broker for messaging.  


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


[jira] Closed: (UIMA-1433) UIMA AS service creates too many JMS connections

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

Jerry Cwiklik closed UIMA-1433.
-------------------------------

    Resolution: Fixed

Modified JmsEndpointConnection_impl openChannel() method to check if connection exists in the cache before creating a new one.  

> UIMA AS service creates too many JMS connections 
> -------------------------------------------------
>
>                 Key: UIMA-1433
>                 URL: https://issues.apache.org/jira/browse/UIMA-1433
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout
>            Reporter: Jerry Cwiklik
>            Assignee: Jerry Cwiklik
>
> UIMA AS service maintains connections to client's reply queue. These connections are cached and reused. When the connection becomes idle for too long, it is closed. Current default connection timeout is set to 30 minutes. This value can be changed via System property -DSessionTimeoutOverride=n.
> JMS Connections are expensive, and if too many are created the broker may become unstable. As optimization, the service should create a single JMS connection (per broker) and use it to create jms sessions and message producers for each client. This change will  reduce number of threads the broker needs to manage in deployments where clients and services use a single broker for messaging.  

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


[jira] Commented: (UIMA-1433) UIMA AS service creates too many JMS connections

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

Jerry Cwiklik commented on UIMA-1433:
-------------------------------------

Modified service code to create a single jms connection per broker and use it to create jms sessions and message producers when replying to a client. Each client sends to a service a broker URL and a reply destination object. These are used by the service to send replies. The service uses a cache to lookup endpoint connection object associated with every client. This object is created once and than is cached for subsequent reuse. This change reduces number of threads in the broker and tunnels reply messages through a single JMS connection to many clients.

> UIMA AS service creates too many JMS connections 
> -------------------------------------------------
>
>                 Key: UIMA-1433
>                 URL: https://issues.apache.org/jira/browse/UIMA-1433
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout
>            Reporter: Jerry Cwiklik
>            Assignee: Jerry Cwiklik
>
> UIMA AS service maintains connections to client's reply queue. These connections are cached and reused. When the connection becomes idle for too long, it is closed. Current default connection timeout is set to 30 minutes. This value can be changed via System property -DSessionTimeoutOverride=n.
> JMS Connections are expensive, and if too many are created the broker may become unstable. As optimization, the service should create a single JMS connection (per broker) and use it to create jms sessions and message producers for each client. This change will  reduce number of threads the broker needs to manage in deployments where clients and services use a single broker for messaging.  

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


[jira] Reopened: (UIMA-1433) UIMA AS service creates too many JMS connections

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

Jerry Cwiklik reopened UIMA-1433:
---------------------------------


OutputChannel is not caching JMS connections properly leaving stale connections in a broker.

> UIMA AS service creates too many JMS connections 
> -------------------------------------------------
>
>                 Key: UIMA-1433
>                 URL: https://issues.apache.org/jira/browse/UIMA-1433
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout
>            Reporter: Jerry Cwiklik
>            Assignee: Jerry Cwiklik
>
> UIMA AS service maintains connections to client's reply queue. These connections are cached and reused. When the connection becomes idle for too long, it is closed. Current default connection timeout is set to 30 minutes. This value can be changed via System property -DSessionTimeoutOverride=n.
> JMS Connections are expensive, and if too many are created the broker may become unstable. As optimization, the service should create a single JMS connection (per broker) and use it to create jms sessions and message producers for each client. This change will  reduce number of threads the broker needs to manage in deployments where clients and services use a single broker for messaging.  

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


[jira] Closed: (UIMA-1433) UIMA AS service creates too many JMS connections

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

Jerry Cwiklik closed UIMA-1433.
-------------------------------

    Resolution: Fixed

Reduced number of connections to a Broker managing reply queues. 

> UIMA AS service creates too many JMS connections 
> -------------------------------------------------
>
>                 Key: UIMA-1433
>                 URL: https://issues.apache.org/jira/browse/UIMA-1433
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout
>            Reporter: Jerry Cwiklik
>            Assignee: Jerry Cwiklik
>
> UIMA AS service maintains connections to client's reply queue. These connections are cached and reused. When the connection becomes idle for too long, it is closed. Current default connection timeout is set to 30 minutes. This value can be changed via System property -DSessionTimeoutOverride=n.
> JMS Connections are expensive, and if too many are created the broker may become unstable. As optimization, the service should create a single JMS connection (per broker) and use it to create jms sessions and message producers for each client. This change will  reduce number of threads the broker needs to manage in deployments where clients and services use a single broker for messaging.  

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


[jira] Reopened: (UIMA-1433) UIMA AS service creates too many JMS connections

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

Jerry Cwiklik reopened UIMA-1433:
---------------------------------


Cleanup global connection Map when inactivity timer on a reply queue pops

> UIMA AS service creates too many JMS connections 
> -------------------------------------------------
>
>                 Key: UIMA-1433
>                 URL: https://issues.apache.org/jira/browse/UIMA-1433
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout
>            Reporter: Jerry Cwiklik
>            Assignee: Jerry Cwiklik
>
> UIMA AS service maintains connections to client's reply queue. These connections are cached and reused. When the connection becomes idle for too long, it is closed. Current default connection timeout is set to 30 minutes. This value can be changed via System property -DSessionTimeoutOverride=n.
> JMS Connections are expensive, and if too many are created the broker may become unstable. As optimization, the service should create a single JMS connection (per broker) and use it to create jms sessions and message producers for each client. This change will  reduce number of threads the broker needs to manage in deployments where clients and services use a single broker for messaging.  

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


[jira] Closed: (UIMA-1433) UIMA AS service creates too many JMS connections

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

Jerry Cwiklik closed UIMA-1433.
-------------------------------

    Resolution: Fixed

> UIMA AS service creates too many JMS connections 
> -------------------------------------------------
>
>                 Key: UIMA-1433
>                 URL: https://issues.apache.org/jira/browse/UIMA-1433
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout
>            Reporter: Jerry Cwiklik
>            Assignee: Jerry Cwiklik
>
> UIMA AS service maintains connections to client's reply queue. These connections are cached and reused. When the connection becomes idle for too long, it is closed. Current default connection timeout is set to 30 minutes. This value can be changed via System property -DSessionTimeoutOverride=n.
> JMS Connections are expensive, and if too many are created the broker may become unstable. As optimization, the service should create a single JMS connection (per broker) and use it to create jms sessions and message producers for each client. This change will  reduce number of threads the broker needs to manage in deployments where clients and services use a single broker for messaging.  

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


[jira] Closed: (UIMA-1433) UIMA AS service creates too many JMS connections

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

Jerry Cwiklik closed UIMA-1433.
-------------------------------

    Resolution: Invalid

The UIMA AS service is unable to recover from broker failure and subsequent restart. This deserves its own JIRA. Opened this by mistake.

> UIMA AS service creates too many JMS connections 
> -------------------------------------------------
>
>                 Key: UIMA-1433
>                 URL: https://issues.apache.org/jira/browse/UIMA-1433
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout
>            Reporter: Jerry Cwiklik
>            Assignee: Jerry Cwiklik
>             Fix For: 2.3AS
>
>
> UIMA AS service maintains connections to client's reply queue. These connections are cached and reused. When the connection becomes idle for too long, it is closed. Current default connection timeout is set to 30 minutes. This value can be changed via System property -DSessionTimeoutOverride=n.
> JMS Connections are expensive, and if too many are created the broker may become unstable. As optimization, the service should create a single JMS connection (per broker) and use it to create jms sessions and message producers for each client. This change will  reduce number of threads the broker needs to manage in deployments where clients and services use a single broker for messaging.  

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


[jira] Updated: (UIMA-1433) UIMA AS service creates too many JMS connections

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

Jerry Cwiklik updated UIMA-1433:
--------------------------------

    Comment: was deleted

(was: UIMA AS service is not recovering properly when the broker is stopped and restarted. When the broker is bounced the service should invalidate its connection cache and create a new one. It should also invalidate all sessions and producers associated with a stale connection. The aggregate service with remote delegates will appear hung if the broker is bounced.)

> UIMA AS service creates too many JMS connections 
> -------------------------------------------------
>
>                 Key: UIMA-1433
>                 URL: https://issues.apache.org/jira/browse/UIMA-1433
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout
>            Reporter: Jerry Cwiklik
>            Assignee: Jerry Cwiklik
>             Fix For: 2.3AS
>
>
> UIMA AS service maintains connections to client's reply queue. These connections are cached and reused. When the connection becomes idle for too long, it is closed. Current default connection timeout is set to 30 minutes. This value can be changed via System property -DSessionTimeoutOverride=n.
> JMS Connections are expensive, and if too many are created the broker may become unstable. As optimization, the service should create a single JMS connection (per broker) and use it to create jms sessions and message producers for each client. This change will  reduce number of threads the broker needs to manage in deployments where clients and services use a single broker for messaging.  

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


[jira] Closed: (UIMA-1433) UIMA AS service creates too many JMS connections

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

Jerry Cwiklik closed UIMA-1433.
-------------------------------

    Resolution: Fixed

Improved detection of bad jms connection in the uima as client. This improvement detects connections that are in a bad state due to "Inactivity Timeout'. Such connection is closed and reopened before sending next CAS.

> UIMA AS service creates too many JMS connections 
> -------------------------------------------------
>
>                 Key: UIMA-1433
>                 URL: https://issues.apache.org/jira/browse/UIMA-1433
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout
>            Reporter: Jerry Cwiklik
>            Assignee: Jerry Cwiklik
>             Fix For: 2.3AS
>
>
> UIMA AS service maintains connections to client's reply queue. These connections are cached and reused. When the connection becomes idle for too long, it is closed. Current default connection timeout is set to 30 minutes. This value can be changed via System property -DSessionTimeoutOverride=n.
> JMS Connections are expensive, and if too many are created the broker may become unstable. As optimization, the service should create a single JMS connection (per broker) and use it to create jms sessions and message producers for each client. This change will  reduce number of threads the broker needs to manage in deployments where clients and services use a single broker for messaging.  

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


[jira] Reopened: (UIMA-1433) UIMA AS service creates too many JMS connections

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

Jerry Cwiklik reopened UIMA-1433:
---------------------------------


Improve detection of a bad JMS connection in JmsEndpointConnection_impl.openChannel()  In the current code a new connection is created only if the cache reports it to be null:

brokerDestinations.getConnection() == null

The above test is not sufficient as the connection can be in a stale state due to Inactivity Timeout. Check the state of the connection and create a new one when the state is bad. 

> UIMA AS service creates too many JMS connections 
> -------------------------------------------------
>
>                 Key: UIMA-1433
>                 URL: https://issues.apache.org/jira/browse/UIMA-1433
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout
>            Reporter: Jerry Cwiklik
>            Assignee: Jerry Cwiklik
>             Fix For: 2.3AS
>
>
> UIMA AS service maintains connections to client's reply queue. These connections are cached and reused. When the connection becomes idle for too long, it is closed. Current default connection timeout is set to 30 minutes. This value can be changed via System property -DSessionTimeoutOverride=n.
> JMS Connections are expensive, and if too many are created the broker may become unstable. As optimization, the service should create a single JMS connection (per broker) and use it to create jms sessions and message producers for each client. This change will  reduce number of threads the broker needs to manage in deployments where clients and services use a single broker for messaging.  

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


[jira] Reopened: (UIMA-1433) UIMA AS service creates too many JMS connections

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

Jerry Cwiklik reopened UIMA-1433:
---------------------------------


UIMA AS service is not recovering properly when the broker is stopped and restarted. When the broker is bounced the service should invalidate its connection cache and create a new one. It should also invalidate all sessions and producers associated with a stale connection. The aggregate service with remote delegates will appear hung if the broker is bounced.

> UIMA AS service creates too many JMS connections 
> -------------------------------------------------
>
>                 Key: UIMA-1433
>                 URL: https://issues.apache.org/jira/browse/UIMA-1433
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout
>            Reporter: Jerry Cwiklik
>            Assignee: Jerry Cwiklik
>             Fix For: 2.3AS
>
>
> UIMA AS service maintains connections to client's reply queue. These connections are cached and reused. When the connection becomes idle for too long, it is closed. Current default connection timeout is set to 30 minutes. This value can be changed via System property -DSessionTimeoutOverride=n.
> JMS Connections are expensive, and if too many are created the broker may become unstable. As optimization, the service should create a single JMS connection (per broker) and use it to create jms sessions and message producers for each client. This change will  reduce number of threads the broker needs to manage in deployments where clients and services use a single broker for messaging.  

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


[jira] Updated: (UIMA-1433) UIMA AS service creates too many JMS connections

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

Jerry Cwiklik updated UIMA-1433:
--------------------------------

    Fix Version/s: 2.3AS

> UIMA AS service creates too many JMS connections 
> -------------------------------------------------
>
>                 Key: UIMA-1433
>                 URL: https://issues.apache.org/jira/browse/UIMA-1433
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout
>            Reporter: Jerry Cwiklik
>            Assignee: Jerry Cwiklik
>             Fix For: 2.3AS
>
>
> UIMA AS service maintains connections to client's reply queue. These connections are cached and reused. When the connection becomes idle for too long, it is closed. Current default connection timeout is set to 30 minutes. This value can be changed via System property -DSessionTimeoutOverride=n.
> JMS Connections are expensive, and if too many are created the broker may become unstable. As optimization, the service should create a single JMS connection (per broker) and use it to create jms sessions and message producers for each client. This change will  reduce number of threads the broker needs to manage in deployments where clients and services use a single broker for messaging.  

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