Dennis van der Stelt asked in the github issue:
The short answer, however, is, that we do not have such a tool or anything that helps.
That being said, I’d like to add two remarks:
- I’m not aware of many customers actually requiring such a tool, but maybe there are. We’d need to more carefully think through if this is something that is useful and what edge cases we’d need to think about when adding this to NServiceBus or release it as a separate tool. I will, however, take this into consideration and discuss this internally.
- Why are you creating these short-lived endpoints? If they perform a certain business actions, why would they only exist for a short time? And if these ‘respawn’ on a regular basis, can’t you have an endpoint that gets updated/redeployed instead of creating a new one, over and over again?
I work on a SaaS product that makes heavy use of powershell. Powershell has two interesting constraints:
- The endpoints I’m connecting to have strict throttling limitations. I am limited on both the number of client connections that are allowed and the number of messages sent in a time period.
- The connection handshake is relatively expensive vs say a https rest endpoint. It’s disadvantageous to constantly be creating a new connection both in terms of time/io but it also counts against throttling.
Additionally, we can have 100s of worker agents that all need to interact with the same powershell tenant endpoint.
The design we came up with then was to spin up a dedicated worker for each powershell tenant with its own queue on demand. This way we can funnel all requests for a specific tenant endpoint to a specific worker; we can persist the underlying powershell connection and limit the number of simultaneous requests being sent to the powershell endpoint.
However, as our query load is inconsistent - we might make 5 queries in 3 minutes but not make another query for several hours or days - we don’t want to pay the compute costs for the dedicated worker to be constantly sitting idle. So after a few minutes of inactivity we’ll tear down the worker.
When we tear down a worker, we also want to clean up the NSB transport/persistance resources that worker was using. We don’t want to flood the Azure Storage Account we’re using with 1000s of queues, tables, and blobs that aren’t being used.