search

paolosalvatori / ServiceBusExplorer

The Service Bus Explorer allows users to connect to a Service Bus namespace and administer messaging entities in an easy manner. The tool provides advanced features like import/export functionality or the ability to test topic, queues, subscriptions, relay services, notification hubs and events hubs.
MIT License
1.98k stars 577 forks source link

move long-running operations off of the UI thread #754

Open jamesmanning opened 7 months ago

jamesmanning commented 7 months ago

NOTE: only creating this issue since I see it mentioned as something needed long-term in other issues but all of them are closed AFAICT. This isn't something that's an easy fix by any means, but as I was hoping to maybe take a shot at this, I wanted to file this both as a place to keep notes and also to try to contribute help from any others that either have already started on this or tried and have valuable insights to share, or even @paolosalvatori just deciding whether he's ok with the idea or not

The proposed 'phases' would be:

Phase 1 - entire UI is still blocked, user can't cancel the operation, but there's a new modal dialog with an indeterminate progress bar that's just cycling and states that an operation is in progress. Bonus points for accepting a specific name for the operation

Phase 2 - entire UI is still blocked by modal, but the modal now includes a cancel button. Implementation should use async/await and CancellationTokenSource / CancellationToken

Phase 3 - progress bars (where possible) implement actual progress

Phase 4 (maybe, distant future) stop blocking the full UI, potentially allow multiple concurrent operations.

ErikMogensen commented 6 months ago

There has been some requests for a progress bar so this is something that will be appreciated if done properly, which is not easy.

Today, I would say that many operations are not blocking the UI thread. However, I have the feeling that all paths does not work properly when another operation is going on.

jamesmanning commented 6 months ago

The operations that block the UI thread (at least AFAICT / IME) are peek and receive+delete on queues/subscriptions. Admittedly, I may be an outlier when it comes to those, but as an example, I used it to drain 1.4M messages from a deadletter queue this past week and it took well over an hour and by all indications was blocking the UI thread the entire time (app won't paint, task manager shows it as not responding, etc).

There are probably tons of operations that either don't happen on the UI thread or do and just run quickly enough that I can't perceive that they're blocking the UI, it's really just those receive/peek operations that are problematic. :)

SeanFeldman commented 6 months ago

I used it to drain 1.4M messages from a deadletter queue this past week and it took well over an hour

Reading this thread, I can't shake off the fact that what SBE is doing is a workaround, to compensate for the missing feature, celebrating its 7th anniversary this month.

jamesmanning commented 6 months ago

@SeanFeldman agreed, although in this case, I needed to download the contents of the 1.4M messages, so a purge operation that didn't grab the message contents wouldn't have helped me in this particular case.