When, for example, an exception occurres in the middle of a spring integration flow, is there any way to get a path the message have traveled before the crash happend?
The message tracks its path only if #EnableMessageHistory is switched on.
Independently of error handling, Spring Integration always wraps any exception to the MessagingException which has failedMessage property.
Getting that message and analizing its MessageHistory.HEADER_NAME you get the path before an exception.
Related
I am getting a few sessionlostlock exceptions while sending some messages to our SB triggered function app. We've set up alerts to check whenever such an error occurs. Although these messages do get retried and there no messages are sent to the DLQ. How do I find out which messages gave these exceptions in the first place.
How do I find out which messages gave these exceptions in the first place?
According to documentation:
You can use MessagingException.Detail Property to get the detail information on the messaging exception.
public Microsoft.ServiceBus.Messaging.MessagingExceptionDetail Detail { get; }
References: Cause and resolution of SessionLockLostException, Class SessionLockLostException and SessionLockLostException(String, Exception)
Is there a way to configure Spring Integration channels such that in case of uncaught exceptions, the headers at the time of exception (if available) are published to the errorChannel along with the exception object?
Right now, I can subscribe to the 'errorChannel' and adds handling code there which is extremely useful. But in errorChannel, I can only get the exception; headers from the original channel are lost. I tried looking at the reference here (https://docs.spring.io/spring-integration/reference/htmlsingle/#namespace-errorhandler) but no luck.
The ErrorMessage payload is a MessagingException with 2 properties cause and failedMessage. The headers are available on the latter.
I'm trying to start up a spring-int-aws flow that is writing to an SQS queue, but the context won't load.
Error starting ApplicationContext. To display the auto-configuration report
re-run your application with 'debug' enabled.
2016-10-03 14:10:51.848 ERROR 3741 --- [ main]
o.s.boot.SpringApplication : Application startup failed
org.springframework.beans.factory.BeanCreationException: Error creating bean
with name 'org.springframework.integration.aws.outbound.SqsMessageHandler#0':
Bean instantiation via constructor failed; nested exception is
org.springframework.beans.BeanInstantiationException: Failed to instantiate
[org.springframework.integration.aws.outbound.SqsMessageHandler]: Constructor
threw exception; nested exception is java.lang.NoSuchMethodError:
org.springframework.cloud.aws.messaging.core.QueueMessagingTemplate.<init
(Lcom/amazonaws/services/sqs/AmazonSQS;Lorg/springframework/cloud/aws/core/env/ResourceIdResolver;)V
....
Did some research: Inside of the SQSMessageHandler (v 1.0.0-RELEASE) it's attempting to create a QueueMessagingTemplate using a declared AmazonSQS object, however the QueueMessagingTemplate (v1.1.3 Release) it requires an AmazonSQSAsync object in the constructor. Since spring-cloud-aws uses the sub-interface, it seems that spring-int-aws should as well.
Am I missing something, or should this be an issue filed against the project?
spring-integration-aws is built against 1.1.1.
Please open an issue there so we can make a compatible build.
That said, it's pretty unusual for Spring projects to break APIs in a point release, so we should raise an issue for spring-cloud-aws too, to ask them to restore the other ctor (if possible), and cross-link the issues.
I opened issues.
We would wait for the disposition of that issue before doing anything in spring-integration-aws (but we should still go ahead and support the async option).
In the error-channel attribute of message-driven-channel-adapter
I want the original inbound message as the payload not the payload at the point of failure. To achieve this I use claim-check-in/out and SimpleMessageStore. The UUID I get from claim-check-in is stored in the header of the original inbound message. This message is now consumed by the transformer and then webservice call.
When the service time out or transformation exception is thrown the error-channel of message-driven-channel-adapter does not get any message, also it seems to retry in its own infinite loop rather than throwing an exception to error-channel. Is this the expected behaviour, Please let me know if I am missing something.
I have a spring integration flow like this:
1) message-driven-channel-adapter ->
1.1) output-channel connected to -> service-activator -> outbound-channel-adapter (for sending response)
1.2) error-channel connected to -> exception-type-router
1.2.1) message is sent to different queues depending on the exception type using outbound-channel-adapter
I have set acknowledge="transacted" in message-driven-channel-adapter. I want to introduce rollback for a specific type of exception, after error-channel.
First, I tried to connect the exception-type-router output to service-activator. But i get exception:
Code:
<service-activator id="rollBackActivator" input-channel="RollBackChannel"
ref="errorTransformer" method="rollBackMessage"/>
public void rollBackMessage(MessagingException message){
TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
System.out.println("Message rolled back:"+TransactionAspectSupport.currentTransactionStatus().isRollbackOnly());
}
Exception:
org.springframework.messaging.MessageHandlingException: org.springframework.transaction.NoTransactionException: No transaction aspect-managed TransactionStatus in scope
Then, I tried with outbound-channel-adapter expression , But got another exception again
Code:
<outbound-channel-adapter id="rollbackOut" channel="RollBackChannel"
expression="T(org.springframework.transaction.interceptor.TransactionAspectSupport).currentTransactionStatus().setRollbackOnly()"/>
Exception:
org.springframework.messaging.MessageHandlingException: Expression evaluation failed: T(org.springframework.transaction.interceptor.TransactionAspectSupport).currentTransactionStatus().setRollbackOnly()
Please advise to implement rollback in this scenario.
The container uses local transactions on the session by default. There's no AOP involved. Simply throw an exception and the container will roll back the message.