Tweet
Short version:
- Would it be possible to implement a feature where v-ray standalone would accept an option to kill itself after n minutes of inactivity?
In our case, we would be interested to set V-Ray standalone to kill itself after about 15 minutes of inactivity.
The reason I'm not asking for a graceful exit is that if the process would exit with a non-zero exit code, we would see that something unexpected happened in our render manager...
---
Long version:
Some years ago, we ran DR jobs in tandem with our render manager.
This meant that we submitted a "master" job, which in turn would spawn a "slaves" job. In the master job, one machine would initiate the render with DR enabled. In the slaves job, V-Ray standalone was started on multiple machines (instead of a frame render). This mean that the render manager saw these machines as busy, not accepting some other task to execute. Once the master job was done, it would kill its corresponding slaves job, freeing up all the V-Ray standalone instances.
We removed this feature after having problems with the whole farm (except the master machine) getting stuck in the slaves job because of e.g. a super slow bucket or a V-Ray bug which caused the master machine to never exit its process. Instead we implemented good old fashioned region rendering of still images.
But today, we see a lot of potential with progressive rendering and many of the newer features of V-Ray rendering is attractive to use in combination with DR to speed up the render. However, if we were to re-implement DR in tandem with our render manager, we would like to make sure that we can never end up in that scenario again, where a majority of our farm (or basically the entire farm) would get stuck running idle V-Ray standalone instances forever (or until someone notices). If we were able to trust the slaves to kill themselves (resulting in a non-zero exit code), we would get notifications on that something has gone wrong and our render manager would highlight these processes as problematic. But more importantly, the farm would go on with other tasks instead of being stuck.
I realize this all is a hack and not the solution to the core problem, which is that we want to run DR in tandem with our render manager... but it's the best solution I can think of.
- Would it be possible to implement a feature where v-ray standalone would accept an option to kill itself after n minutes of inactivity?
In our case, we would be interested to set V-Ray standalone to kill itself after about 15 minutes of inactivity.
The reason I'm not asking for a graceful exit is that if the process would exit with a non-zero exit code, we would see that something unexpected happened in our render manager...
---
Long version:
Some years ago, we ran DR jobs in tandem with our render manager.
This meant that we submitted a "master" job, which in turn would spawn a "slaves" job. In the master job, one machine would initiate the render with DR enabled. In the slaves job, V-Ray standalone was started on multiple machines (instead of a frame render). This mean that the render manager saw these machines as busy, not accepting some other task to execute. Once the master job was done, it would kill its corresponding slaves job, freeing up all the V-Ray standalone instances.
We removed this feature after having problems with the whole farm (except the master machine) getting stuck in the slaves job because of e.g. a super slow bucket or a V-Ray bug which caused the master machine to never exit its process. Instead we implemented good old fashioned region rendering of still images.
But today, we see a lot of potential with progressive rendering and many of the newer features of V-Ray rendering is attractive to use in combination with DR to speed up the render. However, if we were to re-implement DR in tandem with our render manager, we would like to make sure that we can never end up in that scenario again, where a majority of our farm (or basically the entire farm) would get stuck running idle V-Ray standalone instances forever (or until someone notices). If we were able to trust the slaves to kill themselves (resulting in a non-zero exit code), we would get notifications on that something has gone wrong and our render manager would highlight these processes as problematic. But more importantly, the farm would go on with other tasks instead of being stuck.
I realize this all is a hack and not the solution to the core problem, which is that we want to run DR in tandem with our render manager... but it's the best solution I can think of.
Comment