Nservicebus: Move .PurgeOnStartup(bool) to Transport

[ramonsmits]

Purge on startup seems to be a transport option. ASB does not support purge on startup and so it's strange that this method is even available in the configuration.

By moving it to the transport the transport config can add support for purge on startup or not.

It also can make the following suggestion easier to implement: https://github.com/Particular/NServiceBus.SqlServer/issues/203#issuecomment-229895194

``` c#
config.UseTransport().PurgeMode(PurgeMode.Truncate);
config.PurgeOnStartup(true); // If purge mode is not called, throw an exception stating that selecting a purge mode is explicit.

vs.

``` c#
config
    .UseTransport<SqlServer>()
        .PurgeOnStartup(true)
            .PurgeMode(PurgeMode.Truncate);

// or
config
    .UseTransport<SqlServer>()
        .PurgeOnStartup(true, PurgeMode.Truncate)

[andreasohlund]

I like it! We pass it to IPushMessages.Init() so we would have to remove it from there.

[MarcinHoppe]

Do we want to squeeze this into second public Beta or postpone until V7? I'm not proposing that we go either direction, just raising a question.

[SimonCropp]

+1 for v7

[danielmarbach]

V7 for me as well.

On Sat, Jul 2, 2016 at 12:42 PM, Simon Cropp [email protected]
wrote:

+1 for v7

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Particular/NServiceBus/issues/3897#issuecomment-230095627,
or mute the thread
https://github.com/notifications/unsubscribe/AAKost_0MPW-f4y49Me4gGpVoQfflkM6ks5qRkCxgaJpZM4JC86H
.

[andreasohlund]

I think we should remove it all together and provide scripts for purging instead

[SimonCropp]

so lets obsolete with warning in v6.1? and in the upgrade guide give instructions for the scripting side

[andreasohlund]

so lets obsolete with warning in v6.1? and in the upgrade guide give instructions for the scripting side

I'm good with that. @Particular/nservicebus-maintainers give a thumbs up and I'll raise a new issue for it?

[danielmarbach]

I want to get rid of it as well. But doesn't that mean it requires a
coordinated release of core and transport updates? Is the timing good since
we would like to focus on things with potentially more impact? Hop on a
call first?

On Thursday, September 22, 2016, Andreas Öhlund [email protected]
wrote:

so lets obsolete with warning in v6.1? and in the upgrade guide give
instructions for the scripting side

I'm good with that. @Particular/nservicebus-maintainers
https://github.com/orgs/Particular/teams/nservicebus-maintainers give a
thumbs up and I'll raise a new issue for it?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Particular/NServiceBus/issues/3897#issuecomment-248856857,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKosoDk5ODo3lalzo9ebZ0sRPu-2iIWks5qsk6AgaJpZM4JC86H
.

[andreasohlund]

I want to get rid of it as well. But doesn't that mean it requires a
coordinated release of core and transport updates?

Not if we only obsolete the config option with WARN => we don't have to touch the downstreams until the next major? (where the change would be trivial, just remove the code that does the purge)

[bording]

Do we know what sort of scenarios purge on startup is used for? Can we be sure all of those scenarios would be covered by a separate script vs. having NSB handle it?

[andreasohlund]

The sceanarios I know of:

• Smart client starting after a long period of being offline

Should be ok

• Website starting after being offline for a longer period of time

I think this will even be improved since we currently would purge on app pool recycles which would be unessesary. Now admins can just execute the script as part of the startup procedure/provisioning/whatever of the specific web instance?

@SeanFeldman @yvesgoeleven azure websites etc has hooks for this right?

[SeanFeldman]

@andreasohlund not following what a webapp hook would do with a transport.
ASB cannot purges queues BTW, only ASQ can.

[andreasohlund]

I just meant something to clear the input queue before the webapp starts?

This made me realize that for webapps purge is probably only relevant for msmq (where each instance would have its own local queue). For transports like ASQ all instances would likely share the same queue so purging would not be needed.

[SeanFeldman]

@andreasohlund indeed. Just keep in mind, purge operation is not an LCD :)

[bording]

Smart client starting after a long period of being offline

@andreasohlund Do you see a script being able to handle this, or would be saying that it would be up to the users to write the transport-specific purging code for this?

[andreasohlund]

I'd say we should do our best to given them the the code/script to do it, pretty much like we do here https://docs.particular.net/nservicebus/rabbitmq/operations-scripting#create-queues

then users can take that and wire it into their apps as they see fit?

[SeanFeldman]

@andreasohlund transports that can promise purge is a possible operation, then yes. If transports cannot ensure a proper purge, we shouldn't provide anything that is misleading.

[andreasohlund]

If transports cannot ensure a proper purge, we shouldn't provide anything that is misleading.

I'd say the purge is best effort so even with ASQ can't we have a script that shows how to issue the purge. Then we add a disclaimer explaining what they can expect and things like "if you wait at least X there is a chance that the queue is purged".

We could even add a loop to the script that waits until num messages is zero? (or at least below X since messages might be coming into the queue at the same time)

[SeanFeldman]

We've got operational scripts that cover receiving messages.

We could even add a loop to the script that waits until num messages is zero? (or at least below X since messages might be coming into the queue at the same time).

The challenge with this approach is that you cannot receive messages that are scheduled for future in ASB @andreasohlund.

[andreasohlund]

The challenge with this approach is that you cannot receive messages that are scheduled for future in ASB

I think we have to see the purge as best effort since this apply to all transports (ie a timeout/retry can cause a message to appear in the queue right after the purge completes.

This is another reason to use scripts instead of the endpoint it self to purge since for the transports without native delays a script can make sure that the queue is truly empty before starting?

[ramonsmits]

Since yesterdays critical case I'm completely confident that PurgeOnStartup should not be in core or transport package. I still see it as a transport concern but that should be done via powershell scripting or something else but not be part of the main packages and only in the perspective of operations/maintenance.

I propose to close this issue and create a new issue to drop PurgeOnStartup in the next major.

[andreasohlund]

Seems like we have consensus that PurgeOnStartup should go. Raised a separate issue to track that https://github.com/Particular/NServiceBus/issues/4740

Replaced by https://github.com/Particular/NServiceBus/issues/4740