Regarding setting JMSProperties with the help of solclient C api

Hey @amol_p81,
In the C API ignore the name "JMSProperties" and just set each property separately. When this gets mapped to the JMS message they'll be retrievable via getIntProperty, getStringProperty, etc.

I simulated this using sdkperf_java b/c my machine isn't setup for c dev right now (but sdkperf_java uses SMF just like the C API)
sdkperf_java.sh -cip localhost:55555 -cu default@default -cp default -ptl abc/topic2 -mn 1 -mr 1 -cpl Int,snapshotid,521

Then on the JMS side you should be able to get a list of JMS Properties available and query them in your onMessage. For example,

    @Override
    public void onMessage(Message message) {
        try {
            System.out.println("Message received.");
                System.out.println(("snapshotid:" + Integer.toString(message.getSgetIntProperty("snapshotid"))));
            System.out.printf("Message Content:%n%s%n", SolJmsUtility.dumpMessage(message));
        } catch (JMSException ex) {
            System.out.println("Error processing incoming message.");
            ex.printStackTrace();
        }
    }

Output from running that..

Message received.
snapshotid:521

Message Content:
JMSDeliveryMode:                        1
JMSDestination:                         Topic 'abc/topic2'
JMSExpiration:                          0
JMSPriority:                            0
JMSDeliveryCount:                       1
JMSTimestamp:                           0
JMSProperties:                          {snapshotid:521,JMS_Solace_DeliverToOne:false,JMS_Solace_DeadMsgQueueEligible:false,JMS_Solace_ElidingEligible:false,JMS_Solace_MsgDiscardIndication:false,Solace_JMS_Prop_IS_Reply_Message:false,JMSXDeliveryCount:1}
Destination:                            Topic 'abc/topic2'
Class Of Service:                       USER_COS_1
DeliveryMode:                           DIRECT
Message Id:                             4
User Property Map:                      1 entries
  Key 'snapshotid' (Integer): 521

Hey @amol_p81,
Awesome, glad you were able to get properties passing properly from your app using the C API to the one using JMS.

As for the follow-up question, what you are seeing here is by design and you have the option to choose between two different qualities of service (QoS).

• Event producers can send event messages using a guaranteed QoS by setting the message’s Persistent Delivery Mode to Persistent. This flag instructs the broker to reply to the producer with an acknowledgment when the broker has stored the message in durable storage (including HA and / or DR replication).
• When event messages arrive at the broker with Persistent Delivery Mode set to Direct, the message is placed at the tail of the Non-Persistent Event Stream and no acknowledgement is sent to the producer.

Depending on your choice of QoS the events pass through the broker differently. This page goes into a lot of detail on that: https://docs.solace.com/PubSub-ConceptMaps/Event-Stream-Maps.htm

-Marc

Hi @amol_p81,
In general, best practice when using maps would be to retrieve values via the key as different languages and library implementations may treat maps differently and many don't guarantee order. So I highly recommend retrieving via the key and not relying on order of the properties in the map.

To get a bit more info I also talked to someone on our engineering team and the C SDK serializes the map as it is being created, and consequently if read by the C sdk properties should be retrieved in the same order. That said, the JCSMP/JMS APIs convert the serialized map from the wire into an actual map-object which is going to be implementation dependent and insertion order of properties may not be maintained as you're seeing.

-Marc