tag:blogger.com,1999:blog-14758839.post4634092768967970988..comments2008-08-16T20:21:35.770+01:00Yossi Dahanhttp://www.blogger.com/profile/00273796629458942657noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-14758839.post-80108742854100387662008-08-16T20:21:00.000+01:002008-08-16T20:21:00.000+01:00Yes, that's what we're looking at doing, the problem is that you have to be very careful in the orchestration you use to "handle" the errors - you don't want to ignore any other failures, and you losse the native ability to retry on the other "real" errors.Yossi Dahanhttp://www.blogger.com/profile/00273796629458942657noreply@blogger.comtag:blogger.com,1999:blog-14758839.post-53883050949563106452008-08-16T19:55:00.000+01:002008-08-16T19:55:00.000+01:00Hi Yossi,<BR/><BR/>I think we encountered the same situation as you. What we did was to have our orchestration have an error handler to do what it does, but we also enabled routing errors on the send port and created a subscription which would pick up any of these errors and just log to the event log that it had cleaned up this message.<BR/><BR/>Its a bit of a pain I completely agree but this work around did the job for usmikehttp://geekswithblogs.net/michaelstephensonnoreply@blogger.com