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?
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
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.
Related
Good morning, I am currently managing a queue jms [wso2] message broker.
I have a java client who sends a message in the queue and a java ServletContextListener which activates every time a message is being delivered.
And everything works ok.
My bosses have asked me now if it was possible that once the message arrives in the queue, it automatically makes a call to a service.
I was reading something like [wso2] ESB Message Processor.
My questions are:
1) Is it possible to do such a thing without using [wso2] ESB? but only [wso2] message Broker.
If you have some ideas.
2) at this point [wso2] ESB would be a consumer and a call from them?
3) If someone can give me an example of how to handle the ESB once the message ne [wso2] Message Broker has arrived.
Thanks in advance
Not sure if I got it right, but here are some thoughts that come into my mind.
1.) I'm not familiar with wso2 mb (using activemq) but I assume that its not possible according to the documentation
2.) Yes, the esb acts as a message consumer (like your java client) and can do various things then. You can call other services, forward the message to another queue etc...Maybe the ESB can do the things you're servlet is doing
3.)You can create a simple proxy in esb that takes the jms message and forwards it to your servlet,service or whatever. There are plenty of cases, regarding jms messages the following link might help.
ESB JMS
One other thing I'm thinking of, if you send your jms message to a jms topic from your java client, you can then create several consumers for the same message. So your existing implementation will subscribe to that topic and you can create a simple second client (or use the esb) that connects to that topic as well. Both will receive the same message and can do whatever processing is needed.
Hope that helps.
Recently I started using ActiveMQ to act as a Message Middleware in my new project, this is the first time I try use ActiveMQ, the projects I had participated before used our previous company's inner message framework like Swallow. So before I begin implementing the system, I need to clear some design points.
Cases in our system will use ActiveMQ include sending mail, sending tasks to queue and doing tasks from queue, asynchronous request/response, so what kind of protocol and network connection is the right choice for our cases? I list some protocols and network connection options here:
ActiveMQ protocols:
MQTT
WS
Openwire
Stomp
Stomp
ActiveMQ Network connections:
VM
TCP
UDP
HTTP
Failover
Discovery
I will also consider the aspects of HA and cluster for my system, so can anybody gives me some ideas to decide how to choose the protocol and network connection?
Thanks a lot.
Openwire has historically been the default protocol the NIO transport can give performance improvements over TCP so if you use ActiveMQ as your only broker use one of these. However using AMQP means in the future you could possibly use RabbitMQ, another popular Message Broker. There are others, STOMP or MQTT are lightweight, VM is designed to be used when the application resides on the same machine as the broker so gets very high throughput.
As ActiveMQ can enable all protocols by default do some quick tests to gain an idea of throughput on the specific application you are building. Then consider the above points in making a decison.
Regarding UDP, TCP, HTTP I would choose TCP. UDP is unreliable and TCP is more than adequate in sending 1000's per second. HTTP could be useful if your company has awkward firewall rules.
I would wrap this in a failover transport. I have never used discovery but would argue this is more advanced and not required initially as it requires a discovery agent. Its only purpose is too discover the ActiveMQ broker dynamically (although you still have to know where the discover agent is).
I am totally new to spring framework. I am trying to create a java maven project where I can have the connectivity to the rabbitMq and I even before publish the message, I want to check if the queues are alive or not. Is this possible to ping the queue to see if it a alive or not.. I am totally new to this rabbitMQ.
Thanks for the answers
Checking for the availability of a queue is a bit of an anti-pattern with messaging systems.
The message producer should not care if there is something on the other end to receive / process the message. The producer only cares that the RabbitMQ instance is available, with the correct exchange.
If the message must be delivered to a consumer, guaranteed, then the consumer needs to configure the queue with durability in mind and the producer should send the message with the persistence flag to ensure it is written to disk.
...
re-reading your question, i'm wondering if you mean "rabbitmq server" when you say "queue". are you wanting to check if the rabbitmq server is available?
if that is the case, the proper thing to do is use a heartbeat in your RabbitMQ connection. the spring framework should know how to do this, and should respond with some kind of event or other code that executes when the connection dies. i'm not really familiar with spring, though, so i don't know the details of doing that with this framework.
You might check this post or this RabbitMQ page on handling this.
What happens behind the scene, when receiving messages with (spring or ejb) message listener container in ActiveMQ/HornetQ?
Does broker pushing messages to consumers? If so, how consumers register
themselves to broker?
Or consumers polling messages on the queue? If so, why each queue (in admin console) has a consumer-number field that shows number of registered consumers of the queue?
This link of O'Reilly book said:
The p2p messaging model has traditionally been a pull- or
polling-based model, where messages are requested from the queue
instead of being pushed to the client automatically. (The JMS
specification does not specifically state how the p2p and pub/sub
models must be implemented. Either one may use push or pull, but at
least conceptually pub/sub is push and p2p is pull).
You are not stating the protocol, since ActiveMQ and HornetQ are multi protocol brokers the exact implementation may vary a bit. However, most protocols except HTTP/REST based ones pushes messages to the client. It's not possible to achive high throughput without a push strategy on the wire protocol level.
The application level API allows for "polling", i.e. JMS MessageConsumer.receive, but that's really just a "sleep until a message is pushed" mechanism.
What is common and useful uses of JMS and Message Driven Beans?
Asynchronous communication: The caller returns quickly, and can continue its work (without creating a new thread) and the message can be processed later. Messages can be stored, and even when the server fails, they can continue to be processed, once the server starts up again. Messages can be distributed to multiple machines (optionally based on rules).
Callers and callees can be decoupled (the caller doesn't have to know, who will consume the message, and how many message consumers there are).
It can have enormous performance advantages compared to synchronous communication. Such a messaging middleware can be crucial for services that have to handle lots of messages per second (think of Twitter for example). But it's not restricted to human readable messages.
Another reason to choose JMS and MDBs is guaranteed delivery. A synchronous, point to point call fails if the receiver is unavailable, but a queue can be set up to guarantee delivery, handle retries or transactional failures, use error queues for messages that are "poison", etc.
There are two transmission models built into JMS: point-to-point using queues and publish/subscribe using topics. Each has its own advantages.
The downside of JMS and MDBs is speed of response. You might like the decoupling, but if you block and wait for a response it'll certainly be slower than a direct remote method invocation, because there are two network trips involved instead of just one.