Ndtyjky

I have a Camel route where the producer is an smb mount, and the consumer is an ActiveMQ queue.

I would like to rollback the transaction when SMB server is unable to delete the file from source SMB mount. This, however, happens during commit phase of the transaction.

I can intercept the exception when using onCompletionExceptionHandler, but the catching happens AFTER the Exchange object connected with the file is already sent to the target ActiveMQ.

Is there a way to prevent Camel from commiting the transaction in the first place or rolling back the transaction so that the message isn't sent to AMQ? This behaviour is present in Camel 2.17.2

Let's look into the different delivery patterns for messaging:

• 
  At least once - the message is deleted from source after it's delivered to target. Same message can be sent multiple times.
  
  
  
  
  • This is what you got now.
  
  
  
  


• 
  At most once - the message is deleted from source before it's delivered to target. Data can be lost.
  
  
  
  
  • Likely not what you want.
  
  
  
  


• 
  Exactly once - message will be deleted from source at the same time it's delivered to target.
  
  
  
  
  • The holy grail. Very hard to achieve.
  
  
  
  

Ok, so you essentially want a Exactly once semantics. That can "only" be achieved when moving data between queues in the same broker, between tables in a database or by moving a file on a local disk (or internally in the same "resource").

When you have multiple protocols/resources, it's almost impossible, or at least very hard. There are some ways to somewhat ensure exactly once delivery using "two phase commit" transactions using a distributed transaction coordinator, such as MSDTC in Windows or Atomikos in Java (among others). Those will only support transactional resources, such as queues and databases, not file systems such as SMB.

Another way is to use the sagas-pattern. That pattern is maybe a bit overkill in this case though.

So what to do? Well - I can think of at least one way:

Idempotent consumer pattern. This makes Camel hold copies of each message (or a key at least, such as filename) in memory to ensure no single message will be delivered more that once.

// Something like this

from("smb://someplace?&idempotentKey=${file:name}&idempotent=true")

. // Whatnot

.to("activemq:queue:foobar");

Please note that you can configure an idempotent repository to keep entries in database, disk or multiple other places if you want something more persistent (but also more complex).