Masstransit retries and threads question

[Jakob Nordlander]

Hi,

Apologies if this has been posted before but I didn’t manage to find the answer using the search.

I am running Masstransit 3.5.0 using the Azure service bus and have a question regarding Masstransit retries.

Will a Masstransit consumer thread continue to process other messages while waiting for a retry delay to complete?

For example, if I have a consumer configured like below and I send 5 messages where I know message 1,2, 4 and 5 will be processed correctly but message 3 will cause an error that will have to be retried.

cfg.UseRetry(Retry.Except<ArgumentException>().Incremental(5, TimeSpan.FromSeconds(10), TimeSpan.FromSeconds(5)));
cfg.MaxConcurrentCalls = 1;

I would expect the consumer to process message 4 and 5 while waiting for message 3s retry delay to complete but this is not what I am seeing in my test application. Instead Masstransit appears to wait until all of the retries for message 3 have completed before processing message 4 and 5. Have I misunderstood how the retries work?

Any insight appreciated.

Jakob

[Chris Patterson]

What is your prefetch count and concurrency limit set to for the endpoint? It is true that retries will block a consumer as they are part of the pipeline and not really intended for long delays.

For longer delays, use message redelivery which leverages the scheduler of either Quartz or Service Bus natively to deliver the message. With version 3.5 redelivery should use a retry policy and properly error the message when the retry limit is reached.

__
Chris Patterson

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.
To post to this group, send email to masstrans...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/945b1d29-12c0-4682-88bd-c4f49c69371f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jakob Nordlander]

Thanks Chris, that makes sense. In this case I was running the subscriber with both concurrency limit and prefetch count set as 1 to force the issue. I think we just need to rethink or retries to run for a much shorter period of time. Do you have any recommendations for when you should switch from retries to redelivery?

Do you have any examples of how redelivery is configured in version 3.5? We do have some consumers using redelivery, they are however running Masstransit 3.3.5 but they have custom logic to terminate the redelivery if it goes on for too long. If it has become easier to configure this in 3.5 we would look at upgrading.

Thanks

Jakob

On Monday, December 5, 2016 at 4:00:38 AM UTC, Chris Patterson wrote:

What is your prefetch count and concurrency limit set to for the endpoint? It is true that retries will block a consumer as they are part of the pipeline and not really intended for long delays.

For longer delays, use message redelivery which leverages the scheduler of either Quartz or Service Bus natively to deliver the message. With version 3.5 redelivery should use a retry policy and properly error the message when the retry limit is reached.

__
Chris Patterson

On Sun, Dec 4, 2016 at 5:24 PM -0600, "Jakob Nordlander" <jakob.no...@gmail.com> wrote:

Hi,

Apologies if this has been posted before but I didn’t manage to find the answer using the search.

I am running Masstransit 3.5.0 using the Azure service bus and have a question regarding Masstransit retries.

Will a Masstransit consumer thread continue to process other messages while waiting for a retry delay to complete?

For example, if I have a consumer configured like below and I send 5 messages where I know message 1,2, 4 and 5 will be processed correctly but message 3 will cause an error that will have to be retried.

cfg.UseRetry(Retry.Except<ArgumentException>().Incremental(5, TimeSpan.FromSeconds(10), TimeSpan.FromSeconds(5)));
cfg.MaxConcurrentCalls = 1;

I would expect the consumer to process message 4 and 5 while waiting for message 3s retry delay to complete but this is not what I am seeing in my test application. Instead Masstransit appears to wait until all of the retries for message 3 have completed before processing message 4 and 5. Have I misunderstood how the retries work?

Any insight appreciated.

Jakob

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

To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.

[Chris Patterson]

The .UseRetry() filter is really meant to handle exceptional conditions -- a transient database availability issue, a flaky web service call, things like that. It isn't really meant for things that are expected to fail, or not yet be ready in the case of coordination with other events.

The .UseDelayedRedelivery() filter is meant to allow longer breaks, and uses a message scheduler to do the work (versus just awaiting Task.Delay(n)...

The example unit test (the documentation sure needs an update in this regard):

https://github.com/MassTransit/MassTransit/blob/develop/src/MassTransit.RabbitMqTransport.Tests/DelayRetry_Specs.cs#L71

On Mon, Dec 5, 2016 at 7:36 AM, Jakob Nordlander <jakob.no...@gmail.com> wrote:

Thanks Chris, that makes sense. In this case I was running the subscriber with both concurrency limit and prefetch count set as 1 to force the issue. I think we just need to rethink or retries to run for a much shorter period of time. Do you have any recommendations for when you should switch from retries to redelivery?

Do you have any examples of how redelivery is configured in version 3.5? We do have some consumers using redelivery, they are however running Masstransit 3.3.5 but they have custom logic to terminate the redelivery if it goes on for too long. If it has become easier to configure this in 3.5 we would look at upgrading.

Thanks

Jakob

On Monday, December 5, 2016 at 4:00:38 AM UTC, Chris Patterson wrote:

What is your prefetch count and concurrency limit set to for the endpoint? It is true that retries will block a consumer as they are part of the pipeline and not really intended for long delays.

For longer delays, use message redelivery which leverages the scheduler of either Quartz or Service Bus natively to deliver the message. With version 3.5 redelivery should use a retry policy and properly error the message when the retry limit is reached.

__
Chris Patterson

On Sun, Dec 4, 2016 at 5:24 PM -0600, "Jakob Nordlander" <jakob.no...@gmail.com> wrote:

Hi,

Apologies if this has been posted before but I didn’t manage to find the answer using the search.

I am running Masstransit 3.5.0 using the Azure service bus and have a question regarding Masstransit retries.

Will a Masstransit consumer thread continue to process other messages while waiting for a retry delay to complete?

For example, if I have a consumer configured like below and I send 5 messages where I know message 1,2, 4 and 5 will be processed correctly but message 3 will cause an error that will have to be retried.

cfg.UseRetry(Retry.Except<ArgumentException>().Incremental(5, TimeSpan.FromSeconds(10), TimeSpan.FromSeconds(5)));
cfg.MaxConcurrentCalls = 1;

I would expect the consumer to process message 4 and 5 while waiting for message 3s retry delay to complete but this is not what I am seeing in my test application. Instead Masstransit appears to wait until all of the retries for message 3 have completed before processing message 4 and 5. Have I misunderstood how the retries work?

Any insight appreciated.

Jakob

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

To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsubscribe...@googlegroups.com.

To post to this group, send email to masstrans...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/945b1d29-12c0-4682-88bd-c4f49c69371f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.

To post to this group, send email to masstransit-discuss@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/052e572a-3eb7-431a-80bb-4bc9193a5809%40googlegroups.com.