Loading ...
Sorry, an error occurred while loading the content.
 

Exception handling in NServiceBus

Expand Messages
  • reed.mscott
    I have seen the web pages and so forth all stating that exceptions should not be caught, and I agree with that. However, how do you tell NServiceBus which
    Message 1 of 9 , Sep 24, 2012
      I have seen the web pages and so forth all stating that exceptions should not be caught, and I agree with that. However, how do you tell NServiceBus which exceptions should be retried and which ones have no hope of ever succeeding? In other words if a database connection fails, then retry, but if you get back the document doesn't exist, it doesn't matter how many times you try it will never work, and you will be wasting resources by retrying. How do you let NServiceBus know which case is which?

      Also, (slightly related) is there a way of plugging into the exception pipeline, such that I can make sure a message is sent back without looking in the error queue? I basically need the equivalent of a finally block (or a final catch block) so that I can send a message back. I can do that via the error queue, but that seems like more work because I will have many different types of messages in there, and I would have to have some sort of switch logic to send the right failure message.
    • kijana.woodard
      This is a tough problem. The Second Level Retries came about because people felt messages ended up in the error queue too fast. AFAIK, there s nothing that
      Message 2 of 9 , Sep 24, 2012
        This is a tough problem.

        The Second Level Retries came about because people felt messages ended up in the error queue too fast.

        AFAIK, there's nothing that let's you say, "put this in the error queue now". For the most part, it doesn't matter. You can let these hopeless messages work their way to error queue and when you see them, figure out how you got into this situation.

        In practice, you should rarely be in that situation in production. Paths that lead to "can never work" should be dealt with before commands are put on the bus. Commands should be "highly likely to succeed".

        Production exceptions tend to be temporal "oh, the db is down for a bit, try again in 10 minutes".

        Second Level Retries is the easy path answer to the second part of your question. It will bring messages back into your main queue, by default, 3 times giving you ~15 chances to process the message.

        http://nservicebus.com/SecondLevelRetries.aspx

        Does that make some sense?

        --- In nservicebus@yahoogroups.com, "reed.mscott" <scott@...> wrote:
        >
        > I have seen the web pages and so forth all stating that exceptions should not be caught, and I agree with that. However, how do you tell NServiceBus which exceptions should be retried and which ones have no hope of ever succeeding? In other words if a database connection fails, then retry, but if you get back the document doesn't exist, it doesn't matter how many times you try it will never work, and you will be wasting resources by retrying. How do you let NServiceBus know which case is which?
        >
        > Also, (slightly related) is there a way of plugging into the exception pipeline, such that I can make sure a message is sent back without looking in the error queue? I basically need the equivalent of a finally block (or a final catch block) so that I can send a message back. I can do that via the error queue, but that seems like more work because I will have many different types of messages in there, and I would have to have some sort of switch logic to send the right failure message.
        >
      • reed.mscott
        I agree completely that there should be a Second Level Retry. The issue is that there should also be a Don t Bother Retrying (with either the first level or
        Message 3 of 9 , Sep 25, 2012
          I agree completely that there should be a Second Level Retry. The issue is that there should also be a Don't Bother Retrying (with either the first level or the second level). Examples of this are when there is a business domain problem, like something is now in the wrong state, or a user should not be allowed to do that operation. It doesn't matter how many times you retry it will never work, so don't waste resources on it. I see no way of influencing this, but I can't be the first person to come across this issue. I am looking for something similar to the Exception policies for Enterprise library as it relates to NServiceBus.

          The issue I have with the error queue is that all of the exceptions (something is now in the wrong state, the user is not allowed to do that, as well as the database is down) end up going to the error queue. I just don't like handling all types of errors (IT *and* business) in a central place.

          Re SLR: So is the only way to look at the config file at the maximum number attempts and figure out if this is that attempt, and if so do something else? That seems rather kludgy to me.


          --- In nservicebus@yahoogroups.com, "kijana.woodard" <nservicebus@...> wrote:
          >
          > This is a tough problem.
          >
          > The Second Level Retries came about because people felt messages ended up in the error queue too fast.
          >
          > AFAIK, there's nothing that let's you say, "put this in the error queue now". For the most part, it doesn't matter. You can let these hopeless messages work their way to error queue and when you see them, figure out how you got into this situation.
          >
          > In practice, you should rarely be in that situation in production. Paths that lead to "can never work" should be dealt with before commands are put on the bus. Commands should be "highly likely to succeed".
          >
          > Production exceptions tend to be temporal "oh, the db is down for a bit, try again in 10 minutes".
          >
          > Second Level Retries is the easy path answer to the second part of your question. It will bring messages back into your main queue, by default, 3 times giving you ~15 chances to process the message.
          >
          > http://nservicebus.com/SecondLevelRetries.aspx
          >
          > Does that make some sense?
          >
          > --- In nservicebus@yahoogroups.com, "reed.mscott" <scott@> wrote:
          > >
          > > I have seen the web pages and so forth all stating that exceptions should not be caught, and I agree with that. However, how do you tell NServiceBus which exceptions should be retried and which ones have no hope of ever succeeding? In other words if a database connection fails, then retry, but if you get back the document doesn't exist, it doesn't matter how many times you try it will never work, and you will be wasting resources by retrying. How do you let NServiceBus know which case is which?
          > >
          > > Also, (slightly related) is there a way of plugging into the exception pipeline, such that I can make sure a message is sent back without looking in the error queue? I basically need the equivalent of a finally block (or a final catch block) so that I can send a message back. I can do that via the error queue, but that seems like more work because I will have many different types of messages in there, and I would have to have some sort of switch logic to send the right failure message.
          > >
          >
        • chrisbednarski76
          Have you looked at DoNotContinueDispatchingCurrentMessageToHandlers ?
          Message 4 of 9 , Sep 25, 2012
            Have you looked at DoNotContinueDispatchingCurrentMessageToHandlers ?

            --- In nservicebus@yahoogroups.com, "reed.mscott" <scott@...> wrote:
            >
            > I agree completely that there should be a Second Level Retry. The issue is that there should also be a Don't Bother Retrying (with either the first level or the second level). Examples of this are when there is a business domain problem, like something is now in the wrong state, or a user should not be allowed to do that operation. It doesn't matter how many times you retry it will never work, so don't waste resources on it. I see no way of influencing this, but I can't be the first person to come across this issue. I am looking for something similar to the Exception policies for Enterprise library as it relates to NServiceBus.
            >
            > The issue I have with the error queue is that all of the exceptions (something is now in the wrong state, the user is not allowed to do that, as well as the database is down) end up going to the error queue. I just don't like handling all types of errors (IT *and* business) in a central place.
            >
            > Re SLR: So is the only way to look at the config file at the maximum number attempts and figure out if this is that attempt, and if so do something else? That seems rather kludgy to me.
            >
            >
            > --- In nservicebus@yahoogroups.com, "kijana.woodard" <nservicebus@> wrote:
            > >
            > > This is a tough problem.
            > >
            > > The Second Level Retries came about because people felt messages ended up in the error queue too fast.
            > >
            > > AFAIK, there's nothing that let's you say, "put this in the error queue now". For the most part, it doesn't matter. You can let these hopeless messages work their way to error queue and when you see them, figure out how you got into this situation.
            > >
            > > In practice, you should rarely be in that situation in production. Paths that lead to "can never work" should be dealt with before commands are put on the bus. Commands should be "highly likely to succeed".
            > >
            > > Production exceptions tend to be temporal "oh, the db is down for a bit, try again in 10 minutes".
            > >
            > > Second Level Retries is the easy path answer to the second part of your question. It will bring messages back into your main queue, by default, 3 times giving you ~15 chances to process the message.
            > >
            > > http://nservicebus.com/SecondLevelRetries.aspx
            > >
            > > Does that make some sense?
            > >
            > > --- In nservicebus@yahoogroups.com, "reed.mscott" <scott@> wrote:
            > > >
            > > > I have seen the web pages and so forth all stating that exceptions should not be caught, and I agree with that. However, how do you tell NServiceBus which exceptions should be retried and which ones have no hope of ever succeeding? In other words if a database connection fails, then retry, but if you get back the document doesn't exist, it doesn't matter how many times you try it will never work, and you will be wasting resources by retrying. How do you let NServiceBus know which case is which?
            > > >
            > > > Also, (slightly related) is there a way of plugging into the exception pipeline, such that I can make sure a message is sent back without looking in the error queue? I basically need the equivalent of a finally block (or a final catch block) so that I can send a message back. I can do that via the error queue, but that seems like more work because I will have many different types of messages in there, and I would have to have some sort of switch logic to send the right failure message.
            > > >
            > >
            >
          • Scott Reed
            That is basically what I am doing now, a try catch in every handler catching the business exception that most business exceptions derive from. -Scott From:
            Message 5 of 9 , Sep 25, 2012

              That is basically what I am doing now, a try catch in every handler catching the business exception that most business exceptions derive from.

               

              -Scott

               

              From: nservicebus@yahoogroups.com [mailto:nservicebus@yahoogroups.com] On Behalf Of chrisbednarski76
              Sent: Tuesday, September 25, 2012 2:14 PM
              To: nservicebus@yahoogroups.com
              Subject: [nservicebus] Re: Exception handling in NServiceBus

               

               

              Have you looked at DoNotContinueDispatchingCurrentMessageToHandlers ?

              --- In nservicebus@yahoogroups.com, "reed.mscott" <scott@...> wrote:
              >
              > I agree completely that there should be a Second Level Retry. The issue is that there should also be a Don't Bother Retrying (with either the first level or the second level). Examples of this are when there is a business domain problem, like something is now in the wrong state, or a user should not be allowed to do that operation. It doesn't matter how many times you retry it will never work, so don't waste resources on it. I see no way of influencing this, but I can't be the first person to come across this issue. I am looking for something similar to the Exception policies for Enterprise library as it relates to NServiceBus.
              >
              > The issue I have with the error queue is that all of the exceptions (something is now in the wrong state, the user is not allowed to do that, as well as the database is down) end up going to the error queue. I just don't like handling all types of errors (IT *and* business) in a central place.
              >
              > Re SLR: So is the only way to look at the config file at the maximum number attempts and figure out if this is that attempt, and if so do something else? That seems rather kludgy to me.
              >
              >
              > --- In nservicebus@yahoogroups.com, "kijana.woodard" <nservicebus@> wrote:
              > >
              > > This is a tough problem.
              > >
              > > The Second Level Retries came about because people felt messages ended up in the error queue too fast.
              > >
              > > AFAIK, there's nothing that let's you say, "put this in the error queue now". For the most part, it doesn't matter. You can let these hopeless messages work their way to error queue and when you see them, figure out how you got into this situation.
              > >
              > > In practice, you should rarely be in that situation in production. Paths that lead to "can never work" should be dealt with before commands are put on the bus. Commands should be "highly likely to succeed".
              > >
              > > Production exceptions tend to be temporal "oh, the db is down for a bit, try again in 10 minutes".
              > >
              > > Second Level Retries is the easy path answer to the second part of your question. It will bring messages back into your main queue, by default, 3 times giving you ~15 chances to process the message.
              > >
              > > http://nservicebus.com/SecondLevelRetries.aspx
              > >
              > > Does that make some sense?
              > >
              > > --- In nservicebus@yahoogroups.com, "reed.mscott" <scott@> wrote:
              > > >
              > > > I have seen the web pages and so forth all stating that exceptions should not be caught, and I agree with that. However, how do you tell NServiceBus which exceptions should be retried and which ones have no hope of ever succeeding? In other words if a database connection fails, then retry, but if you get back the document doesn't exist, it doesn't matter how many times you try it will never work, and you will be wasting resources by retrying. How do you let NServiceBus know which case is which?
              > > >
              > > > Also, (slightly related) is there a way of plugging into the exception pipeline, such that I can make sure a message is sent back without looking in the error queue? I basically need the equivalent of a finally block (or a final catch block) so that I can send a message back. I can do that via the error queue, but that seems like more work because I will have many different types of messages in there, and I would have to have some sort of switch logic to send the right failure message.
              > > >
              > >
              >

            • kijana.woodard
              For business domain problems, they should be dealt with explicitly and not turn into exceptions that are bubbling up to the infrastructure. Stipulation: I
              Message 6 of 9 , Sep 25, 2012
                For business domain problems, they should be dealt with explicitly and not turn into exceptions that are bubbling up to the infrastructure.

                Stipulation: I recognize that what you gave was just an example.

                If a user isn't authorized, they shouldn't be allowed to submit the command. If a user submitted a command that they are _now_ not authorized for, that state should be detected and routed appropriately (SendUserAnEmailSayingWeWontDoWhatTheySaidCommand).

                If you find yourself with a lot of shifting sands in terms of business states like that, a Saga might be in order, precisely to handle such cases.

                --- In nservicebus@yahoogroups.com, "reed.mscott" <scott@...> wrote:
                >
                > I agree completely that there should be a Second Level Retry. The issue is that there should also be a Don't Bother Retrying (with either the first level or the second level). Examples of this are when there is a business domain problem, like something is now in the wrong state, or a user should not be allowed to do that operation. It doesn't matter how many times you retry it will never work, so don't waste resources on it. I see no way of influencing this, but I can't be the first person to come across this issue. I am looking for something similar to the Exception policies for Enterprise library as it relates to NServiceBus.
                >
                > The issue I have with the error queue is that all of the exceptions (something is now in the wrong state, the user is not allowed to do that, as well as the database is down) end up going to the error queue. I just don't like handling all types of errors (IT *and* business) in a central place.
                >
                > Re SLR: So is the only way to look at the config file at the maximum number attempts and figure out if this is that attempt, and if so do something else? That seems rather kludgy to me.
                >
                >
                > --- In nservicebus@yahoogroups.com, "kijana.woodard" <nservicebus@> wrote:
                > >
                > > This is a tough problem.
                > >
                > > The Second Level Retries came about because people felt messages ended up in the error queue too fast.
                > >
                > > AFAIK, there's nothing that let's you say, "put this in the error queue now". For the most part, it doesn't matter. You can let these hopeless messages work their way to error queue and when you see them, figure out how you got into this situation.
                > >
                > > In practice, you should rarely be in that situation in production. Paths that lead to "can never work" should be dealt with before commands are put on the bus. Commands should be "highly likely to succeed".
                > >
                > > Production exceptions tend to be temporal "oh, the db is down for a bit, try again in 10 minutes".
                > >
                > > Second Level Retries is the easy path answer to the second part of your question. It will bring messages back into your main queue, by default, 3 times giving you ~15 chances to process the message.
                > >
                > > http://nservicebus.com/SecondLevelRetries.aspx
                > >
                > > Does that make some sense?
                > >
                > > --- In nservicebus@yahoogroups.com, "reed.mscott" <scott@> wrote:
                > > >
                > > > I have seen the web pages and so forth all stating that exceptions should not be caught, and I agree with that. However, how do you tell NServiceBus which exceptions should be retried and which ones have no hope of ever succeeding? In other words if a database connection fails, then retry, but if you get back the document doesn't exist, it doesn't matter how many times you try it will never work, and you will be wasting resources by retrying. How do you let NServiceBus know which case is which?
                > > >
                > > > Also, (slightly related) is there a way of plugging into the exception pipeline, such that I can make sure a message is sent back without looking in the error queue? I basically need the equivalent of a finally block (or a final catch block) so that I can send a message back. I can do that via the error queue, but that seems like more work because I will have many different types of messages in there, and I would have to have some sort of switch logic to send the right failure message.
                > > >
                > >
                >
              • Andreas Öhlund
                I agree with Kijana! That said there a few situations where it might make sense to tweak this and we actually have a extension point for it. (answer turned
                Message 7 of 9 , Sep 26, 2012
                  I agree with Kijana!

                  That said there a few situations where it might make sense to tweak this and we actually have a extension point for it. 

                  (answer turned into a blog post)



                  Hope this helps!

                  /Andreas


                  On Wed, Sep 26, 2012 at 3:02 AM, kijana.woodard <nservicebus@...> wrote:
                   

                  For business domain problems, they should be dealt with explicitly and not turn into exceptions that are bubbling up to the infrastructure.

                  Stipulation: I recognize that what you gave was just an example.

                  If a user isn't authorized, they shouldn't be allowed to submit the command. If a user submitted a command that they are _now_ not authorized for, that state should be detected and routed appropriately (SendUserAnEmailSayingWeWontDoWhatTheySaidCommand).

                  If you find yourself with a lot of shifting sands in terms of business states like that, a Saga might be in order, precisely to handle such cases.



                  --- In nservicebus@yahoogroups.com, "reed.mscott" <scott@...> wrote:
                  >
                  > I agree completely that there should be a Second Level Retry. The issue is that there should also be a Don't Bother Retrying (with either the first level or the second level). Examples of this are when there is a business domain problem, like something is now in the wrong state, or a user should not be allowed to do that operation. It doesn't matter how many times you retry it will never work, so don't waste resources on it. I see no way of influencing this, but I can't be the first person to come across this issue. I am looking for something similar to the Exception policies for Enterprise library as it relates to NServiceBus.
                  >
                  > The issue I have with the error queue is that all of the exceptions (something is now in the wrong state, the user is not allowed to do that, as well as the database is down) end up going to the error queue. I just don't like handling all types of errors (IT *and* business) in a central place.
                  >
                  > Re SLR: So is the only way to look at the config file at the maximum number attempts and figure out if this is that attempt, and if so do something else? That seems rather kludgy to me.
                  >
                  >
                  > --- In nservicebus@yahoogroups.com, "kijana.woodard" <nservicebus@> wrote:
                  > >
                  > > This is a tough problem.
                  > >
                  > > The Second Level Retries came about because people felt messages ended up in the error queue too fast.
                  > >
                  > > AFAIK, there's nothing that let's you say, "put this in the error queue now". For the most part, it doesn't matter. You can let these hopeless messages work their way to error queue and when you see them, figure out how you got into this situation.
                  > >
                  > > In practice, you should rarely be in that situation in production. Paths that lead to "can never work" should be dealt with before commands are put on the bus. Commands should be "highly likely to succeed".
                  > >
                  > > Production exceptions tend to be temporal "oh, the db is down for a bit, try again in 10 minutes".
                  > >
                  > > Second Level Retries is the easy path answer to the second part of your question. It will bring messages back into your main queue, by default, 3 times giving you ~15 chances to process the message.
                  > >
                  > > http://nservicebus.com/SecondLevelRetries.aspx
                  > >
                  > > Does that make some sense?
                  > >
                  > > --- In nservicebus@yahoogroups.com, "reed.mscott" <scott@> wrote:
                  > > >
                  > > > I have seen the web pages and so forth all stating that exceptions should not be caught, and I agree with that. However, how do you tell NServiceBus which exceptions should be retried and which ones have no hope of ever succeeding? In other words if a database connection fails, then retry, but if you get back the document doesn't exist, it doesn't matter how many times you try it will never work, and you will be wasting resources by retrying. How do you let NServiceBus know which case is which?
                  > > >
                  > > > Also, (slightly related) is there a way of plugging into the exception pipeline, such that I can make sure a message is sent back without looking in the error queue? I basically need the equivalent of a finally block (or a final catch block) so that I can send a message back. I can do that via the error queue, but that seems like more work because I will have many different types of messages in there, and I would have to have some sort of switch logic to send the right failure message.
                  > > >
                  > >
                  >




                  --
                  http://andreasohlund.net
                  http://twitter.com/andreasohlund

                • Ramon Smits
                  ... You don t let NServiceBus know.. you do this handling yourself. There are technical and functional errors. Technical errors are due to technical issues,
                  Message 8 of 9 , Sep 26, 2012
                    On Mon, Sep 24, 2012 at 10:56 PM, reed.mscott <scott@...> wrote:
                    I have seen the web pages and so forth all stating that exceptions should not be caught, and I agree with that.  However, how do you tell NServiceBus which exceptions should be retried and which ones have no hope of ever succeeding?  In other words if a database connection fails, then retry, but if you get back the document doesn't exist, it doesn't matter how many times you try it will never work, and you will be wasting resources by retrying.  How do you let NServiceBus know which case is which?

                    You don't let NServiceBus know.. you do this handling yourself. There are technical and functional errors. Technical errors are due to technical issues, network connection dropped, out of memory and lots of related errors. Functional errors are NOT exceptions. Receiving a document does not exist is not an exception it is a result and this result can make you choose a alternate code path.

                    Usually these is no reason do use exception handling for such scenario's as you need to use exceptions for 'exceptional' situations which your problem probably is not.

                    In your situation you can either choose to drop the message (do a return) or publish/reply/send a message to handling this business alternate flow.

                    -- Ramon
                  • Udi Dahan
                    The statement it doesn t matter how many times you try it will never work doesn t take into account other messages that could be processed during the retry
                    Message 9 of 9 , Sep 26, 2012

                      The statement “it doesn't matter how many times you try it will never work” doesn’t take into account other messages that could be processed during the retry period that would resolve the problem – for example:

                       

                      UpdateDocument and CreateDocument – should the update really fail if handled a millisecond before the create?

                       

                      and

                       

                      DoSomething and GivePermissionToDoSomething – could be the user doesn’t have permission to “do something” but the message giving them those permissions could arrive soon after.

                       

                      We don’t necessarily need to be so pessimistic about business “failures”.

                       

                      Kind regards,

                       

                      Udi

                       

                       

                      From: nservicebus@yahoogroups.com [mailto:nservicebus@yahoogroups.com] On Behalf Of Ramon Smits
                      Sent: Wednesday, September 26, 2012 9:48 AM
                      To: nservicebus@yahoogroups.com
                      Subject: Re: [nservicebus] Exception handling in NServiceBus

                       

                       

                       

                      On Mon, Sep 24, 2012 at 10:56 PM, reed.mscott <scott@...> wrote:

                      I have seen the web pages and so forth all stating that exceptions should not be caught, and I agree with that.  However, how do you tell NServiceBus which exceptions should be retried and which ones have no hope of ever succeeding?  In other words if a database connection fails, then retry, but if you get back the document doesn't exist, it doesn't matter how many times you try it will never work, and you will be wasting resources by retrying.  How do you let NServiceBus know which case is which?

                       

                      You don't let NServiceBus know.. you do this handling yourself. There are technical and functional errors. Technical errors are due to technical issues, network connection dropped, out of memory and lots of related errors. Functional errors are NOT exceptions. Receiving a document does not exist is not an exception it is a result and this result can make you choose a alternate code path.

                       

                      Usually these is no reason do use exception handling for such scenario's as you need to use exceptions for 'exceptional' situations which your problem probably is not.

                       

                      In your situation you can either choose to drop the message (do a return) or publish/reply/send a message to handling this business alternate flow.

                       

                      -- Ramon


                      No virus found in this message.
                      Checked by AVG - www.avg.com
                      Version: 2012.0.2221 / Virus Database: 2441/5292 - Release Date: 09/25/12

                    Your message has been successfully submitted and would be delivered to recipients shortly.