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.
Related
I have web service that handles requests and publishes messages to RabbitMQ (Written in spring boot).
The problem is when there is no connection I cannot detect it immediately and I am losing all my messages. How can I deal with this problem? I got AMQP Connection error after 30 seconds. In that interval I cannot handle this problem. I want to know when message delivered to RabbitMQ. If it is not delivered I need to store all messages and when rabbitmq is up resend all these messages. By the way, performance is important.
I have read documentations below. I think it could be solved with OperationsCallback but I dont know how..
https://docs.spring.io/spring-amqp/docs/current/reference/html/#scoped-operations
https://docs.spring.io/spring-amqp/docs/current/reference/html/#cf-pub-conf-ret
Thanks in Advance
its rather a rabbit MQ feature more than java or spring, which allows any message that is published to be acknowledged back to the publisher, see the below link for references on how:
https://www.rabbitmq.com/confirms.html
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.
I am working on a project and have decided to use Camel and ActiveMQ. I am attempting to create a route using Java and MQTT endpoints. Within this route I have also incorporated a Processor. This is what my route looks like:
from("mqtt:test?subscribeTopicName=zaq.avila.send")
//.process(new RestProcessor())
.to("mqtt:test?publishTopicName=zaq.avila.receive");
From my understanding, the route is consuming from zaq/avila/send, a processor is applied and then the message is published to zaq/avila/receive. The to() part does not appear to be happening, when I check the console, I see that the processor executes though no message is published to zaq/avila/receive. Also, within the web console I see that the messages in zaq/avila/send for enqueued and dequeued increment even when I only pusblished one message. In addition, if I shutdown ActiveMQ I get the following:
INFO | Waiting as there are still 1 inflight and pending exchanges to complete,
timeout in 7 seconds.
Also:
WARN | Error occurred while shutting down service: Endpoint[mqtt://test?publish
TopicName=zaq.avila.receive]. This exception will be ignored.
java.lang.NullPointerException
These exception make me wonder that the exchange is not completing and something is missing. I need help!
Have a look into Camel MQTT component documentation. There is note that this component can be only used for consuming messages if I understand it correctly.
Note: The component currently only supports polling (consuming) feeds.
It's quite weird. I'll investigate further.
This may not necessarily be the best answer, however, it works.
from("mqtt:test?subscribeTopicName=zaq.avila.send")
.process(new RestProcessor())
.to("jms:topic:zaq.avila.receive");
According to ActiveMQ Doc
MQTT messages are transformed into an JMS ByteMessage. Conversely, the body of any JMS Message is converted to a byte buffer to be the payload of an MQTT message.
I was able to publish an mqtt message to a topic, apply a processor and receive the modified message as an mqtt message even though the specified endpoint is JMS.
If anyone can think of any possible downfalls I would gladly appreciate hearing from you. In my opinion, this removes the need to publish messages as MQTT.
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.
We're using a Tibco client implementation of the JMS API. We have a MessageListener with an onMessage() implementation.
Is there a way with the Tibco client to inspect past (received) messages in the queue? (I realise this totally ignores the logical concept of a queue - I wondered if the queue implementation provided this workaround.)
No. Not for "past" messages.
Messages acknowledged by the receiver are removed from the queue - as their "function" is already done.
You could have a Listener configured to persist your messages in some DB or file - but for future messages.
A client uses a QueueBrowser object to look at messages on a queue without removing them.
#hawkeye Its not possible to browse messages from the past... At any point of time , you can browse destinations only for the pending messages.
There is no way for you browse all the received messages as EMS server usually deletes the message once it has delivered ( acknowledged) for the given delivery mode.
One possible way is to a send copy of the messages to another queue (without any receivers) before actually confirming the messages.
Also it depends on your acknowledgement mode and logic involved.