I recently pushed out some new updates and bug fixes to my PoshRSJob module. I am continuing to provide updates to this module based not only on the feedback on the GitHub Issues page, but also on things that I happen to think about as well to continue to make this an amazing module to use!
This update only included 3 major updates that I focused on and each one was important to help ensure that the module is more stable and provides more accurate data. I’ll highlight each update and provide a little bit of information for each one.
This one was an odd bug that I hadn’t encountered while using the module and during testing. Fortunately for me, others have really put this module through the ringer and have found some bugs that I doubt that I would have ever found.
What was happening was that the runspacepool monitor was determining that a newly created runspacepool was already past its expiration timestamp and would then dispose of the runspacepool which resulted in errors when runspaces being built on the runspacepool was trying to be invoked. The solution to this was actually very simple: when the runspacepool is created, set the time of expiration to 5 minutes in the future to give Start-RSJob enough time to create and start the runspaces within that runspacepool. Once the runspaces are going, the runspacepool monitor will update the timestamp as long as runspaces are still being used within the pool.
This one is not exactly a major bug, but still one that had to be dealt with and squashed.
Instead of using Break to halt all activity in the Wait-RSJob command and any subsequent commands, I instead use return instead which allows other commands to run after it. I had originally use Break because I wanted to ensure that no other commands within Wait-RSJob would, causing potential errors later on in the command.
This one was an issue that was reported a long time after I built this module but in the back of my mind was something that I really wanted to solve. Being able to track each runspace as its own job and to know if it was truly running or waiting to run would really change how PoshRSJob would look. Prior to this, all jobs showed as Running regardless of how many jobs were running. This led to a lot of confusion as to whether jobs were actually being throttled (they were) and this just added fuel to my fire of solving this issue.
This led me down the path of finding a useful way of determining which runspaces in a runspacepool were actually running while others were still waiting in the queue to kick off. In the end, I took what I learned with that and applied it to PoshRSJob. You can see an example in the image below.
There is still plenty to do with this module and I hope to continue to implement the various feature requests that others have asked for as well as the things that I would like to see done to make this an amazing module. Of course, I am always looking for others to help out with this if they want to contribute to any of the posted issues or if they happen to have other ideas.