🎄 Happy Holidays! 🥳
Most of Solace is closed December 24–January 1 so our employees can spend time with their families. We will re-open Thursday, January 2, 2024. Please expect slower response times during this period and open a support ticket for anything needing immediate assistance.
Happy Holidays!
Please note: most of Solace is closed December 25–January 2, and will re-open Tuesday, January 3, 2023.
FlowHandle.sendSingleAck parameter
In https://docs.solace.com/API-Developer-Online-Ref-Documentation/jms/com/solacesystems/jcsmp/impl/flow/FlowHandle.html#sendSingleAck(long, boolean)
the method sendSingleAck has second parameter "allowReactorComplete". What is the meaning of it?
Answers
-
Hi @lilyevsky ... FlowHandle is not a documented class, and is therefore considered "internal" and not available for use by applications. I'm actually very surprised it exists at all in the JavaDocs, I've never seen it before! But I'm guessing this method is probably used by the JMS 1.1 API, which wraps around JCSMP.
Still, if I had to guess, it might be related to the Session property that allows you to only configure one context thread, so the dispatch happens on the reactor thread (rather than a 2nd dispatch thread as usual), and maybe this has something to do with allowing the method to run on the reactor thread? I'm not sure.
0 -
Hi Aaron,
This is how I got to the current issue. In my code I need to explicitly acknowledge messages, and the obvious way to do it is calling ackMessage() on the message itself.
However, I want to postpone the acknowledgment until the data that came with the message is fully processed. In such case, I need to keep that BytesMessage object around for longer time, which is likely to be a huge memory waste. On top of that, I use Flink (I am actually trying to create JCSMP Flink connector), and with all that checkpoint framework, I would have to store message objects in there, which is very problematic. In all Flink tutorials and connector examples they use message IDs to acknowledge messages on the broker side.
Logically it is obvious that to ack the message you only need an ID, and so I started digging inside the ackMessage() call stack, and there I found the FlowHandle and sendSingleAck . So apparently it is not just for JMS, but for JCSMP itself. Looks like this is the ultimate way to ack the message. I strongly believe it should be documented as public interface; all other message brokers allow ack by ID in their APIs.
Anyways, my connector prototype is working fine, only I was not sure whether I should set that "allowReactorComplete" to true or false - I would like to understand what difference would it make. Maybe I can trace the ackMessage() call and see how it sets that flag.
Another question: I know you have the Flink connector for JMS, but not for JCSMP (this is why I started my little project). Do you know of any plans developing such connector?Regards,
Leonid
0
