Setting up standards for publishers using JMS

Abu Member Posts: 13

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 ?



  • marc
    marc Member, Administrator, Moderator, Employee Posts: 848 admin
    edited January 2022 #2

    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.


    I believe this already automatically gets set if it isn't touched? Are you seeing otherwise (i might be wrong here)


    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!

  • Abu
    Abu Member Posts: 13

    Hi @marc,

    Thank you for the information.

    As I understand there is no way to enforce seeking these properties from the publisher but should be recommended to the developers as best practice.

  • Abu
    Abu Member Posts: 13

    Hi @marc,

    I just saw this thread which says otherwise.

    I see that atleast the ApplicationMessageID and SenderTimeStamp are not set as default or ?

  • Robert
    Robert Member Posts: 53

    Here my view on that based on tests.

    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
    Javascript => not even telling what is default => not good

    Only 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 = false

    More info here:


    I tested both by publish from e.g. javascript and nothing was set.
    Only when setting

    ApplicationMessageID =>JMSMessageID
    SenderTimeStamp => JMSTimestamp
    i saw values on jms consumer.

    As well a fixed value on JMSMessageID would be worst option.
    As that value is defined like that:
    Unique Id per message from publisher (so publisher and any event message id) => must be unique

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

  • marc
    marc Member, Administrator, Moderator, Employee Posts: 848 admin
    edited January 2022 #6

    Hi @Robert,

    My comments further up in this thread were under the assumption that the Solace JMS Library was being used.

    So 2 things:

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

    2. 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 Components page. 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!

  • Robert
    Robert Member Posts: 53

    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:

    => "The JMSMessageID header field contains a value that uniquely identifies each message sent by a provider."

    Thanks for clarification of the topic.