we are trying to understand how the tRabbitMQACK component is supposed to be used after a tRabbitMQInput component.
Looking at the code, the TRabbitMQInput component start an infinite loop that regularly check the queue for new data, and if available get them. The tRabbitMQAck componet on the other hand can be connected to other components just by oncomponentOK/Error; but in the code those actions are performed outside the while infinite loop, so, never...
The question then is: how is the Ack meant to be used, or how can one exit from the infinite loop of the MQInput component?
The tRabbitMQAck component is used to send an acknowledgement (Ack) or negative acknowledgement (Nack) for messages that have been received by a tRabbitMQInput component. It works together with a non-auto-acknowledge consumer to explicitly acknowledge or reject messages after processing.
How it is intended to be used
Ensure Auto Acknowledge is disabled: In the tRabbitMQInput component’s Advanced settings, uncheck the Auto acknowledge option. This prevents messages from being acknowledged automatically when read.
Place tRabbitMQAck after message processing: Once a message has been successfully processed, connect tRabbitMQAck from the component that completes processing (for example using OnComponentOK) to send an acknowledgement back to the broker.
Select Ack or Nack mode: In the tRabbitMQAck component, choose the mode to either Ack (confirm successful processing) or Nack (indicate processing failure). Nack can optionally be configured to requeue the message.
Notes
The tRabbitMQInput component runs in a loop reading messages from the queue; it does not stop unless the job logic terminates it.
Because the input loop may run continuously, you typically use triggers (e.g., OnComponentOK / OnSubjobOK) or job design to control when tRabbitMQAck is executed relative to your message processing logic.
The acknowledgement component must reference the same connection used by the input component; select the appropriate connection if needed.
Summary: Use tRabbitMQAck following a tRabbitMQInput that has Auto acknowledge disabled. After processing a message, route control to tRabbitMQAck to send the appropriate acknowledgment back to the broker.
Thanks for the answer, but that's exactly the point... If you connect the tRabbitMQInput to the tRabbitMQACK via the onComponentOk, that path will never being executed, since the input start an infinite loop, that only follow a "row" path, executed always befor an "oncomponet*" or "onjob" path. The only way I found is to go from a row to a tflowiterate and to this then connect the ack component...
Also, it would be nice if there would be a way to stop the input when needed, but here too the only way found is to "hack" the java code by putting a break into a tjavarow component, inside the "row" path of the input component, in order to stop the infinite while loop it creates.
You are correct. This is a known design characteristic of tRabbitMQInput.
tRabbitMQInput runs in an internal infinite loop to continuously consume messages. Because of this:
OnComponentOK / OnSubjobOK / OnJobOK triggers are never reached
Only the row flow is executed while the consumer loop is active
This is why connecting tRabbitMQAck using OnComponentOK does not work.
Correct and expected pattern for ACK handling
The acknowledgement must be triggered from the row flow, not from a trigger path.
A common and valid pattern is: tRabbitMQInput (Auto Acknowledge = false) | (row = one RabbitMQ message) | tFlowToIterate (or tJavaRow / tMap) | tRabbitMQAck
This ensures:
Each consumed message is processed
ACK / NACK is sent per message
The ACK component executes inside the consumer loop
Your tFlowToIterate approach is therefore correct and appropriate.
About stopping the input loop
tRabbitMQInput does not provide a native “stop consumption” or “break loop” option. The component is designed for continuous consumers.
Available options are:
Let the job run continuously (recommended for consumers)
Stop the job externally (scheduler / OS / Talend Cloud)
Control execution using job design (separate consumer and processor jobs)
Injecting a break statement via tJavaRow works technically, but it is not recommended, as it relies on internal generated code and may break with future versions.
Best practice
Use row flow–based ACK/NACK, not trigger-based
Use tFlowToIterate or equivalent to invoke tRabbitMQAck
Treat tRabbitMQInput as a long-running consumer
Avoid modifying generated Java code to control looping
This behavior is expected given the component’s design.
