Closed sasbury closed 5 years ago
We did some experiments (and i was missing an error handler), it looks like you have to pause/resume callbacks to do this async Cmit(), let me know if that sounds right.
You don't say what the error was that you needed to handle - I guess it was MQRC_CALL_IN_PROGRESS.
You can call MQI verbs from any thread in the process. But you cannot call one while another is in the middle of working. So you can't call Cmit if the callback function is currently being invoked.
There are flags to the MQCNO Options parameter used during Connx. The default in this package is to set MQCNO_HANDLE_SHARE_NO_BLOCK, which will cause that MQRC if 2 calls are being simultaneously made. You can otherwise use MQCNO_HANDLE_SHARE_BLOCK, in which case the 2nd caller will be silently delayed until the first has finished. See https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.1.0/com.ibm.mq.dev.doc/q025940_.htm
Excellent thanks.
Is it ok to call commit from a go routine/thread that isn't the one processing callbacks.
I am currently allowing the client to receive > 1 message between Cmit() calls. But I also set up a timer to make sure i never go more than 100ms before I call the Cmit. The idea is to allow fast moving messages through, but still commit responsively for low message traffic.
Our concern is will the library prevent us from committing the message that is in a callback if we call Cmit() from a different thread.