🎄 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.

DeliveryMode setting with Pure Java API

KeganHoltzhausen
KeganHoltzhausen Member Posts: 4 ✭
in PubSub+ Event Broker #1


I am creating a rewrite of previously JMS specific spring implementation of an eventing library to pure java. But I could not find where to set DeliveryMode in the message properties, and then found that there pretty much is no place to set that per-message like I used to with JCSMP / JMS.

I have to decide when I create the publisher if it will be either persistent or direct.

publisher = messagingService.createPersistentMessagePublisherBuilder()
        .onBackPressureWait(2000)
        .build();


Now everything I publish with this publisher will be "Persistent" and possibly demoted to direct based on subscriber properties. This is fine.

But I used to offer producers per-message level control over the DeliveryMode, but now if I want to achieve that I need to have two publisher instances per producer to flip between Direct and Persistent. So I am questioning if I need this as it feels bad.

If I used the PersistentPublisher, I already offer the highest guarantee at this level, but there could be a need to publish a "Direct" message for utilizing less overhead. Is there a specific combination of MessageProperties that could help me here, or am I overthinking this, and just go with Persistent and let the demotion do its thing?

Answers

  • Aaron
    Aaron Member, Administrator, Moderator, Employee Posts: 644 admin
    edited April 15 #2

    Hey @KeganHoltzhausen… how are you doing? Hope all is well!

    Yup, from my understanding, you'll need two publisher services Builder objects if you want per-message control to mix-and-match at will. Our "next gen" APIs were designed to be simpler and simplify development. Simpler use cases too.

    Publishing Guaranteed and letting it be demoted is probably mostly fine, unless you're looking to reduce every nano of latency that you can… or if we're talking about massive throughput. Also, a Direct subscriber listening to a demoted stream might get dupes if the publisher automatically retransmits a message for any reason (ACK timeout, failover, etc.). The ADB/message spool will automatically de-dupe retransmissions for any Persistent subscriber.

    One other thing: if your publisher is using the client-profile setting reject-msg-to-sender-on-no-subscription-match (where the broker will send a NACK if nobody is subscribed to the message) then the publisher will still get a NACK even if there is a Direct subscriber… they gotta be subs on queues or TEs. So maybe that's not so good?

  • Kegan
    Kegan Member Posts: 1 ✭
    edited March 27 #3

    Hej @Aaron ! Yep all good here! Hope you are well too!

    So then I know I'm not missing anything in this particular case.

    Do the MessagingService instances count against my client connection count towards the broker? Im just thinking about impact if I start instantiating additional MessagingService instances per client, or would the publisher not be connected until it gets some work to do?

  • Aaron
    Aaron Member, Administrator, Moderator, Employee Posts: 644 admin
    edited March 27 #4

    We have two different users now?? 🤔 haha

    Nope, they're just internal API objects. All use just 1 TCP connection. You can check your broker: show client * in CLI, or use the PubSub+ Manager GUI to confirm this.

Categories

This Month's Leaders

This Week's Leaders