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

Parallel processing of messages by Solace

Vinay Jashtadhi
Vinay Jashtadhi Member Posts: 1 ✭
in PubSub+ Event Broker #1

Hi,

We have a scenario to process the messages at a faster rate and in parallel with solace consumer/listener, so would like to get clarified on the questions below.

  1. If the scenario above is possible & supported by solace, how many threads are permissible & configured to do the parallel processing?
  2. Does it require any additional configuration ?
  3. Also, is creating multiple sessions on a single connection allowed ? If so, what will be the impact on the consumers using this single connection ?

Thanks,

Vinay

Answers

  • nicholasdgoodman
    nicholasdgoodman Member, Employee Posts: 43 Solace Employee
    #2

    Can you clarify which language / framework / Solace SDK you are interested in doing this with?

  • TomF
    TomF Member, Employee Posts: 412 Solace Employee
    #3

    Hi @Vinay Jashtadhi ,

    Yes, there is a lot of support for consumer parallel processing in Solace. A lot depends on how you want to do this.

    If you'd like to parallel process across applications, for direct messages through a subscription, we have shared subscriptions, and for persistent endpoints (e.g. queues) we have non-exclusive queues. Both will "round-robin" messages to the least busy consumer.

    If you'd like to parallel process inside one application instance, you can do this two by allocating messages to worker threads using a message read thread.

    It is possible to create multiple sessions in the Solace APIs, but unless your performance requirements are very high, I wouldn't recommend it.

    The maximum parallelism is limited by the maximum unacknowleged message setting, which is per flow, per queue or at the system level. This is between 100,000 and 1,000,000 by default - again, unless you have very high performance requirements, this won't affect you.

  • Tripti
    Tripti Member Posts: 8 ✭
    #4

    Hi @TomF , We are looking for parallel processing inside one application instance. We are using non-exclusive queues. Right now, we create a session over the connection and one consumer for a queue. Is creating multiple sessions and eventually consumers over the sessions the only way to achieve parallelism in message processing? Are there any recommendations from the community?

    We are using java (1.8) stack and qpid-jms-client version 0.61.0.

    Our current implementation looks as follows:

    Connection connection = cachingConnectionFactory.createConnection();
Session bpInboundSession =
    connection.createSession(false, Session.CLIENT_ACKNOWLEDGE); // connection instance 
Queue bpInboundQueue =
    bpInboundSession.createQueue(
        BPMessageProcessorConstant.QUEUE_NAME_BPINBOUND + tenantId);
MessageConsumer bpInboundMessageConsumer =
    bpInboundSession.createConsumer(bpInboundQueue);
bpInboundMessageConsumer.setMessageListener(
    new SolaceBPInboundListener(
        tenantId));

Session bpConfOutSession =
    connection.createSession(false, Session.CLIENT_ACKNOWLEDGE);//same connection instance used
Queue bpconfOutQueue =
    bpConfOutSession.createQueue(
        BPMessageProcessorConstant.QUEUE_NAME_BPOUTBOUND_CONF + tenantId);
MessageConsumer bpConfOutMessageConsumer =
    bpConfOutSession.createConsumer(bpconfOutQueue);
bpConfOutMessageConsumer.setMessageListener(
    new SolaceBPConfOutboundListener(
        tenantId));

    Could you please elaborate on this :

    If you'd like to parallel process inside one application instance, you can do this two by allocating messages to worker threads using a message read thread.

    We observed an issue while using ThreadPoolExecutor. We spawned a new thread for processing a new incoming message. We observed issues with message acknowledgment. Once we removed the thread pool executor, messages were processed successfully. However, it made the message processing slower.

    Thanks in advance!

    Best regards,

    Tripti

  • nicholasdgoodman
    nicholasdgoodman Member, Employee Posts: 43 Solace Employee
    #5

    Hello @Tripti,

    What issues are you seeing with message ack in the multi-threaded processor case?

    I would suggest you might see if you are having the same issues as this question:

    Acknowledging messages using Spring JMS — Solace Community

    The crux of it is that per the JMS spec: "Acknowledging a consumed message automatically acknowledges the receipt of all messages that have been delivered by its session."

    Solace follows the spec when you configure your session with Session.CLIENT_ACKNOWLEGE, and can use individual message acknowledgement by specifying SupportedProperty.SOL_CLIENT_ACKNOWLEDGE instead.

  • marc
    marc Member, Administrator, Moderator, Employee Posts: 963 admin
    #6

    Hi @Tripti,

    I'll chime in here quickly:

    If you'd like to parallel process inside one application instance, you can do this two by allocating messages to worker threads using a message read thread.

    When @TomF mentioned this I believe he meant to use the reactor pattern. Here is a quick video on it (granted Aaron uses JCSMP to show the pattern)

    qpid-jms-client

    To be honest I haven't seen many people use the qpid JMS client. I took a quick look and didn't see a built in way that it scales consumers for you, but if you're open to it you may want to consider using Spring JMS as they allow you to just say I want concurrency of 5 or 10 or whatever and then handle the sessions/consumers/threads for you. e.g: on this line you would just add "concurrency=5" or "concurrency=5-10" in the @JMSListenerannotation

    Hope that helps!

  • KumarAbhishek
    KumarAbhishek Member Posts: 4 ✭
    #7

    Hi @marc , while we are using spring boot do you think tomact server threads can take concurrent requests inside onreceive method.

    We are not using Spring JMS however we are using JSCMP with spring boot.

Categories

This Month's Leaders

This Week's Leaders