How to set max-delivered-unacked-msgs-per-flow via JCSMP API
I see that .Net API has methods to set WindowSize and MaxUnackedMessages ( )
But I do not see any such documentation for JCSMP API, can you please let me know how to set those?
Regards,
Karthik
Best Answer
-
JCSMP Flow Window size can be set when the flow is created in the ConsumerFlowProperties.
Specifically ConsumerFlowProperties.setTransportWindow().
JCSMP does not support MaxUnackedMessages. There is an important concept here, an application acknowledgement via XMLMessage.ackMessage() is a signal to the Solace broker that the message has been successfully processed and can be remove from the queue on the Solace broker. It is definitely not related to window size or flow control. An application can received many thousands of messages more than the transport window size even if XMLMessage.ackMessage() is never called.
JCSMP automatically exerts flow control on the broker based on it's internal queue, which is set by the Transport Window size. If an application does not call or is slow to call 'receive()' that internal queue fills up and the API will close the window. There is no need to set MaxUnackedMessages as the flow control is automatic based on how fast the application is consuming messages.
If you are using async message processing (via a callback) or are receiving messages from the queue but cannot process them, then it is possible to call Consumer.stop() to prevent delivery of more messages. Followed by Consumer.start().
In the .NET API, which is based on the C API, there is no internal queuing point. The MaxUnackedMessages property was added as a workaround to tightly couple message processing to transport flow control, but it is not ideal. APIs the support an internal queueing point and automatic flow control do not need to implement MaxUnackedMessages.
Regards,
Ragnar
1
Answers
-
JCSMP Flow Window size can be set when the flow is created in the ConsumerFlowProperties.
Specifically ConsumerFlowProperties.setTransportWindow().
JCSMP does not support MaxUnackedMessages. There is an important concept here, an application acknowledgement via XMLMessage.ackMessage() is a signal to the Solace broker that the message has been successfully processed and can be remove from the queue on the Solace broker. It is definitely not related to window size or flow control. An application can received many thousands of messages more than the transport window size even if XMLMessage.ackMessage() is never called.
JCSMP automatically exerts flow control on the broker based on it's internal queue, which is set by the Transport Window size. If an application does not call or is slow to call 'receive()' that internal queue fills up and the API will close the window. There is no need to set MaxUnackedMessages as the flow control is automatic based on how fast the application is consuming messages.
If you are using async message processing (via a callback) or are receiving messages from the queue but cannot process them, then it is possible to call Consumer.stop() to prevent delivery of more messages. Followed by Consumer.start().
In the .NET API, which is based on the C API, there is no internal queuing point. The MaxUnackedMessages property was added as a workaround to tightly couple message processing to transport flow control, but it is not ideal. APIs the support an internal queueing point and automatic flow control do not need to implement MaxUnackedMessages.
Regards,
Ragnar
1 -
Thanks @Ragnar for the detailed explanation, it makes sense.
Then, what would be ideal/recommended solution to control the flow of messages based on the processing capacity of the application in a scenario where applications handle the message in async mode with internal threads and each thread does an individual acknowledgement/rejection based on the status ?
- To use Consumer.start() and Consumer.stop()
- To set both max-delivered-unacked-msgs-per-flow at the Queue level and ConsumerFlowProperties.setTransportWindow()
- To use Consumer.receive() and internally in the application based on its capacity
Thanks in advance.
Best Regards,
Karthik0
