You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by "Torsten Mielke (Created) (JIRA)" <ji...@apache.org> on 2011/11/04 10:49:00 UTC

[jira] [Created] (CAMEL-4616) register exception listener with camel-jms producer endpoint

register exception listener with camel-jms producer endpoint
------------------------------------------------------------

                 Key: CAMEL-4616
                 URL: https://issues.apache.org/jira/browse/CAMEL-4616
             Project: Camel
          Issue Type: Improvement
          Components: camel-jms
    Affects Versions: 2.8.2
         Environment: camel-jms producer sending to ActiveMQ 
            Reporter: Torsten Mielke


camel-jms should register an exception listener automatically when used as a producer. That way it can deal with any exception that may occur on async sends.

To be more precise:
If a camel-jms producer sends a msg within a transaction to an ActiveMQ broker, then this send happens async by default (kind of an optimization done by ActiveMQ). If anything goes wrong with the send (e.g. broker raises a javax.jms.ResourceAllocationException because its full or there is a transport problem) then we currently don't catch this exception as there is no async exception listener registered. What's worse the TX will be committed thereafter although the async send has actually failed.
As a result the msg is lost. 
For ActiveMQ there is a simple solution to this problem: either
- set jms.useAsyncSend=false on the broker URL, or
- call setAlwaysSyncSend(true) on the ActiveMQConnectionFactory


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Updated] (CAMEL-4616) register exception listener with camel-jms producer endpoint

Posted by "Torsten Mielke (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CAMEL-4616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Torsten Mielke updated CAMEL-4616:
----------------------------------

    Description: 
camel-jms should register an exception listener automatically when used as a message producer. That way it can deal with any exception that may occur on async sends.

To be more precise:
If a camel-jms producer sends a msg within a transaction to an ActiveMQ broker, then this message send happens async by default (kind of an optimization done by ActiveMQ). If anything goes wrong with the send (e.g. broker raises a javax.jms.ResourceAllocationException because its full or there is a transport problem) then we currently don't catch this exception as there is no async exception listener registered. What's worse the TX will be committed thereafter although the send has actually failed.
As a result the msg is lost. 

For ActiveMQ there is a simple solution to this problem, either
- set jms.useAsyncSend=false on the broker URL, or
- call setAlwaysSyncSend(true) on the ActiveMQConnectionFactory


However many users won't be aware of this solution and will simply assume that using a transaction is enough to guard against message loss. 
Also the same problem can potentially arise with other JMS providers if they also use async send within a transaction. 

Camel should ensure that the out of the box behavior prevents from loosing msgs in transactional sends.



  was:
camel-jms should register an exception listener automatically when used as a producer. That way it can deal with any exception that may occur on async sends.

To be more precise:
If a camel-jms producer sends a msg within a transaction to an ActiveMQ broker, then this send happens async by default (kind of an optimization done by ActiveMQ). If anything goes wrong with the send (e.g. broker raises a javax.jms.ResourceAllocationException because its full or there is a transport problem) then we currently don't catch this exception as there is no async exception listener registered. What's worse the TX will be committed thereafter although the async send has actually failed.
As a result the msg is lost. 
For ActiveMQ there is a simple solution to this problem: either
- set jms.useAsyncSend=false on the broker URL, or
- call setAlwaysSyncSend(true) on the ActiveMQConnectionFactory


However many users won't be aware of this solution and will surely assume that using a transaction is enough to guard against message loss. 
Also, the same problem can arise with other JMS providers if they also use async send within a transaction. 

