Mule Tonicas

Overview This post explains how to use Mule with RabbitMQ AMQP Connector with Dead Letter queues. The Sample code can be easily adapted to other Message Brokers. The Problem We have a Mule application consuming messages from a Message Broker and pushing those messages to a database table. The database server becomes temporally unavailable returning ConnectExceptions. How to save that message that failed to be delivered so it can be reprocessed later when the target system is back? How to retry delivering the same message to the target system before giving up? How to wait between each retry, avoiding overflowing the target system with requests that will most likely fail? Introducing the Dead-letter Channel Integration Pattern This pattern gives the consumer applications an opportunity to reprocess the same message several times. If a final retry also fails, the message is forwarded to an auxiliary queue for further manual intervention. Being selective on the errors we wan

I don't like wrapping well stablished frameworks to add little to no functionality. It does not sound right. Creating wrappers around log4j is the most common example of this awful practice. It is just a dragging thing that we should all avoid. My point is: if it is simple and it works, just live it alone. After all, the best code you can ever write is the code you did not write! So, most of my Mule applications rely solely on bare Log4j for logging. The below is a collection of some of the best log4j practices I have been using for awhile in my Mulesoft applications. One log file per application Each application logs to its own log files. That is, only the errors thrown by a application are allowed to be written on the main mule console or default log files. Everything else is on the application log file. Therefore, each application have its own appender and logger: ...     <Appenders>         <RollingFile name="file" fileName="${sys:mule.h