Get clarity on retry count (named delivery count) - several questions
Use Case:
==========
As consumer in case of retries you naturally want to differ in your logic depending on which retry you are on. As well likely you want to log somewhere which retry you currently processing.
Delivery Count:
=============
That seems to be what i look for but i don't understand that info message:
"Enabling the message delivery count is a Controlled Availability (CA) feature. Please contact Solace to find out if this feature is supported for your use case."
So how to get the delivery count then in HA set-up which likely many companies use in their topology ?
Why are so many fields (like this one as well) not mapped in RDP to send as http header field ?
https://docs.solace.com/API/RESTMessagingPrtl/Solace-REST-Message-Encoding.htm#_Ref393979969
Any message or delivery related field must be possible to configured to expose as http header fields with RDP. If that is not done then RDP behaves different then non RDP look up. I understand that it does not make sense maybe to map any setting but then i would like to choose which ones to map.
Maybe i missed something but it would be great to clarify on that.
Answers
-
Hi @Robert, looks like you have two questions in one thread here..!
Enabling Delivery Count means that the consuming app can see how many times a message has been attempted to be delivered. Exactly to your point, it might want to try a different strategy. This is a somewhat newer feature, and it involved changing the wireline protocol to include this count with the message header. I forget exactly what the caveats were around using this feature (maybe can't be used on tiny 100-connection tier brokers?), but just email Solace Support for clarification.
Note that we've also had the "max redelivery" setting on queues for a long time, where the broker tracks the number of redelivery attempts (from 1..255). If enabled, these counts are available in the queues' message details.
Regarding RDP / REST API feature parity with SMF: there are a number of fields that are not exposed or do not map through, both ingress (REST POST) and egress (RDP). If there is a specific field/metadata you need mapped through for your use-case needs, the best thing to do is raise an enhancement request with Solace Support.
0 -
@Aaron can you elaborate more behind the scenes which newer feature you talk about ? I need something to mention it for support, so some name would help me.
Related to not mapping through several fields via RDP (any partially other interfaces) got reported several months back to get an overview for all interfaces to see which properties are properly handled or not. My problem is that not propagating so many fields through RDP is a big gap on solace as RDP is the only reasonable option to use when having serverless components. And severless is the future more and more what will be the way to go.
Just Check Ticket: 72560
0
