I have a Workflow Service that has a few receives that listen to MSMQ queues. I would like to implement the following behavior:
If a correlation exception occurs (ie - workflow instance is gone), throw away the message.
If an InstanceLockException occurs (ie - this workflow instance is doing something on another server), put the message in the retry queue.
I have tried putting TransactedReceiveScope around the Receive activities, but it will put the message in the retry queue on a correlation error. Plus, it causes a lot of problems under heavy load.
Without the TransactedReceiveScope, the message is thrown away if there is an InstanceLockException.
Is there a way to implement this behavior (maybe via behavior extensions)?
You can implement a IErrorHandler for WCF to catch all unhandled exceptions whether thrown by your app or by WCF. The thing you have to be careful about with the netMsmqBinding is that throwing a fault in this handler means the message has been "successfully" processed and it will taken off the queue. In your case when InstanceLockException occurs, you'll have to let it remain unhandled if you want the built-in MSMQ 4 retry handling to occur. You'll also need to allow the PoisonMessageException to remain unhandled for proper MSMQ retrying to occur.
I'm not familiar with using Workflow, but knowing how MSMQ and WCF work you could try this
When a CorrelationException occurs:
Catch the exception
Return from your service method
Since your service method doesn't throw an exception it will think the message was successfully processed and remove it from the queue.
When a InstanceLockException occurs:
Catch the exception
rethrow the exception
Since your service method throws and exception it will think the message was not successfully processed and move it to the retry queue.
I think you'll have to create a WCF custom behavior to catch those exceptions.
Related
I see that RabbitTemplate.convertAndSend() declares to throw AmqpException. Will this exception always be thrown if publishing a message will be unsuccessful or should one take extra measures, for example, using correlationConvertAndSend() along with a RabbitTemplate.ConfirmCallback.
Publishing to RabbitMQ is asynchronous; you will only get an exception for immediate failures (such as can't connect to the broker).
Publisher confirms and returns are needed for guaranteed delivery.
I understand NServiceBus's retry mechanism to be primarily for connectivity problems or database deadlock problems, which is great and I love it for that.
However, I would like to configure NServiceBus' retry mechanism to not bother with a retry if the exception is typeof(ApplicationException). My code throws this kind of exception when there is a broken business rule (like a customer on hold), so no matter how many times this message is retried by NServiceBus' quick-retry mechanism, it will fail. This scenario requires that users take action on the data and then use ServiceInsight to re-queue the message for processing.
Can this be done?
I would reconsider using your application logic to inform users about this type of errors using Reply or Return in your handler, that should be located in the catch (ApplicationException) section. Then users change the data and send the message again using your application, not ServiceInsight. In this case, do not re-throw the ApplicationException in your catch block and this will prevent NServiceBus from retrying your message handling.
If I queue up a bunch of tasks into ServiceStack MQ, they are picked up by registered handlers for processing as expected. However if my handler application exits during processing or crashes, the message seems to be gone for ever.
I see that it does support retries, and a dead letter queue, but are messages only retried if they explicitly throw and exception from the handler?
Is there any way to have the framework handle keeping the message around until a success result is returned from the handler?
I am wondering what would be the best practice when a consumer is not able to handle the message it receives. What would be the mechanism to notify the rabbit to it will either put it back on to the queue or move to an error queue?
im using the .net client from rabbitmq
Either discard it or put it on an error queue. If there is a problem with the message such that the consumer cannot handle it then do not put it back on the queue as the consumer will just try to read it again.
It is an exception so handle it as such. In the exception handling you should raise an error message stating what happened and what you have done with the message. Best practice is to put it on an error queue where it could be handled manually.
I'm using IDispatchMessageInspector to inspect request/response messages in my WCF service and log some data to our logging database. I also have a custom error handler which catches exceptions and transforms them to faults. I'd like to be able to log the exception (if any) in the IDispatchMessageInspector.BeforeSendReply() method but I cannot figure out how to capture exception data. Is there a fault collection of some sort that I should be looking for? I realize I could log the exception in the IErrorHandler.HandleError() method, but I'd like to include the exception details along with the other details that I'm capturing while inspecting the request/response messages. Thanks!
Here's something I wrote a while ago about this topic. Basically, an exception will cause a fault message to be sent to the client as a reply