We have been using a framework to use Spring AMQP , where the framework has set the SimpleMessageListenerContainer.setDefaultRequeueRejected(false),
Which means default messages will not be Requeued if throwing an exception from consumer .
Is there any way i can change this behavior without changing the SimpleMessageListenerContainer.setDefaultRequeueRejected(true)
If you mean can you set the container to not requeue by default but requeue for some exception, the only way you can do that is to set defaultRequeueRejected to true (the default) and use a custom error handler.
The default ConditionalRejectingErrorHandler is configured with a default FatalExceptionStrategy that treats certain unrecoverable exceptions as fatal (message conversion exceptions etc). When these exceptions are thrown the message is rejected and not requeued.
You can provide a custom FatalExceptionStrategy to the error handler and (since version 1.6.3) inject an instance of a subclass of ConditionalRejectingErrorHandler.DefaultExceptionStrategy and implement isUserCauseFatal() - this allows you to decide which exceptions are fatal (reject and don't requeue) and which should be requeued. The error handler achieves this by throwing AmqpRejectAndDontRequeueException which is a signal to the container to not requeue the message.
Prior to 1.6.3, you had to inject a complete implementation of FatalExceptionStrategy.
Related
using Spring Boot 2.1.6 and Spring AMQP/RabbitMQ neither of these application.properties do trigger a DLX/DLQ when an Exception is thrown in the #RabbitListener:
spring.rabbitmq.listener.direct.default-requeue-rejected=false
spring.rabbitmq.listener.default-requeue-rejected=false
instead isDefaultRequeueRejected() always evaluates to true. how do I change that to false to cause a proper DLX/DLQ?
Perhaps you are missing
spring.rabbitmq.listener.type=direct
?
I get the same result as you when that is missing - none of the listener properties are applied, including the one you are talking about.
spring.rabbitmq.listener.type=direct
spring.rabbitmq.listener.direct.default-requeue-rejected=false
works fine for me; failed messages are rejected without being requeued.
The default container type is simple so the direct property you set is ignored.
I am studying OOP, and I did not understood the concept of exception.
What are the correct uses of exceptions?
Why use exceptions when you already know a possible exception?
For example, I have seen a code sample where the programmer needed to access a file, and had an exception in case the file does not exist. Something like "catch(fileDoesNotExist e)".
Why not use an if to verify before take the action? And use exception only for not known issues, for logging or error messages.
The idea behind the concept of exception was to decouple the error handling code from the "normal" behaviour flow control. That lets to manage/handle the exception further up the call stack.
Historically, with structured language, error handling code (file opening error,...) was mixed within the "business" application code. It was also painful to improve the code in order to manage new error codes.
What are the correct uses of exceptions?
If it is not normal that your file doesn't exist or cannot be opened => it is considered as an exceptional situation => exception => exception handler
Why use exceptions when you already know a possible exception?
To decouple the business application code from the error handling. That eases source code readibility and maintenance.
Exception:
Exception is that interrupt(break) the normal flow of the program.It's thrown at runtime.
Exception Handling
Exception Handling is a mechanism to handle runtime errors such as ClassNotFound, IO, SQL, Remote etc
In java there are mainly two types of exception that checked and unchecked.Other than Error is there
Hierarchy of Exception classes in Java
Why use exceptions when you already know a possible exception?
basically exception handling use to mainly,we assuming in that our particular code will occur some(NullPointerException,ArrayIndexOutOfBoundsException etc..)exception.If we not Handle that,program will break.Actually that Exception it may or may not will happen.But so we need to handle normal flow of the program it occurred or not.Otherwise after that particular code section not executing.
I have an application instance, backed by a web service using OIM Webservices Connector.
This connector is used in a synchronous manner by OIM, so when I create a new account in OIM for this application instance, the webservice calls the partner link's method.
Until the method ends its execution, the OIM screen hangs (as expected).
What seems strange to me is that, no matter the partner link's method executes successfully or not (when it does not execute properly, it throws an exception), the OIM operation actually ignores the exception and completes the operation.
Even if I explicitly throw an exception in the BPEL, I can see the error in the webservice log in weblogic, but the OIM method completes anyway.
What one would expect from a situation like this, I guess, is that OIM could just give an error message on the screen, because the operation failed. But no, OIM ignores the errors and go on.
Then I've tried to change the process definition in Design Console to force the process to stop on any error, setting the flag "required for completion" below
So I think I am missing something here
How can I make OIM abort some operation when the webservice connector throws an exception?
Assuming you're throwing a ConnectorException, check in the 'Responses' tab that you have that exception mapped, and in the 'Task to Object Status Mapping' you're setting the desired target Object Status for the object status setted before.
We are using ActiveMQ 5.8.0 in combination with Spring JMS 3.2.3.RELEASE. The application listens to a queue using the Spring DefaultMessageListenerContainer, and objects are stored in an ActiveMQTextMessage using the Spring MappingJackson2MessageConverter.
We also use the ActiveMQ broker redelivery plugin, which is configured in activemq.xml. Messages are persisted in an Oracle database, also configured in activemq.xml.
Now we have the following problem: in about 60% of the messages that are redelivered, the javaClass property that is set on the message by the MappingJackson2MessageConverter is missing. This causes the following stack trace:
org.springframework.jms.support.converter.MessageConversionException: Could not find type id property [javaClass]
at org.springframework.jms.support.converter.MappingJackson2MessageConverter.getJavaTypeForMessage(MappingJackson2MessageConverter.java:360)
at org.springframework.jms.support.converter.MappingJackson2MessageConverter.fromMessage(MappingJackson2MessageConverter.java:176)
When examining the persisted messages in our database we see that the javaClass property is indeed missing. But the redeliveryDelay and AMQ_SCHEDULED_DELAY properties that are set by the RedeliveryPlugin are present.
Could this be caused by a bug in ActiveMQ? I see that RedeliveryPlugin.scheduleRedelivery() sets the marshalledProperties to null, which should be correct behaviour to ensure that all properties are serialised in Message.beforeMarshall(). But if the properties are created lazily and no method that creates them (i.e. getProperty() or some such) has been called yet, then nulling the marshalledProperties wipes out properties that have been set before the redelivery plugin.
The following unit test proves that this scenario is possible with the current implementation of org.apache.activemq.command.Message:
#Test
public void testGetPropertyAfterUnmarshallAndNullMarshalledProperties() throws IOException {
ActiveMQTextMessage msg = new ActiveMQTextMessage();
msg.setProperty(TYPEID_PROPERTY, TEST_CLASS);
OpenWireFormat wireFormat = new OpenWireFormat(CommandTypes.PROTOCOL_VERSION);
msg.beforeMarshall(wireFormat);
ByteSequence byteSequence = wireFormat.marshal(msg);
ActiveMQTextMessage unmarshalled = (ActiveMQTextMessage) wireFormat.unmarshal(byteSequence);
// simulate RedeliveryPlugin behaviour
unmarshalled.setMarshalledProperties(null);
assertNull(unmarshalled.getProperty(TYPEID_PROPERTY));
}
Has anyone seen this kind of behaviour when using the broker redelivery plugin? We started using the broker plugin because we were experiencing problems with the client redelivery mechanism, so going back to that is not an option.
I have implemented IErrorHandler in my WCF service to determine what should be sent to a client (ProvideFault) and for logging the exception (HandleError).
As part of this process I want to:
Send the client an error code with some standard text to hide the internal exception details.
Log the error with the same error code so that I can match up the entry in the log file with the error report from the client.
I have been looking into this and cannot find a way where the same error code will be guaranteed to be used in both methods as HandleError will be called at some time in the future on a separate thread. This would seem to rule out having some kind of class level counter as ProvideFault could be called twice before HandleError is called.
Has anyone come up against the same situation and worked out a solution/pattern to use in this scenario?