Camel should ensure that the out of the box behavior prevents from loosing msgs in transactional sends.



    
> register exception listener with camel-jms producer endpoint
> ------------------------------------------------------------
>
>                 Key: CAMEL-4616
>                 URL: https://issues.apache.org/jira/browse/CAMEL-4616
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-jms
>    Affects Versions: 2.8.2
>         Environment: camel-jms producer sending to ActiveMQ 
>            Reporter: Torsten Mielke
>              Labels: transactions
>
> camel-jms should register an exception listener automatically when used as a message producer. That way it can deal with any exception that may occur on async sends.
> To be more precise:
> If a camel-jms producer sends a msg within a transaction to an ActiveMQ broker, then this message send happens async by default (kind of an optimization done by ActiveMQ). If anything goes wrong with the send (e.g. broker raises a javax.jms.ResourceAllocationException because its full or there is a transport problem) then we currently don't catch this exception as there is no async exception listener registered. What's worse the TX will be committed thereafter although the send has actually failed.
> As a result the msg is lost. 
> For ActiveMQ there is a simple solution to this problem, either
> - set jms.useAsyncSend=false on the broker URL, or
> - call setAlwaysSyncSend(true) on the ActiveMQConnectionFactory
> However many users won't be aware of this solution and will simply assume that using a transaction is enough to guard against message loss. 
> Also the same problem can potentially arise with other JMS providers if they also use async send within a transaction. 
> Camel should ensure that the out of the box behavior prevents from loosing msgs in transactional sends.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Updated] (CAMEL-4616) register exception listener with camel-jms producer endpoint

Posted by "Torsten Mielke (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CAMEL-4616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Torsten Mielke updated CAMEL-4616:
----------------------------------

    Description: 
camel-jms should register an exception listener automatically when used as a producer. That way it can deal with any exception that may occur on async sends.

To be more precise:
If a camel-jms producer sends a msg within a transaction to an ActiveMQ broker, then this send happens async by default (kind of an optimization done by ActiveMQ). If anything goes wrong with the send (e.g. broker raises a javax.jms.ResourceAllocationException because its full or there is a transport problem) then we currently don't catch this exception as there is no async exception listener registered. What's worse the TX will be committed thereafter although the async send has actually failed.
As a result the msg is lost. 
For ActiveMQ there is a simple solution to this problem: either
- set jms.useAsyncSend=false on the broker URL, or
- call setAlwaysSyncSend(true) on the ActiveMQConnectionFactory


However many users won't be aware of this solution and will surely assume that using a transaction is enough to guard against message loss. 
Also, the same problem can arise with other JMS providers if they also use async send within a transaction. 

Camel should ensure that the out of the box behavior prevents from loosing msgs in transactional sends.



  was:
camel-jms should register an exception listener automatically when used as a producer. That way it can deal with any exception that may occur on async sends.

To be more precise:
If a camel-jms producer sends a msg within a transaction to an ActiveMQ broker, then this send happens async by default (kind of an optimization done by ActiveMQ). If anything goes wrong with the send (e.g. broker raises a javax.jms.ResourceAllocationException because its full or there is a transport problem) then we currently don't catch this exception as there is no async exception listener registered. What's worse the TX will be committed thereafter although the async send has actually failed.
As a result the msg is lost. 
For ActiveMQ there is a simple solution to this problem: either
- set jms.useAsyncSend=false on the broker URL, or
- call setAlwaysSyncSend(true) on the ActiveMQConnectionFactory


         Labels: transactions  (was: )
    
> register exception listener with camel-jms producer endpoint
> ------------------------------------------------------------
>
>                 Key: CAMEL-4616
>                 URL: https://issues.apache.org/jira/browse/CAMEL-4616
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-jms
>    Affects Versions: 2.8.2
>         Environment: camel-jms producer sending to ActiveMQ 
>            Reporter: Torsten Mielke
>              Labels: transactions
>
> camel-jms should register an exception listener automatically when used as a producer. That way it can deal with any exception that may occur on async sends.
> To be more precise:
> If a camel-jms producer sends a msg within a transaction to an ActiveMQ broker, then this send happens async by default (kind of an optimization done by ActiveMQ). If anything goes wrong with the send (e.g. broker raises a javax.jms.ResourceAllocationException because its full or there is a transport problem) then we currently don't catch this exception as there is no async exception listener registered. What's worse the TX will be committed thereafter although the async send has actually failed.
> As a result the msg is lost. 
> For ActiveMQ there is a simple solution to this problem: either
> - set jms.useAsyncSend=false on the broker URL, or
> - call setAlwaysSyncSend(true) on the ActiveMQConnectionFactory
> However many users won't be aware of this solution and will surely assume that using a transaction is enough to guard against message loss. 
> Also, the same problem can arise with other JMS providers if they also use async send within a transaction. 
> Camel should ensure that the out of the box behavior prevents from loosing msgs in transactional sends.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira