Selenium module: VNC recorder doesn't stop recording when test ends #6229
Replies: 3 comments 1 reply
-
Here are a few cases that I've seen that seem to be related to this: |
Beta Was this translation helpful? Give feedback.
-
Thanks a lot for your detailed explanation of the issue and the suggestions @deejgregor. I agree completely with your proposal and the following approach seems sensible:
We'd be very happy if you can provide a PR for 1 🙂 |
Beta Was this translation helpful? Give feedback.
-
So after searching for a few weeks why our tests in our CI got randomly stuck and run into timeouts, after a lot of debugging I found out that this issue seems to cause the problems (VNC recorder was consuming all resources until it died from memory starvation). As a consequence (we also found other problems) we re-implemented the video recording using Seleniums native video recorder. |
Beta Was this translation helpful? Give feedback.
-
Today, if VNC recording is enabled in
BrowserWebDriverContainer
, we create thevncRecordingContainer
and start it. Once the test is done, if we retain the recording (in afterTest and retainRecordingIfNeeded), the VNC recording isn't stopped before transcoding is started. Recording is normally only stopped in stop, which doesn't happen until after we retain the recording.In many cases this isn't too much of an issue as long as the transcoding with
ffmpeg
can process the recording faster than newer data is received. In this case, the screen will still be continue to be recorded while transcoding is happening, but eventually transcoding catches up, hits EOF on the input file andffmpeg
exits, at which point the file is copied and later the containers are stopped.I ran into two cases where this doesn't happen:
vnc-recording
container, which is available for amd64 only,ffmpeg
runs super slow and never has any hope of catching up. I'm working on a PR to make versions for other architectures. See: Multi-platform build vnc-recorder#5ffmpeg
's processing rate, even when the container architecture matches the host architecture. I can reproduce this with exampleselenium-container
if I increase the screen size.When the transcoder can't keep up, the
retainRecordingIfNeeded
method never returns and the test never completes.I was able to workaround this by sending a SIGSTOP to the VNC recorder process inside its Docker container. Note that we can't just stop the container because we need it around and running since that's where the transcoder runs--at least, that's where it runs today. You can see my workaround for OpenNMS.
A backward-compatible fix with existing
vnc-recording
containers would be to put a similar SIGSTOP solution in place, probably inafterTest
, I think (regardless of whether or not we want to retain the recording, I think it makes sense to stop recording in any event).A cleaner approach would be to add some more specific support to the container to stop recording (maybe a script that tells the python recording process to stop recording but stick around so the container doesn't stop). But this would require both vnc-recorder and testcontainers-java (and other language versions?) to be updated. My suggestion would be to first get the fix in place that works with existing containers. Work on a cleaner approach could start after that, if desired.
I'm happy to submit a PR with a cleaned up version of the SIGSTOP approach mentioned above along with a test case. I'm also very happy to take suggestions for other approaches and anything else you would like to be done with this. Note: it might make sense to add a (configurable?) delay before stopping recording.
Beta Was this translation helpful? Give feedback.
All reactions