Service bus - Set interval to wait between retries

[Erik Juhlin]

I'm new to service buses, but we have a problem that we think a
service bus might solve.

When communicating with an external service, we want to try X number
of times before putting it in an error queue or perhaps doing
something else (e.g. switch from credit card provider to invoice
provider).

But we don't want to do these calls directly after eachother. We want
to wait a certain time to give the external provider a chance to wake
up after a crash.

It seems like the Rhino Service Bus can do the first part, but is
there a way to wait between retries? Or is a service bus not suitable
for this?

[Ozan Yurtseven]

You can look at

http://ayende.com/blog/3802/rhino-service-bus-managing-timeouts

and

http://ayende.com/blog/3933/rhino-queues-feature-detecting-message-failures

2012/3/23 Erik Juhlin <erik.ju...@gmail.com>:

> --
> You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group.
> To post to this group, send email to rhino-t...@googlegroups.com.
> To unsubscribe from this group, send email to rhino-tools-d...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.
>

--
Ozan Yurtseven

CTO

InsuredPlay

Office: 0090 (212) 249 1762

Mobile:  0090 (544) 464 62 57

Skype: ozanyurt

Email: oz...@insuredplay.com

www.insuredplay.com

[Jason Meckley]

this sounds like a good candidate for a saga. here is one idea.

paymentsaga

 : Isagastate<paymentstate>

 : initializedby<submitpayment>

 : orchstrates<submitpaymentagain>

{

   public guid id {get;set;}

   public paymentstate state {get;set;} 

   public bool iscopmlete {get;set;}

   public void consume(submitpayment message)

   {

         var provider = paymentproviderfactory.create(message.paymenttype);

         if(provider.chargepayment(message...) == false)

         {

                state. failattempts = 1;

                var paymenttype = provider.getnextpaymentmethod(message...);

                bus.delaysend(datetime.now.addhours(4), new submitpaymentagain{paymenttype});

               return;

         }

         bus.send(new paymentprocessed());

         iscomplete = true;

   }

   public void consume(submitpaymentagain message)

   {

         var provider = paymentproviderfactory.create(message.paymenttype);

         if(provider.chargepayment(message...) == false)

         {

                if(state.failattempts == 3)

                {

                     bus.send(new paymentnoprocessed{...});

                     iscopmlete = true;

                     return;

                }

                state. failattempts ++;

                var paymenttype = provider.getnextpaymentmethod(message...);

                bus.delaysend(datetime.now.addhours(4), new submitpaymentagain{paymenttype});

         }

   }

[Scott]

I solved a similar problem using RSB. We have allow users to make
payments from their checking accounts. To do so, we use RSB to call a
third-party service to process the payment. This third party has
scheduled outages once a month that can last up to 6 hours (why, I
don't know. Don't get me started). When the service is down, we
don't want to repeatedly make calls to it for the same payment. I
wrote a custom MessageModule which overrides the error handling/retry
action that comes with RSB. This message module reads the retry
intervals from a config file. We use a fibonacci sequence to retry
the messages at successively longer intervals and we have the sequence
set so that the total time a message will be retried is > the possible
6 hour outage. This has worked perfectly for us.

That would solve the first part of your issue. As for switching to a
different provider, you could add logic to the MessageModule that
would force a switch in providers after a certain number of retries.

Good luck.

[Oren Eini (Ayende Rahien)]

I just love this story, more because you were able to plug into this and modify core behavior without needing anything else.

[Erik Juhlin]

Thanks Jason, this worked well. Seems like RSB is a good fit for our
current needs. :)