I am using Spring-Kafka and using request/reply templates. I am noticing that after awhile I encounter timeouts when one service calls the other. The only way this seems to resolve is when I change topic name from request1, reply1 to request2, reply2 and redeploy both sides.... What am I missing in the configuration of the listener and or requester side? It seems the after a period of time it goes stale
Related
Using Spring boot #RabbitListener, we are able to process the AMQP messages.
Whenever a message sent to queue its immediately publish to destination exchange.
Using #RabbitListener we are able to process the message immediately.
But we need to process the message only between specific timings example 1AM to 6AM.
How to achieve that ?
First of all you can take a look into Delayed Exchange feature of RabbitMQ: https://docs.spring.io/spring-amqp/docs/current/reference/html/#delayed-message-exchange
So, this way on the producer side you should determine how long the message should be delayed before it is routed to the main exchange for the actual consuming afterwards.
Another way is to take a look into Spring Integration and its Delayer component: https://docs.spring.io/spring-integration/docs/5.2.0.BUILD-SNAPSHOT/reference/html/messaging-endpoints.html#delayer
This way you will consume messages from the RabbitMQ, but will delay them in the target application logic.
And another way I see like start()/stop() the listener container for consumption and after according your timing requirements. This way the message is going to stay in the RabbitMQ until you start the listener container: https://docs.spring.io/spring-amqp/docs/current/reference/html/#containerAttributes
So using JMS and ActiveMQ, I can be sure that my message sent from my Spring Boot application using JmsTemplate will reach it's destination application even if that destination application is down at the time I send the message to ActiveMQ. As when the destination application starts up, it grabs the message from the queue. Great!
However.
What happens if my Spring Boot application tries to send a JMS message to a queue on the ActiveMQ server, but the ActiveMQ server is down at that point or the network is down and I get a connection refused exception?
What is the recommended way to make sure my application keeps trying to re-sends the message to ActiveMQ until it is successful? Is this something I have to develop into my application myself? Are there any nifty Spring tools or annotations which do this for me? Any advice on best practice or how I should be handling this scenario?
You can try Spring-Retry. Has lots of fine grain controls for it:
http://www.baeldung.com/spring-retry
https://github.com/spring-projects/spring-retry
If it is critical that you don't lose this message, you will want to save it to some alternative persistent store (e.g. filesystem, local mq server) along with whatever retry code you come up with. But for those occasional network glitches or a very temporary mq shutdown/restart, Spring-Retry alone should do the trick.
Couple of approaches I can think of
1. You can set up another ActiveMq as fallback. In your code you don't have to do anything, just change your broker url from
activemq.broker.url=tcp://amq01.blah.blah.com:61616
to
activemq.broker.url=failover:(tcp://amq01.blah.blah.com:61616,tcp://amq02.blah.blah.com:61616)?randomize=false
The rest is automatically taken care of. i.e. when one of them is down, the messages are sent to other.
Another approach is to send to a internal queue (like seda, direct) when activemq is down and read from there.
Adding failover to the url is one appropriate way.
And another reasonable way is to making sure activemq always online , as activemq has the master-slave mode(http://activemq.apache.org/masterslave.html) to get high availability.
I am using Spring Integration in my project.
We have a requirement that in case where we will have stop Spring standalone service if database goes down.
In Message listener when I persist the data into database I check if I get CannotGetJdbcConnectionException then stop the Spring service using applicationContext.close() method.
Problem here is if I received any message on to the Queue and database goes down.
I tried to close Spring service then all resource goes down except DefaultMessageListenerContainer that holds that message.
If I terminate the process manually then message goes into inbound Queue which is correct.
Is there any way I could stop Spring service forcefully and put the message back to Inbound Queue?
I hope I am clear with my point here.
Thanks
Sachin
You should configure the DMLC with setSessionTransacted(true) (acknowledge="transacted" when using the namespace to define the endpoints).
Then any in-flight messages will be rolled-back onto the queue.
//OVERVIEW//
I have a Java Swing Client that is pushing messages to a broker. For the producer, I am using the Spring SingleConnectionFactory:
org.springframework.jms.connection.SingleConnectionFactory
that is wrapped around an ActiveMQConnectionFactory:
org.apache.activemq.ActiveMQConnectionFactory
I am using the Spring JMSTemplate:
org.springframework.jms.core.JmsTemplate
to provide the mechanisms to send messages from the producer to the broker.
// PROBLEM //
Sometimes, the broker might go down, or the network might fail. When this happens, the only way I have been able to re-establish connection to the broker is to re-start the Swing application (producer) to re-initialize the components mentioned above.
Does anyone know how this might be done at run-time? Atempting to re-initialise beans at runtime sounds like a hack and I was wondering if there was a more elegant configuration option.
Thanks
I wonder what is the correct way to subscribe to a Topic using Spring.
I tried with a DefaultMessageListenerContainer, using a non-durable subscription, but it fails most of the time. There is an open bug (SPR-7833) that seems to point out it will not work for non-durable topic subscriptions.
Is there any alternative to the DMLC that supports auto-reconnection in case of failure?
By the way, I'm creating the DMLC programmatically, connecting to an embedded ActiveMQ 5.5.1 broker using the Failover Transport for automatic reconnection. Consuming messages from Queues work as expected even in the most bizarre scenarios, but no luck with Topics.