[
https://issues.apache.org/jira/browse/CXF-6454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15255134#comment-15255134
]
ASF GitHub Bot commented on CXF-6454:
-------------------------------------
Github user dhpatel27 commented on the pull request:
https://github.com/apache/cxf/pull/132#issuecomment-213663398
@cschneider The use case for point-1 mentioned by me above is when the
application wants the flexibility to stop the retries after certain number of
attempts if the Connection couldnt be established to JMS queue managers or JMS
Destinations itself. The client may not like to continue the retry infinite
times due to the CPU Spikes that they can experience unnecessarily after every
completion of thread.sleep. Also, this situation becomes worst if a single JVM
has >50 JMS Destination Listeners defined and a single physical host has
multiple such JVMs. In such scenario, client would still see high CPU when it
continues to do infinite retries. Thus it makes sense to give flexibility to
client in terms of exposing both retries and retryinterval.
Also for point 2, I was trying to avoid need for client to put custom
solution to call explicitly shutdown on JMSDestination as well. ALso, if you
note, shutdown variable is proned to race condition since its not defined
volatile. If you call shutdown from another Thread, and the retry thread is
still looping in another thread, the change in the value of shutdown variable
may not be instantaenously visible to other thread.
Thanks!
> Orphaned JMS connections created in endless loop
> ------------------------------------------------
>
> Key: CXF-6454
> URL: https://issues.apache.org/jira/browse/CXF-6454
> Project: CXF
> Issue Type: Bug
> Components: JMS, Transports
> Affects Versions: 3.0.5
> Reporter: Waldemar Szostak
> Assignee: Christian Schneider
> Priority: Critical
> Fix For: 3.0.7, 3.1.7, 3.2.0
>
>
> h3. Problem description
> In JMSFactory.createConnection(JMSConfiguration):
> {code}public static Connection createConnection(JMSConfiguration jmsConfig)
> throws JMSException {
> String username = jmsConfig.getUserName();
> ConnectionFactory cf = jmsConfig.getConnectionFactory();
> Connection connection = username != null
> ? cf.createConnection(username, jmsConfig.getPassword())
> : cf.createConnection();
> if (jmsConfig.getDurableSubscriptionClientId() != null) {
>
> connection.setClientID(jmsConfig.getDurableSubscriptionClientId());
> }
> return connection;
> }{code}
> there is no exception handling if the clientID fails to be set. Such an
> exception would exit this method without passing the reference to the
> just-opened JMS connection to exception handling code
> (JMSDestination.createTargetDestinationListener()).
> Moreover, JMSDestination.restartConnection() keeps on starting new
> connections (there is no max attempt restriction!) until it creates one
> without an exception thrown in the process.
> Now, if the clientID is already connected to the ESB, this creation of new
> connection will last until server resources are no longer available to the
> JVM.
> h3. Possible solution
> # Close the connection if it's not possible to set the specified clientID at
> the time:
> {code}public static Connection createConnection(JMSConfiguration jmsConfig)
> throws JMSException {
> String username = jmsConfig.getUserName();
> ConnectionFactory cf = jmsConfig.getConnectionFactory();
> Connection connection = username != null
> ? cf.createConnection(username,
> jmsConfig.getPassword())
> : cf.createConnection();
> if (jmsConfig.getDurableSubscriptionClientId() != null) {
> try {
> connection.setClientID(jmsConfig.getDurableSubscriptionClientId());
> } catch (InvalidClientIDException e) {
> connection.close();
> throw e;
> }
> }
> return connection;
> }{code}
> # Add a setting to restrict the maximum attempts to restart the connection in
> JMSDestination.restartConnection() A configurable value would be best, but
> even a hardcoded.. anything but the practically endless loop ;-)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
