Hi I use spring rabbit to send message to rabbitmq.
I want to rollback sending message how can I do that ,my goal is to achive that in writing process.
Can anyone share code sample
Related
My requirement is to clear all the messages from queue before processing the flow or publishing anything in the queue.
We are using rabbitMQ and due to some reason messages are stucked in the queue and because of that we are facing some issue when we are counting the queue based on the messages. so for the next time before processing we have to clear the queue.
Here we have multiple queue like slave1, slave2,slave3 and when api will be triggered in the process section we have to clear the queue.
Kindly suggest how we can do this in mule3.
Mule 3 has a generic AMQP connector. It does not support administrative commands from a specific implementation like RabbitMQ, so you can't use the connector.
You could use RabbitMQ REST API and call it using the HTTP Request connector. See this previous answer to see how to delete queues with Curl, then implement the same request with HTTP Request: https://stackoverflow.com/a/29148299/721855
I am trying to create a Subscriber in my Spring Boot Application. My objective is that the publisher will send multiple messages to a topic and I have to get those message and process them .I noticed that the "handleMessage" of both Paho and Apache ActiveMq will process 1 message at a time. Is it possible to make it concurrent??
I have tried the following
Replaced Paho with ActiveMq
Provided concurrency in my listenercontainer
Provided prefetch in my subscribe URL
Please let me know if there is any way to make my MQTT subscriber to take multiple messages concurrently.
Thank You
If you supply your own thread pool you can have the handleMessage method pass the incoming message off to the threadpool to process and then pass the next message off to the pool.
I am using Spring AMQP to publish messages to RabbitMQ. Consider a scenario:
1. Java client sends a message to MQ usin amqpTemplate.convertAndSend()
2. But RabbitMQ is down OR there's some n/w issue
In this case the message will be lost? OR
Is there any way it'll be persisted and will be retried?
I checked the publish-confirm model as well but as I understood, ultimately we've to handle the nack messages through coding on our own.
The RabbitTemplate supports adding a RetryTemplate which can be configured whit whatever retry semantics you want. It will handle situations when the broker is down.
See Adding Retry Capabilities.
You can use a transaction or publisher confirms to ensure rabbit secured the message.
I am writing some automation ruby scripts to test the streams and messages in queue.
My stream looks like
source| processor| processor| sink
Spring xd creates 3 internal queues.Now i have written ruby consumer to hook to these internal queues to test messages after every module(source/sink/processor).I see that when I post 100 message to my source Some message are getting lost in my ruby client consumer because they are flowing in stream .I think the message are going to the next module ie processor .Is there any way i can get all the message in my ruby client and test them and then I can make those message flow through the stream.Is there a way such that multiple consumers can receive same message.?
If you are registering other consumers on the bus queues, they will compete with the modules for messages.
I suppose that you are looking for a tap: http://docs.spring.io/spring-xd/docs/current/reference/html/#_taps
Hope this helps,
Marius
I have a requirement to load messages from two queues and i am using ActiveMQ I have to implement the Retry mechanism in case of any error or network or application server failure and load back into the same Queue. Also, I want to load any poison messages to DLQ.
Please let me know if I can acheive these through Spring JMS. Also, please advise some good examples to accomplish this task. I checked Spring JMS documentation and have not much details in that.
This is a broker function with ActiveMQ - just configure the broker with the appropriate policies.
If using a DefaultMessageListenerContainer, you must use transacted sessions; then, if the listener throws an exception the message will be rolled back onto the queue and the broker's retry/DLQ policies kick in.
See the Spring documentation about enabling transactions.