Asynchronously Sending and Receive Messages using the Solace JMS API

The Solace JCSMP library provides a lot of power and configuration to produce and consume messages in many fashions. However, for my testing purposes, I must use the Solace JMS API library and it does not provide the as much functionality and it is to my understanding that the library is not JMS 2.0 compliant but still adhering to the JMS 1.1 spec. According to the documentation, JMS 1.1 does not allow attaching a Completion Listener onto the MessageProducer, thus making the "send()" method blocking for the producer.

I have taken a look at "Solace Messaging using Apache Qpid JMS 2.0 over AMQP https://solace.com/samples/solace-samples-amqp-qpid-jms2/", but going this route, it seems as if I lose the ability to use the SolConnectionFactory which exposes some methods that are necessary for my testing.

So basically what I am asking is what is the recommended way to set up an asynchronous/non-blocking producer and consumer using the Sol JMS API while also being able to set Dynamic Durables as true?

Answers

  • Aaron
    Aaron Member, Administrator, Moderator, Employee Posts: 594 admin
    edited February 2020 #2

    Hey Jonathan. Good question! I haven't tried, but can the Qpid JMS API use the connection factory that's configured on the broker? You can set the "dynamic durables" property there. Then you shouldn't need access to the hidden "SolConnectionFactory".

    Or, until Solace comes out with a "native" JMS 2.0 API, another option that may come close to suiting you is to configure the connection factory to use Guaranteed transport for non-persistent messages: transport-properties --> direct-transport == false:

    sg-sol-3501-vmr> show jndi connection-factory * detail
    
    Connection Factory : /jms/cf/default
    Message VPN : default
      messaging-properties : 6
        default-delivery-mode        : persistent
        text-msg-xml-payload         : true
        default-dmq-eligible         : false
        default-eliding-eligible     : false
        xa                           : true
        jmsx-user-id-enabled         : false
      transport-properties : 17
        connect-timeout              : 30000
        read-timeout                 : 10000
        reconnect-retries            : 3
        reconnect-retry-wait         : 3000
        keep-alive-enabled           : true
        keep-alive-interval          : 3000
        keep-alive-count-max         : 3
        send-buffer                  : 65536
        receive-buffer               : 65536
        tcp-no-delay                 : true
        direct-transport             : false       <-----
    

    Then, if you publish using NON-PERSISTENT, you'll still be sending the messages as Guaranteed, and it will be a non-blocking send so you'll get much better performance. However, (due to the JMS spec) there's no ACK/NACK callback, so the publisher will not be made aware of any issues/errors with publishing (e.g. queue over quota).

    Does that help?

  • JonathanEid
    JonathanEid Member Posts: 2

    I tried many things but to your point I was unable to retrieve the connection factory from the broker using QPID

    `final String INITIAL_CONTEXT_FACTORY = "org.apache.qpid.jndi.PropertiesFileInitialContextFactory";
    final String CONNECTION_JNDI_NAME = "local";
    final String CONNECTION_NAME = "amqp://admin:password@malta.corp.sensis.com:30500?brokerlist='vm://:1'";

    Properties properties = new Properties();
    properties.put(Context.INITIAL_CONTEXT_FACTORY, INITIAL_CONTEXT_FACTORY);
    properties.put("connectionfactory."+CONNECTION_JNDI_NAME , CONNECTION_NAME);
    Context ctx = new InitialContext(properties);
    ConnectionFactory factory = (ConnectionFactory)ctx.lookup(CONNECTION_JNDI_NAME);`

    and I did not find that sending Non-Persistent messages unblocks the send function.

    Do you have any examples of fast production and consumption using the Solace JMS API?

  • dsargrad
    dsargrad Member Posts: 7
    edited February 2020 #4

    Aaron.
    Has Jon used the proper CONNECTION_JNDI_NAME, and the proper CONNECTION _NAME in the above? Do you see something wrong with the way his code is trying to access the connection factory configured on the broker?

    Using the JMS API provided by solace, what kinds of msg rates should we be able to achieve under the assumption that we want to publish/subscribe unreliably? Here again, assume that we dont need persistence, or durability. I'm trying to see if we can receive anywhere close to the 250,000 messages per second that you showed us with the core solace API.

    Jon.
    "local" (CONNECTION_JNDI_NAME ) and "vm://:1" (CONNECTION_NAME suffix) are confusing to me. Where do you get these?