SessionHandler dies when starts with many messages in queue about azure-service-bus-java

[yvgopal]

Your observation is right. What are you doing in the onMessageAsync() implementation? Are you calling a blocking operation in it like Thread.sleep()? Java ForkJoinPool.commonPool starts with threads equal to the number of CPU cores. It is supposed to create more threads based on demand, but it can't handle blocking operations. onMesssageAsync() is supposed to be an async operation, not to block. If you are blocking, use a smaller number for max concurrent sessions.

[eperov]

Hi,
Not doing anything blocking in onMessageAsync
Is it correct implementation of it?

        @Override
        public CompletableFuture<Void> onMessageAsync(IMessageSession session, IMessage message) {
            System.out.println("SessionID: " + session.getSessionId() + " - Message Received - " + message.getMessageId() + " - " + new Date().toString());
            try {
                completeMessage(session, message);
            }
          catch (Exception ex) {
             throw new RuntimeException(ex);
         }
            return CompletableFuture.completedFuture(null);
        }

========================================
Thanks,
Edouard

[yvgopal]

completeMessage() is most likely blocking, I am assuming you call session.complete(message.getLockToken()). complete() call is internally session.completeAsync().get().. which is a blocking call.
If all you want to do is complete in the onMessageAsync.. there is a better option. SEt AutoComplete=true in session handler options. Or return session.completeAsync() in onMessageAsync.

[eperov]

We do not want to set Autocomplete to true,
Because there will be complex message proceeding (validation/transformation/sending to another queue)instead of completeMessage() there and regardless of status the message will be complete, or not complete, or sent to DeadLetterQueue.

Is there another way to process message rather than in onMessageAsync?
We need to get a message, process it, and complete, or not etc.

[yvgopal]

Ok.
Ideally you should perform such tasks like validation,transformation in asynchronous way.
Or just increase the parallelism level of ForkJoinPool.commonPool, using the system property "java.util.concurrent.ForkJoinPool.common.parallelism" as mentioned in [https://docs.oracle.com/javase/8/docs/api/index.html?java/util/concurrent/ForkJoinPool.html] . Set the system property to something more than max concurrent sessions... so there are always some non blocked threads.

[eperov]

Thank you for the System Property tip!
Would you please answer two more questions because we just starting use of ServiceBus

1. You said: Ideally you should perform such tasks like validation,transformation in asynchronous way.
   Is this ok method to achieve our task like below,
   or there is some other way access messages outside of onMessageAssync,
   please just provide a skeleton of such thing.
   ======================
   @OverRide
   public CompletableFuture onMessageAsync(IMessageSession session, IMessage message) {
   processMessage(session, message);
   return CompletableFuture.completedFuture(null);
   }
   ======================
2. Is there a way to stop the SessionHandler from receiving any more messages without removing it?

Thanks,
Edouard

[yvgopal]

1. your code works. But it is not async. Async works if other methods that you call are also async, like if you have a processMessageAsync instead of processMessage. A workaround is to wrap your synchronous code in a Callable and submit it to a thread pool. Create a new completablefuture and complete it inside the call method of the callable, when the actual processing completes. That way you can submit your callable to the thread pool and return the completablefuture right after that. It is ok even if you don't do it the aysnc way. Just increase the thread count using the system property. You should be fine.
   To the second part of your question, we will soon make public Sender and Receiver implementations. With a Receiver, you can call receive() to receive just one message. We will push it sometime next week.
2. No.. There is no way to stop the SessionHandler from receiving any more messages. Just close the queue client when you want to stop receiving.

[eperov]

New Receiver sounds very promising, we may have more control on the flow, thank you.

What are new Sender features comparing to the existing sender - queueClient.send(message); ?

Does new Receiver support Sessions in queues/topic's subscriptions, does it also have onMessage/onSession options?

What about performance comparison of the new Receiver vs Session Handler?

[yvgopal]

Sender features are same as QueueClient.
Yes.. you can get a session receiver object..
Performance will be same as QueueClient internally uses senders and receivers.

[eperov]

• Sender features are same as QueueClient.
  What is new then in new Sender version?

Does new Receiver also have onMessage/onSession options?

[jtaubensee]

@eperov - No. While the below issue is for the .NET client, it will give a brief description of what we are envisioning with the client vs. sender/receiver functionality.

Azure/azure-service-bus-dotnet#87

The bottom line though, is that clients are the "easy getting started scenario" that will cover most use cases, while sender/receivers provide advanced functionality, and some additional knobs to customize your experience.

[jtaubensee]

Closing, please comment back here to reopen if needed.