To consume messages from a Persistent queue in an old monolithic app, I had used javax.jms.MessageListener#onMessage(javax.jms.Message) 10 years ago.
For a new spring-boot app, I am looking to use Solace Java API and going through provided samples.
e.g. HowToConsumePersistentMessageWithAutoAcknowledgement and HelloWorld
I noticed receiveAsync of PersistentMessageReceiver fetches waiting/pending messages in the queue and finishes the thread immediately, instead of waiting for a future message. receiveAsync call requires to be in a while loop if more messages are expected for future messages based on samples. I am not sure if using while loop is an elegant solution (was expecting something similar to onMessage).
Should I use receiveAsync in a while loop, with a flag pushed from app/spring bean shutdown ? Is my approach wrong? Please guide me in the right direction.
The HelloWorld sample uses Direct messaging, so not applicable to your Persistent use-case. (unless you want to use Direct messaging instead?)
This might be more relevent: patterns/GuaranteedSubscriber
And the docs here: https://docs.solace.com/API-Developer-Online-Ref-Documentation/pubsubplus-java/com/solace/messaging/receiver/PersistentMessageReceiver.html
The behaviour you're describing sounds more like receiveMessage(long timeOut) with a timeout of 0. With the receiveAsync(MessageReceiver.MessageHandler messageHandler) method, you pass in the MessageHandler, and that is what is triggered asynchronously (just like JMS onMessage() callback). And it returns void. So I'm not sure how you're getting a message from calling that method?
So yes, check the GuaranteedSubscriber sample above, hopefully it demonstrates Persistent async message handling. And remember: best practices are to use client ACK (manually triggered by your app when done processing the message, from any thread... not auto ACK, which is super basic and just ACKs when the callback is finished. (unless you're doing all your processing in the callback thread, which (also best practices) should be very minimal, otherwise use your own thread).