PepperDash
[FEATURE]-Add a low priority static GenericQueue to the Global class
Is your feature request related to a problem? Please describe. For plugins, there are lots of times I'd like to put some work onto a low priority thread (polls, writing config) and instead of creating my own, it would be convenient if there was a Global GenericQueue for use across the application.
Describe the solution you'd like A GenericQueue in the Global class
Describe alternatives you've considered A low priority queue per plugin
@ngenovese11 What's the use case for something like this? You mention a couple, but my feeling is that polling should be handled by the device plugin itself. Config-writing is already set up so that if multiple changes happen quickly, the file won't be written to disk until a certain amount of time has passed.
Part of the issue is that something like this has possibility of being used inappropriately and causing issues for other plugins or devices in the system that don't use it.
The use case I've come up recently with is a PDU plugin where I have 18 of them. If they all poll at once, the system slows down dramatically. To mitigate, I've created a static queue for the plugin to share, so no matter how many instances there are, the polling will always happen one at a time. If the framework had a built in low priority work queue, it would easy to share this concept across multiple plugins. I agree there would have to be an understanding that there is no guarantee how quickly whatever needs to be done as plugins wouldn't be privy to other plugins utilizing the queue.
I think if we're talking about cases like this where all of the processes that need to be queued exist in the same plugin, it's likely best to have the queue and management of it be contained within the plugin. At the point that we start encountering processes between plugins that need to be queued to maintain sequential order, then a global queue might start to present value.
The biggest reason not to use a global queue is that it would only get a single thread to process queue items. A queue within a plugin gets it's own thread to process that queue's items. It's also possible that in many or most systems, the global queue wouldn't be used by any plugins, but making it static would add some resource consumption and probably an idle thread that would never be used.
Given the example of the PDU plugin, it really sounds like you've already found the optimal solution with the low priority work queue in the plugin.
In my mind the fact that it would only take up a single thread is an advantage. If the Queue is in the plugin(s), you could end up having multiple threads idle that are all intended for the same thing: low priority work. The reason I was thinking about putting this in the framework is that I already have three separate plugins utilizing this static shared queue concept (nvx for device registration, flex for building flex routes, apc for polling). I don't particularly care how quickly any of these things happen, and if I had a single shared Queue, it would use one thread as opposed to three.
As you said, the solution I have works, I just find that when I'm doing the same thing in more then one plugin, there's probably value in considering it for the framework.
