Pause processing of messages

[Shane Holder]

I've been reading some of the posts on how to pause consuming messages.  It seems the proper way is to dispose the bus, is it Ok to do this from inside the Consumer?  

My scenario is in order to process the message I'm relying on a 3rd party.  If that 3rd party goes down (network outage, whatever) I want to pause processing for a while and let the messages queue up for a timeout period, after the timeout period I want to start processing again.  What is the proper way to achieve this using MT?

FWIW we're using RabbitMQ 3.0.1.

Thanks,

Shane

[Dru Sellers]

throw an exception in the consumer when you 3rd party is down

then you can have another svc that watches your 3rd party, and it can pause/resume your other service. keeps the concerns separated nicely. also kind of a watchdog pattern.

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To post to this group, send email to masstrans...@googlegroups.com.
To unsubscribe from this group, send email to masstransit-dis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/masstransit-discuss/-/sA7oZzh45VoJ.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Shane Holder]

Dru, 

Thanks for the reply. Unfortunately the only way I'll know that the service is up is to try and send the message.  I could possibly send a "failed to talk to 3rd party" message from the consumer which failed to another queue which could pause the service (when you mention that I'm assuming your referring to a windows service and something akin to net stop <svc>) but it seems that until the watchdog process is able to stop the service I could process several messages, and possibly end up with messages in the error queue.  I'd really like to have the process hosting the consumer realize that it's not doing anything and then stop the bus.

Is it considered bad form for an Consume(IConsumeContext<Message> msg) to issue a msg.Bus.Dispose()?

Thanks again,

Shane Holder

On Monday, December 17, 2012 9:18:31 PM UTC-6, Dru wrote:

throw an exception in the consumer when you 3rd party is down

then you can have another svc that watches your 3rd party, and it can pause/resume your other service. keeps the concerns separated nicely. also kind of a watchdog pattern.

On Fri, Dec 14, 2012 at 11:15 AM, Shane Holder <holder...@gmail.com> wrote:

I've been reading some of the posts on how to pause consuming messages.  It seems the proper way is to dispose the bus, is it Ok to do this from inside the Consumer?  

My scenario is in order to process the message I'm relying on a 3rd party.  If that 3rd party goes down (network outage, whatever) I want to pause processing for a while and let the messages queue up for a timeout period, after the timeout period I want to start processing again.  What is the proper way to achieve this using MT?

FWIW we're using RabbitMQ 3.0.1.

Thanks,

Shane

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To post to this group, send email to masstrans...@googlegroups.com.

To unsubscribe from this group, send email to masstransit-discuss+unsub...@googlegroups.com.

[Chris Patterson]

Yeah, that's really bad form actually.

What I've done in the past is have two buses in a service, a control bus and the "service" bus. The control bus instance is just listening for commands to control the main service. This isn't using the ControlBus feature of MT, this is different. Just a way to adjust the dials on the service out of band of the main service. The control bus in this case is just controlling the windows service essentially, stopping the "moving parts" of the service without taking the windows service to a stopped state.

To unsubscribe from this group, send email to masstransit-dis...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/masstransit-discuss/-/symqkP0BZhcJ.

[Richard Lowden]

Hi Shane, are there any instances where you would want messages to go onto the error queue vs being tried again at a later point in time?  For example, if the third-party request timed-out would it matter if it got resent again or would it be better on an error queue for manual investigation?

For the timeout you could implement a circuit-breaker class that your message consumer uses - multiple successive failures when talking to the third party could "break the circuit" and your message consumer could then use MassTranit's retry later on any messages consumed while the circuit is in it's open state... after a timeout period the circuit implementation would close again and would let messages through.  Allowing for multiple successive failures would mean occasional intermittent network blips wouldn't stop you processing messages.

Although this would mean the windows service is always running, taking messages from the queue and asking MT to retry again later, it would achieve the effect of not attempting to talk to the third-party system for a period of time.  For any exceptions that definitely mean total communication failure while the circuit was closed your code would still call MT's RetryLater.

[Shane Holder]

Chris,

Thanks, I was worried that might be a bad thing. :)  Using a "control" bus seems like a good approach, would you suggest keeping to the rabbit transport or could I use the loopback transport (since the consumer would be sending a message to the process it was hosted in) keeping in mind that if the process goes down I lose those messages but at that point I probably don't care.

Thanks again,

Shane Holder

On Wednesday, December 19, 2012 7:36:43 AM UTC-6, Chris Patterson wrote:

Yeah, that's really bad form actually.

What I've done in the past is have two buses in a service, a control bus and the "service" bus. The control bus instance is just listening for commands to control the main service. This isn't using the ControlBus feature of MT, this is different. Just a way to adjust the dials on the service out of band of the main service. The control bus in this case is just controlling the windows service essentially, stopping the "moving parts" of the service without taking the windows service to a stopped state.

On Wed, Dec 19, 2012 at 7:21 AM, Shane Holder <holder...@gmail.com> wrote:

Dru, 

