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

Ben Nisbet updated AMQ-6334:
----------------------------
    Affects Version/s:     (was: 5.10.2)
                       5.12.1
          Environment: WebLogic v10.3.6, HotSpot 64bit JVM 1.7.0_71  (was: 
WebLogic 10.3.6, JRockit JDK 1.6)
        Fix Version/s:     (was: 5.12.1)
                           (was: 5.13.0)
          Description: 
This defect was identified when proxying an outbound queue bridge's foreign 
connection through a load balancer with no available cluster nodes and is 
reported in the ActiveMQ broker log file with following DEBUG level event 
message:
 
DEBUG 2016-June-22 15:54:25,165 JmsConnector:627 - Failed to establish initial 
[foreign, 24388] connection for JmsConnector [javax.jms.JMSException: Cannot 
send, channel has already failed: tcp://0.0.0.0:61616]

 In ActiveMQ v5.12.1 release this is triggered by a ConnectionFailedException 
being thrown on line 190 of class 
org.apache.activemq.network.SimpleJmsQueueConnector and can be replicated by 
running the attached JUnit test.
 
Attached ActiveMQConnection subclass ensures that resource clean up is 
performed if any exception is thrown during an invocation of the start() 
method. Consequently instances are eligible for garbage collection if the 
underlying TCP connection is successfully established by constructor and then 
reset by peer before the connection is put into service. 

Is it possible to include this behaviour within the ActiveMQConnection class  
itself in future release?

  was:
When using an OutboundQueueBridge associated with a SimpleJmsQueueConnector 
bean I have observed the default ReconnectionPolicy.maxSendRetries value of 10 
to result in message loss if the connection to destination server is 
unreliable. (messages that are not delivered to destination within 
maxSendRetries are still acknowledged as having been consumed by processing of 
later messages)

Is it possible for the 
org.apache.activemq.network.jms.DestinationBridge.onMessage() implementation to 
interpret a ReconnectionPolicy.maxSendRetries property value of -1 as infinity?






          Component/s: JMS client
           Issue Type: Bug  (was: Improvement)

> ActiveMQConnection triggered heap space out of memory error when used with 
> org.apache.activemq.network.SimpleJmsQueueConnector
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-6334
>                 URL: https://issues.apache.org/jira/browse/AMQ-6334
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker, JMS client
>    Affects Versions: 5.12.1
>         Environment: WebLogic v10.3.6, HotSpot 64bit JVM 1.7.0_71
>            Reporter: Ben Nisbet
>
> This defect was identified when proxying an outbound queue bridge's foreign 
> connection through a load balancer with no available cluster nodes and is 
> reported in the ActiveMQ broker log file with following DEBUG level event 
> message:
>  
> DEBUG 2016-June-22 15:54:25,165 JmsConnector:627 - Failed to establish 
> initial [foreign, 24388] connection for JmsConnector [javax.jms.JMSException: 
> Cannot send, channel has already failed: tcp://0.0.0.0:61616]
>  In ActiveMQ v5.12.1 release this is triggered by a ConnectionFailedException 
> being thrown on line 190 of class 
> org.apache.activemq.network.SimpleJmsQueueConnector and can be replicated by 
> running the attached JUnit test.
>  
> Attached ActiveMQConnection subclass ensures that resource clean up is 
> performed if any exception is thrown during an invocation of the start() 
> method. Consequently instances are eligible for garbage collection if the 
> underlying TCP connection is successfully established by constructor and then 
> reset by peer before the connection is put into service. 
> Is it possible to include this behaviour within the ActiveMQConnection class  
> itself in future release?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to