How does your consumer application look like? You showed above is a sender side, and sending a message to the JMS queue itself is a synchronous action. When we say asynchronous on JMS, it just means the receiver receives a message asynchronously from a queue.
I simply made another service with a JMS binding.
maybe I could call
in a separate thread, but I don't think it's the best pratice
1 of 1 people found this helpful
You mean service.operation() on sender doesn't return until the consumer application receives the message? That shouldn't happen. If you add Thread.sleep(5*60*1000) in the consumer application, service.operation() in sender application actually waits 5 minutes? If so, JMS itself doesn't cause it, but there should be something synchronizing between sender and consumer.
yes, that's it!
the sender awaits.
If I use plain jms api, instead of the injected service, everything goes fine.
Can you attach your application and a testcase which demonstrate that behavior?
Sorry to barge-in Tomo! I did not yet look at the sample application, but my guess is that the REST interface is designed as a request-response MEP, in essence it has a return value. So if user does not want to wait for a response from the Bean service, he can mention either the REST binding to be one-way by having no return value or the Bean interface to be one-way having no return value. Just my 2 cents!
i just set my jms consumer method to void