Solace Confirm Delivery pattern is always executes responseReceivedEx() method in every case in Mule

Abdul_Majid_Mangrio

Solace Confirm Delivery pattern is always executing responseReceivedEx() method in every case, i am implementing JCSMPStreamingPublishCorrelatingEventHandler in my custom Connector in Mulesoft.
weather the queue name is wrong or correct but it always goes in responseReceivedEx() method? Why?

TomF

Hi @Abdul_Majid_Mangrio, I think what you're asking here is why do I always get what appears to be a successful message receipt from the broker, even if the queue name is wrong?

The good news is that you're thinking about dealing with publisher acknowledgments from the broker - you'd be surprised how many people don't.

Are you sure you're sending to a queue and not a topic? This is important. We recommend you always send to a topic, because you can then implement the persistent publish/subscribe pattern. It's an extension of the point to point send to a queue pattern, except you get a lot more power and flexibility.

If you are sending to a topic (good) there is one final thing to be aware of. You need to instruct the broker to tell you if no-one (and that includes a queue) is listening to this topic: turn on the "Reject Messages to Sender On No Subscription Match Discard" switch in the client profile for your publisher. It's off by default for historic reasons. Once you do this and publish to a topic with no subscribers, you'll see handleErrorEx() called with exception "503: No Subscription Match - Topic ..."

swenhelge

@Abdul_Majid_Mangrio
When it comes to writing a custom Mulesoft connector for Solace ... have a look at this:
https://github.com/solace-iot-team/solace-mule-connector
It's open source, provided as-is.
Examples on usage here ...
https://github.com/solace-iot-team/solace-mule-connector-examples

Aaron

@Abdul_Majid_Mangrio ... did you figure this out? I'm curious if you tracked this down. There are statistics inside the broker that are tracked whenever you publish messages, and if these messages are (for example) discarded because the queue is not there. Unfortunately, the PubSub+ Manager web GUI doesn't expose them, they are too detailed, but I can show you how to access via CLI or REST API if you're keen.

That said, you've implemented your own custom Connector. If you've played with the Java (JCSMP) samples and tried publishing to different queue names, you should see that that you get an error if the queue doesn't exist AND you have disabled the code that automatically provisions the queue. The basic samples automatically create the queues, so you need to ensure you remove/comment out the provision() line.

Let us know. Thanks!