🎄 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.
Setting up standards for publishers using JMS
We are using Solace Cloud PubSub+ and trying to standardize JMS properties for Publishers using the Solace API for JMS.
So, some of the recommendations to developers would be like setting these.
- DMQ always set to true
- JMSMessageID
- JMSTimestamp
Can these set by default when not supplied by the publishers ?
Comments
-
Hi @Abu,
DMQ always set to true
If your JMS apps use Solace's JNDI provider to lookup its connection factory then you can set DMQ eligible to true, as well as other properties (such as retries, timeouts, etc.) in one place.
JMSTimestamp
I believe this already automatically gets set if it isn't touched? Are you seeing otherwise (i might be wrong here)
JMSMessageID
Again, I believe the Solace API sets a default (I am seeing something that looks like:
ID:fe80:0:0:0:0:0:0:1%lo0f5d517e4ac6cb730:70) but your applications would be on your own to configure it if you want something different. A lot of times applications will set this ID to an identifier that has some context to the event/processing that is done in the app and that ID will also be included in the logs upstream/downstream to allow for log correlation. If you want it to be the same format across many apps then one option might be to have your apps use a common send method that is in a shared library. This would also allow you to set other properties in one place if desired (this pattern could also be used to set DMQ eligible if you don't do it on the connection factory).Hope that helps!
1 -
Here my view on that based on tests.
DMQEligible:
DQMEligible is a problem case introduced likely with a history. It was discussed already in other threads that a publisher flag should not risk message loss and undergo a proper subscriber setting for DMQ.
The default is: false. I heard then in some chats the some libs are changed to have the default set to true. I checked now latest:
JCSMMP => default still false
https://docs.solace.com/API-Developer-Online-Ref-Documentation/java/index.html
Javascript => not even telling what is default => not good
https://docs.solace.com/API-Developer-Online-Ref-Documentation/js/index.htmlOnly when using JMS there is a way to overrule the setting JNDI provider connection factory.
But that is just for JMS. So the generic pattern is a setting = falseMore info here:
https://docs.solace.com/Solace-JMS-API/Message-Properties.htm#jms_properties_39190069_303895JMSTimestamp
JMSMessageIDI tested both by publish from e.g. javascript and nothing was set.
Only when settingApplicationMessageID =>JMSMessageID
SenderTimeStamp => JMSTimestamp
i saw values on jms consumer.https://docs.solace.com/Solace-JMS-API/Message-Components.htm
As well a fixed value on JMSMessageID would be worst option.
As that value is defined like that:
https://docs.oracle.com/cd/E12839_01/apirefs.1111/e13943/WebLogic.Messaging.IMessage.JMSMessageID.html
Unique Id per message from publisher (so publisher and any event message id) => must be uniqueAdditional that field is often used for de-dup next to: HDR_DUPLICATE_DETECTION_ID
I will create now another thread to recommend to re-work all library docs to state clearly on each set
the default value set.0 -
Hi @Robert,
My comments further up in this thread were under the assumption that the Solace JMS Library was being used.
So 2 things:
Correct, DMQ Eligible is false by default in JMS, CCSMP, JCSMP and JavaScript APIs for backwards compatibility reasons. You have to set that to true unless you are using one of the newer PubSub+ Messaging APIs, such as Java or Python. Each API should already have the default value properly defined in the docs (UPDATE - thank you for opening the other thread as this wasn't true in javascript). Please let us know if you find otherwise. But as we said above, if using JMS you can change this in one spot by changing the settings in the Connection Factory.
If you aren't using JMS then the JMS headers would not be added by the other APIs upon sending a message. However, if you are were to have a JMS app using the sol-jms API receive a message sent by an app using a SMF API (such as JCSMP) the broker automatically translates the headers as defined in the
Message Componentspage. So "ApplicationMessageID =>JMSMessageID" and "SenderTimeStamp => JMSTimestamp" as you saw above. This allows your app using JCSMP to not have to worry about JMS headers, but only about the standard headers in the SMF protocol.
Hope that helps!
0 -
@marc
1.) Let's see what we can do about this flag. I just see risk of loosing messages if someone forgets to set. As we see there are already some simplifications to set for JMS on factory level but JMS is not the only way we connect to solace.2.) Exactly like you say. You explicit have to set the values and in my eyes it should be as well done
by following the purpose of a field and not missuse. As ApplicationMessageID => JMSMessageID both fields must follow the defined purpose described here:https://docs.oracle.com/cd/E12839_01/apirefs.1111/e13943/WebLogic.Messaging.IMessage.JMSMessageID.html
https://docs.solace.com/API-Developer-Online-Ref-Documentation/net/html/ac9871b6-905d-a8df-b27e-2e29c091c73f.htm=> "The JMSMessageID header field contains a value that uniquely identifies each message sent by a provider."
Thanks for clarification of the topic.
0
