fix: stuck MJPEG clients when one client fails to initialize #676
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There was an issue with the Client implementation: if a socket started a connection on the internal MJPEG port and was never initialized, the entire server thread would be stuck in the while loop waiting for initialization. This broke other clients connected to the server: no frames would be received anymore. To reproduce on emulator / real device: - start an Appium server with mJPEG server enabled (`appium:mjpegServerPort:9100` for instance) - Start an Appium session that reads the mJPEG frames (using Appium Inspector for instance) - Then from `adb shell`: connect to the internal mJPEG server (default port 7810): `nc localhost 7810` - --> Streaming will be broken for the existing clients This fixes the problem by returning early: if the client is not ready initialization will be retried later if necessary (or never) instead of blocking the thread Another side effect is that we actually receive frames from `nc localhost 7810` instead of it being stuck
The committers listed above are authorized under a signed CLA. |
vbarbaresi
changed the title
vbarbaresi
changed the title
KazuCocoa
reviewed
Dec 31, 2024
| @@ -0,0 +1,75 @@ | |||
| package io.appium.uiautomator2.server.mjpeg; | |||
KazuCocoa
changed the title
mykola-mokhnach
approved these changes
Dec 31, 2024
github-actions bot
pushed a commit
that referenced
this pull request
Dec 31, 2024
## [7.1.9](v7.1.8...v7.1.9) (2024-12-31) ### Bug Fixes * stuck client when socket client never initializes ([#676](#676)) ([34161a3](34161a3))
|
🎉 This PR is included in version 7.1.9 🎉 The release is available on: Your semantic-release bot 📦🚀 |
|
Hi @vbarbaresi, congrats: the Appium project wants to compensate you for this contribution! Please reply to this comment mentioning @jlipps and @KazuCocoa and sharing your OpenCollective account name, so that we can initiate payment! Or let us know if you decline to receive compensation via OpenCollective. Thank you! |
|
Hi, thanks for the proposition, it's much appreciated! |
|
Thanks for letting us know, hope to see you again @vbarbaresi :-) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
There was an issue with the Client implementation: if a socket started a connection on the internal MJPEG port and was never initialized, the entire server thread would be stuck in the while loop waiting for the client to send something.
This broke other clients connected to the server: no frames would be received anymore.
To reproduce on emulator / real device:
appium:mjpegServerPort:9100for instance)adb shell: connect to the internal mJPEG server (default port 7810):nc localhost 7810nc localhost 9100This happens because the client connection is not sending a proper HTTP request: it simply tries to receive data and this wasn't supported.
In this particular case we should not wait forever and not stop streaming frames to other clients
Fix details
This patch fixes the problem by returning early: if the client is sending anything, initialization will be retried later if necessary instead of blocking the thread.
Another side effect is that we now actually receive frames using
nc localhost 9100: this command was previously stuck waiting for the client to send something.This can be useful for checking the status of the MJPEG server if we don't have a proper HTTP client handy
I added a unit test reproducing the bug by opening a socket connection to the MJPEG server and closing it without sending any data. Then verified that the server still works for another HTTP client. This test wouldn't pass before the fix