Closed michaelklishin closed 4 years ago
I found some more weird behaviour with afterConfirm. This time i send 6 messages (all delivered succesful), but receive 1 ack(first call of afterConfirm handler), 1 with neither ack nor nack(next call) and then 4 nacks. Furthermore channel.basicPublish always returned 1. Shouldn't it at least increment? This problem doesn't make any sense to me.
Channel#basicPublish
shouldn't have any return value. There is no response for basic.publish
and related payload frames in the protocol.
It was a mistake. No other client returns anything like this from basicPublish
. Let's. focus on the issue at hand.
I did an example repo: https://github.com/SimonErm/rabbitmq-objc-client-after-confirm-reproduction .
Just checkout and run npm install
and docker run -p 5672:5672 -e RABBITMQ_DEFAULT_VHOST=test rabbitmq:3
Then you can set a breakpoint in the ConfirmationCallback in AfterConfirmReproduce.swift and run the App from objcRabbitmqAfterConfirm workspace
I got it working for me by using DipatchSemaphore and registering afterConfirm after publish like it's done in https://github.com/rabbitmq/rabbitmq-objc-client/blob/5a845807072c0112168d12dfd6449867764c10a8/RMQClientIntegrationTests/ChannelIntegrationTest.swift#L70
@SimonErm thanks for following-up. I should be able to pick up your repro example in the 2nd half of next week. So it's not been forgotten.
Curiously I no longer can reproduce.
This example does not await confirmations, so the method is as safe as if confirms were not used at all.
I had a different problem but with XCode 11 it seems to be gone. Oh well :)
Publisher confirms test sporadically fails for no known reason. This seemingly only happens when a lot of tests are executed at the same time.
Anecdotal evidence leads me to believe it could a dispatch queue interference. That's just a totally unconfirmed hypothesis at the moment. Possibly related to #56.
I am yet to capture traffic when this happens. Now that we have user-provided connection name support (#156), it should be easier to identify this test's connection in both Wireshark and server logs.