I would like to learn an easy way to requeue a RabbitMQ if an exception is thrown in an SpringBoot application.
#RabbitListener(queues = TRANSACTION_171_REQUEST_QUEUE, errorHandler = "receiverExceptionHandler" )
public void listen171RequestsQueue(Transaction171Request request) {
try {
Transaction171Response response = null;
send171Response("OK", request.getNumeroFormularioRenach());
} catch (Exception e){
//Requeue message
}
}
My code behaviour is to consume a message and take it out of the queue independing of what it happens. I would like to requeue message in RabbitMQ if an exception is thrown.
Could you help me?
I am working in a SpringBoot application with Java 11.
RabbitMQ's default behavior is to requeue when there is an unhandled exception. In your case, you could remove the try..catch block or in the catch block just re-throw the exception.
Related
Working versions in the app
IBM AllClient version : 'com.ibm.mq:com.ibm.mq.allclient:9.1.1.0'
org.springframework:spring-jms : 4.3.9.RELEASE
javax.jms:javax.jms-api : 2.0.1
My requirement is that in case of the failure of a message processing due to say, consumer not being available (eg. DB is unavailable), the message remains in the queue or put back on the queue (if that is even possible). This is because the order of the messages is important, messages have to be consumed in the same order that they are received. The Java app is single-threaded.
I have tried the following
#Override
public void onMessage(Message message)
{
try{
if(message instanceOf Textmessage)
{
}
:
:
throw new Exception("Test");// Just to test the retry
}
catch(Exception ex)
{
try
{
int temp = message.getIntProperty("JMSXDeliveryCount");
throw new RuntimeException("Redlivery attempted ");
// At this point, I am expecting JMS to put the message back into the queue.
// But it is actually put into the Bakout queue.
}
catch(JMSException ef)
{
String temp = ef.getMessage();
}
}
}
I have set this in my spring.xml for the jmsContainer bean.
<property name="sessionTransacted" value="true" />
What is wrong with the code above ?
And if putting the message back in the queue is not practical, how can one browse the message, process it and, if successful, pull the message (so it is consumed and no longer on the queue) ? Is this scenario supported in IBM provider for JMS?
The IBM MQ Local queue has BOTHRESH(1).
To preserve message ordering, one approach might be to stop the message listener temporarily as part of your rollback strategy. Looking at the Spring Boot doc for DefaultMessageListenerContainer there is a stop(Runnable callback) method. I've experimented with using this in a rollback as follows.
To ensure my Listener is single threaded, on my DefaultJmsListenerContainerFactory I set containerFactory.setConcurrency("1").
In my Listener, I set an id
#JmsListener(destination = "DEV.QUEUE.2", containerFactory = "listenerTwoFactory", concurrency="1", id="listenerTwo")
And retrieve the DefaultMessageListenerContainer instance.
JmsListenerEndpointRegistry reg = context.getBean(JmsListenerEndpointRegistry.class);
DefaultMessageListenerContainer mlc = (DefaultMessageListenerContainer) reg.getListenerContainer("listenerTwo");
For testing, I check JMSXDeliveryCount and throw an exception to rollback.
retryCount = Integer.parseInt(msg.getStringProperty("JMSXDeliveryCount"));
if (retryCount < 5) {
throw new Exception("Rollback test "+retryCount);
}
In the Listener's catch processing, I call stop(Runnable callback) on the DefaultMessageListenerContainer instance and pass in a new class ContainerTimedRestart as defined below.
//catch processing here and decide to rollback
mlc.stop(new ContainerTimedRestart(mlc,delay));
System.out.println("#### "+getClass().getName()+" Unable to process message.");
throw new Exception();
ContainerTimedRestart extends Runnable and DefaultMessageListenerContainer is responsible for invoking the run() method when the stop call completes.
public class ContainerTimedRestart implements Runnable {
//Container instance to restart.
private DefaultMessageListenerContainer theMlc;
//Default delay before restart in mills.
private long theDelay = 5000L;
//Basic constructor for testing.
public ContainerTimedRestart(DefaultMessageListenerContainer mlc, long delay) {
theMlc = mlc;
theDelay = delay;
}
public void run(){
//Validate container instance.
try {
System.out.println("#### "+getClass().getName()+"Waiting for "+theDelay+" millis.");
Thread.sleep(theDelay);
System.out.println("#### "+getClass().getName()+"Restarting container.");
theMlc.start();
System.out.println("#### "+getClass().getName()+"Container started!");
} catch (InterruptedException ie) {
ie.printStackTrace();
//Further checks and ensure container is in correct state.
//Report errors.
}
}
I loaded my queue with three messages with payloads "a", "b", and "c" respectively and started the listener.
Checking DEV.QUEUE.2 on my queue manager I see IPPROCS(1) confirming only one application handle has the queue open. The messages are processed in order after each is rolled five times and with a 5 second delay between rollback attempts.
IBM MQ classes for JMS has poison message handling built in. This handling is based on the QLOCAL setting BOTHRESH, this stands for Backout Threshold. Each IBM MQ message has a "header" called the MQMD (MQ Message Descriptor). One of the fields in the MQMD is BackoutCount. The default value of BackoutCount on a new message is 0. Each time a message rolled back to the queue this count is incremented by 1. A rollback can be either from a specific call to rollback(), or due to the application being disconnected from MQ before commit() is called (due to a network issue for example or the application crashing).
Poison message handling is disabled if you set BOTHRESH(0).
If BOTHRESH is >= 1, then poison message handling is enabled and when IBM MQ classes for JMS reads a message from a queue it will check if the BackoutCount is >= to the BOTHRESH. If the message is eligible for poison message handling then it will be moved to the queue specified in the BOQNAME attribute, if this attribute is empty or the application does not have access to PUT to this queue for some reason, it will instead attempt to put the message to the queue specified in the queue managers DEADQ attribute, if it can't put to either of these locations it will be rolled back to the queue.
You can find more detailed information on IBM MQ classes for JMS poison message handling in the IBM MQ v9.1 Knowledge Center page Developing applications>Developing JMS and Java applications>Using IBM MQ classes for JMS>Writing IBM MQ classes for JMS applications>Handling poison messages in IBM MQ classes for JMS
In Spring JMS you can define your own container. One container is created for one Jms Destination. We should run a single-threaded JMS listener to maintain the message ordering, to make this work set the concurrency to 1.
We can design our container to return null once it encounters errors, post-failure all receive calls should return null so that no messages are polled from the destination till the destination is active once again. We can maintain an active state using a timestamp, that could be simple milliseconds. A sample JMS config should be sufficient to add backoff. You can add small sleep instead of continuously returning null from receiveMessage method, for example, sleep for 10 seconds before making the next call, this will save some CPU resources.
#Configuration
#EnableJms
public class JmsConfig {
#Bean
public JmsListenerContainerFactory<?> jmsContainerFactory(ConnectionFactory connectionFactory,
DefaultJmsListenerContainerFactoryConfigurer configurer) {
DefaultJmsListenerContainerFactory factory = new DefaultJmsListenerContainerFactory() {
#Override
protected DefaultMessageListenerContainer createContainerInstance() {
return new DefaultMessageListenerContainer() {
private long deactivatedTill = 0;
#Override
protected Message receiveMessage(MessageConsumer consumer) throws JMSException {
if (deactivatedTill < System.currentTimeMillis()) {
return receiveFromConsumer(consumer, getReceiveTimeout());
}
logger.info("Disabled due to failure :(");
return null;
}
#Override
protected void doInvokeListener(MessageListener listener, Message message)
throws JMSException {
try {
super.doInvokeListener(listener, message);
} catch (Exception e) {
handleException(message);
throw e;
}
}
private long getDelay(int retryCount) {
if (retryCount <= 1) {
return 20;
}
return (long) (20 * Math.pow(2, retryCount));
}
private void handleException(Message msg) throws JMSException {
if (msg.propertyExists("JMSXDeliveryCount")) {
int retryCount = msg.getIntProperty("JMSXDeliveryCount");
deactivatedTill = System.currentTimeMillis() + getDelay(retryCount);
}
}
#Override
protected void doInvokeListener(SessionAwareMessageListener listener, Session session,
Message message)
throws JMSException {
try {
super.doInvokeListener(listener, session, message);
} catch (Exception e) {
handleException(message);
throw e;
}
}
};
}
};
// This provides all boot's default to this factory, including the message converter
configurer.configure(factory, connectionFactory);
// You could still override some of Boot's default if necessary.
return factory;
}
}
I use spring boot 2.2.
In a method with transactional anocation, when I save via repository if there is no error, I want to send a message with rabbit mq.
How to be sure there is no error with repository?
#Transactional
public void save(CreditEvent creditEvent) {
repository.save(creditEvent);
//no error send message
}
if there is an error when sending message, I don't want to rollback saving operation.
Although it's Transactional and JPA, still it's a java method which if save failed then unchecked DataAccessException exception will be thrown and flow won't continue to send message.
class is a runtime exception, there is no need for user code to catch it or subclasses if any error is to be considered fatal (the usual case).
#Transactional
public void save(CreditEvent creditEvent) {
try {
repository.save(creditEvent);
//no error send message}
catch {
// send message
// rethrow error
}
}
I figured I would toss a question on here incase anyone has ideas. My MQ Admin created a new queue and alias queue for me to write messages to. I have one application writing to the queue, and another application listening on the alias queue. I am using spring jmsTemplate to write to my queue. We are seeing a behavior where the message is being written to the queue but then instantly being discarded. We disabled gets and to see if an expiry parameter was being set somehow, I used the jms template to set the expiry setting (timeToLive). I set the expiry to 10 minutes but my message still disappears instantly. A snippet of my code and settings are below.
public void publish(ModifyRequestType response) {
jmsTemplate.setExplicitQosEnabled(true);
jmsTemplate.setTimeToLive(600000);
jmsTemplate.send(CM_QUEUE_NAME, new MessageCreator() {
public Message createMessage(Session session) throws JMSException {
String responseXML = null;
try {
responseXML myJAXBContext.getInstance().toXML(response);
log.info(responseXML);
TextMessage message = session.createTextMessage(responseXML);
return message;
} catch (myException e) {
e.printStackTrace();
log.info(responseXML);
return null;
}
}
});
}
/////////////////My settings
QUEUE.PUB_SUB_DOMAIN=false
QUEUE.SUBSCRIPTION_DURABLE=false
QUEUE.CLONE_SUPPORT=0
QUEUE.SHARE_CONV_ALLOWED=1
QUEUE.MQ_PROVIDER_VERSION=6
I found my issue. I had a parent method that had the #Transactional annotation. I do not want my new jms message to be part of that transaction so I am going to add jmsTemplate.setSessionTransacted(false); before performing a jmsTemplate.send. I have created a separate jmsTempalte for sending my new message instead of reusing the one that was existing, which needs to be managed.
1. Background
We are evaluating Spring JMS and testing out the JMSTemplate for various scenarios - queues, topics (durable, non-durable).
We experienced message loss for non-durable topic subscribers and would like to seek clarifications here.
2. Problem Statement
a) We wrote a standalone java program that would call the JMSTemplate.receive method every n secs to receive messages synchronously from a non-durable topic**.
b) We noticed that there is always message loss after the 1st invocation of the JMSTemplate.receive method. This was due to the JMSTemplate.receive method stopping the connection when it reaches ConnectionFactoryUtils.releaseConnection(...).
JMSTemplate:
public <T> T execute(SessionCallback<T> action, boolean startConnection) throws JmsException
{
Assert.notNull(action, "Callback object must not be null");
Connection conToClose = null;
Session sessionToClose = null;
try {
Session sessionToUse = ConnectionFactoryUtils.doGetTransactionalSession(
getConnectionFactory(), this.transactionalResourceFactory, startConnection);
if (sessionToUse == null) {
conToClose = createConnection();
sessionToClose = createSession(conToClose);
if (startConnection) {
conToClose.start();
}
sessionToUse = sessionToClose;
}
if (logger.isDebugEnabled()) {
logger.debug("Executing callback on JMS Session: " + sessionToUse);
}
return action.doInJms(sessionToUse);
}
catch (JMSException ex) {
throw convertJmsAccessException(ex);
}
finally {
JmsUtils.closeSession(sessionToClose);
ConnectionFactoryUtils.releaseConnection(conToClose, getConnectionFactory(), startConnection); // the connection is stopped here
}
}
ConnectionFactoryUtils.releaseConnection(...):
public static void releaseConnection(Connection con, ConnectionFactory cf, boolean started) {
if (con == null) {
return;
}
if (started && cf instanceof SmartConnectionFactory && ((SmartConnectionFactory) cf).shouldStop(con)) {
try {
con.stop(); // connection was stopped here
}
catch (Throwable ex) {
logger.debug("Could not stop JMS Connection before closing it", ex);
}
}
try {
con.close();
}
catch (Throwable ex) {
logger.debug("Could not close JMS Connection", ex);
}
3. Validation with Spring Documentation
The Spring JMS documentation advised to use pooled connections, so we made sure we did.
Our java program is obtaining the JMS Connection Factories from WLS JMS and MQ JMS (LDAP) Providers and decorated with SingleConnectionFactory and CachingConnectionFactory in respective test cases.
This is what we observed during testing:
a) SingleConnectionFactory - Connection was stopped (Consumer/Session were closed as well).
b) CachingConnectionFactory - Connection was also stopped (although Consumer/Session were cached and not closed)
4. Questions:
a) Has anybody hit the same issue as us?
b) Would you consider this as a defect of Spring JMS for the use case of Non-Durable Subscriptions?
c) We are considering customizing a CachingConnectionFactory that won't stop the connection. Any downsides?
Note: We are aware that Async MessageListeners like DMLC/SMLC and Sync Durable Topic Subscribers using JMSTemplate would not have this issue. We just wish to clarify for Sync Non-Durable Topic Subscribers using JMSTemplate.
Would greatly appreciate any comments and thoughts.
Thanks!
Victor
I'm using JMS to perform some long-running import processes, but running into some duplicate message problems I don't quite understand.
The flow is as follows. Some backing bean code sends a message to a Message Bean. The message bean receives this message, polls a third party service, and then if there is new data to import, commits these rows into a database. The problem is that JMS is sending my message twice in instances where my import process is taking some time, approx 60 seconds or so. If there are no new rows to import and the process takes 30 seconds or so, the message is only sent once.
I thought it had something to do with the acknowledgement of the message receipt so the first thing I did (since the auto acknowledge wasn't working) was set the QueueSession to Session.CLIENT_ACKNOWLEDGE and put msg.acknowledge() in my onMessage method. Sadly, the messages were still being sent twice.
No error codes or Exceptions are thrown during any of this.
Here's the code.
In Backing Bean
public MyBackingBean(){
try {
InitialContext ctx = new InitialContext();
qconFactory = (QueueConnectionFactory) ctx.lookup(JMS_FACTORY);
qcon = qconFactory.createQueueConnection();
qsession = qcon.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
queue = (javax.jms.Queue) ctx.lookup(IMPORT_QUEUE);
qsender = qsession.createSender(queue);
qsender.setDeliveryMode(DeliveryMode.NON_PERSISTENT);
qcon.start();
} catch (JMSException e) {
System.out.println(e);
} catch (NamingException e) {
System.out.println(e);
}
public void startImport() {
try {
// send a JMS message for the long running job
MapMessage mapMessage = qsession.createMapMessage();
mapMessage.setObjectProperty("ipAddress", "127.0.0.1");
qsender.send(mapMessage);
} catch (JMSException e) {
e.printStackTrace();
} catch (Throwable te) {
te.printStackTrace();
}
}
In Import Message Bean
#Override
public void onMessage(Message msg) {
try {
// create an ADF Application Module
// poll a third party for some data
// copy these rows (if new) and then
// commit via the ADF Application Module
}
catch (Exception e){
// no errors are being thrown
}
}
For now, I'm disregarding the duplicate by checking to see if the message is a redelivery (msg.getJMSRedelivered()) and disregarding the duplicate, but I'm not too happy with the band-aid.
Does anyone have some pointers on this?
Will, I can't be sure what's happening, but realize that, with AUTO_ACKNOWLEDGE, the acknowledgement doesn't actually happen until the thread returns from the onMessage() call. Therefore, if you are spending 60 seconds in your onMessage() call, I'm not surprised at the redelivery.
With CLIENT_ACKNOWLEDGE, by calling msg.acknowledge(), you should be explicitly acknowledging the message. However, at what point are you doing that? After spending 60 seconds in onMessage()? Then you'd get the same behavior, I'd expect.
You can call msg.acknowledge() as soon as you enter your onMessage() call, but realize that means the message won't be redelivered in the event that something later in your onMessage() method crashes. But it looks like you're not using persistent delivery anyway, so perhaps you don't care.
Here's a good reference;
http://www2.sys-con.com/itsg/virtualcd/Java/archives/0604/chappell/index.html#s1