Asynchronously Sending and Receive Messages using the Solace JMS API

JonathanEid

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?

Aaron

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

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

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?