Thanks for the reply. Unfortunately the only way I'll know that the service is up is to try and send the message.  I could possibly send a "failed to talk to 3rd party" message from the consumer which failed to another queue which could pause the service (when you mention that I'm assuming your referring to a windows service and something akin to net stop <svc>) but it seems that until the watchdog process is able to stop the service I could process several messages, and possibly end up with messages in the error queue.  I'd really like to have the process hosting the consumer realize that it's not doing anything and then stop the bus.

Is it considered bad form for an Consume(IConsumeContext<Message> msg) to issue a msg.Bus.Dispose()?

Thanks again,

Shane Holder

On Monday, December 17, 2012 9:18:31 PM UTC-6, Dru wrote:

throw an exception in the consumer when you 3rd party is down

then you can have another svc that watches your 3rd party, and it can pause/resume your other service. keeps the concerns separated nicely. also kind of a watchdog pattern.

On Fri, Dec 14, 2012 at 11:15 AM, Shane Holder <holder...@gmail.com> wrote:

I've been reading some of the posts on how to pause consuming messages.  It seems the proper way is to dispose the bus, is it Ok to do this from inside the Consumer?  

My scenario is in order to process the message I'm relying on a 3rd party.  If that 3rd party goes down (network outage, whatever) I want to pause processing for a while and let the messages queue up for a timeout period, after the timeout period I want to start processing again.  What is the proper way to achieve this using MT?

FWIW we're using RabbitMQ 3.0.1.

Thanks,

Shane

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.

To post to this group, send email to masstrans...@googlegroups.com.

To unsubscribe from this group, send email to masstransit-discuss+unsubscribe...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/masstransit-discuss/-/sA7oZzh45VoJ.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To post to this group, send email to masstrans...@googlegroups.com.
To unsubscribe from this group, send email to masstransit-discuss+unsub...@googlegroups.com.

[Tim Holden]

In regards to the RetryLater method called from within a Consumer, in my testing it would create one message for every consumer in the pool.  So, we had 10 consumers running in the pool and when RetryLater was called on the one received message, 10 copies were created in the pool.  Perhaps I was doing something wrong in how I called it.  So, instead of using RetryLater I throw an exception from the consumer and publish the message contained within it from a fault message handler.

 

Thanks,

Tim

[Tim Holden]

Thank you everyone for your help.  We tried creating a separate bus that then shutdown the main bus and that was the key.  Trying to shut down the bus from a handler within that same bus was causing it to block itself.

 

We appreciate all the input.  Thanks,

 

Tim

 

On Wednesday, December 19, 2012 7:36:43 AM UTC-6, Chris Patterson wrote:

Yeah, that's really bad form actually.

What I've done in the past is have two buses in a service, a control bus and the "service" bus. The control bus instance is just listening for commands to control the main service. This isn't using the ControlBus feature of MT, this is different. Just a way to adjust the dials on the service out of band of the main service. The control bus in this case is just controlling the windows service essentially, stopping the "moving parts" of the service without taking the windows service to a stopped state.

On Wed, Dec 19, 2012 at 7:21 AM, Shane Holder <holder...@gmail.com> wrote:

Dru, 

Thanks for the reply. Unfortunately the only way I'll know that the service is up is to try and send the message.  I could possibly send a "failed to talk to 3rd party" message from the consumer which failed to another queue which could pause the service (when you mention that I'm assuming your referring to a windows service and something akin to net stop <svc>) but it seems that until the watchdog process is able to stop the service I could process several messages, and possibly end up with messages in the error queue.  I'd really like to have the process hosting the consumer realize that it's not doing anything and then stop the bus.

Is it considered bad form for an Consume(IConsumeContext<Message> msg) to issue a msg.Bus.Dispose()?

Thanks again,

Shane Holder

On Monday, December 17, 2012 9:18:31 PM UTC-6, Dru wrote:

throw an exception in the consumer when you 3rd party is down

then you can have another svc that watches your 3rd party, and it can pause/resume your other service. keeps the concerns separated nicely. also kind of a watchdog pattern.

On Fri, Dec 14, 2012 at 11:15 AM, Shane Holder <holder...@gmail.com> wrote:

I've been reading some of the posts on how to pause consuming messages.  It seems the proper way is to dispose the bus, is it Ok to do this from inside the Consumer?  

My scenario is in order to process the message I'm relying on a 3rd party.  If that 3rd party goes down (network outage, whatever) I want to pause processing for a while and let the messages queue up for a timeout period, after the timeout period I want to start processing again.  What is the proper way to achieve this using MT?

FWIW we're using RabbitMQ 3.0.1.

Thanks,

Shane

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.

To post to this group, send email to masstrans...@googlegroups.com.

To unsubscribe from this group, send email to masstransit-discuss+unsubscribe...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/masstransit-discuss/-/sA7oZzh45VoJ.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To post to this group, send email to masstrans...@googlegroups.com.
To unsubscribe from this group, send email to masstransit-discuss+unsub...@googlegroups.com.