Reputation: 6248
I'm learning JMS and wonder how a JMS client (e.g MessageListener) can notice about a new message in queue it registed. Is it frequently send requests to broker via TCP to see if there's a new message? If so, is this request synchronousor asynchronous?
Upvotes: 2
Views: 713
Reputation: 22279
JMS is just an API. It does not specify any wire level protocol. So you can't really tell how the client will behave with the broker. It could use a homing piegon for all we know. Ok, maybe not, but brokers like WebSphere MQ and ActiveMQ both supply in memory transport as well as TCP based.
Most vendors have thier own properitary protocols even though AMQP is visible on the horizon as a wire protocol standard (but far from all vendors have started to look at it).
When talking TCP there is no need to poll as long as there is a live connection going on. The broker can easily notify the client that there is a new message published while the client sleeps and the other way around.
A common way, however, is to actually do poll. But rather poll for consumer.receive(TIMEOUT);
in some longer intervals (seconds). This makes it possible to use distributed transactions in frameworks like spring. Still the broker sends actual TCP messages to the client on demand.
If it would not have been like this, then JMS/Messaging would not have been such a fast, wide psread and scalable technology
Upvotes: 1
Reputation: 2360
1) First of all, JMS
does not have something called absolute synchronous messaging. You can definitely implement so called JMS Synchronous messaging
by implementing Sync service methods but in fact it just appears to be mimicking as Synchronous messaging
. In fact it is also Async Messaging
.
2) Technically it is the JMS Server / Broker
which sends Messages to Message Consumers
through dedicated queues. Broker
simply delivers the message to Message Consumer's
onMessage()
method. And then Container
executes onMessage()
method.
Upvotes: 1