Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Client can endlessly block in stopDetector if the server(s) fail replying F_STOP_ACQUISITION #896

Open
alejandrohomsp opened this issue Jan 23, 2024 · 0 comments
Labels
action - Bug Something isn't working as expected priority - Unclassified Priority not classified as yet status - Pending Task not yet started

Comments

@alejandrohomsp
Copy link

*Distribution:

Ubuntu 20.04

*Detector type:

Eiger

*Software Package Version:

6.0.0

Priority:

Low

*Describe the bug

With the Eiger detector, if the acquisition fails due to a detector head buffer overrun (a very large number of frames not fitting in the detector memory), a F_STOP_ACQUISITION might not be properly acknowledged. This can block the client in an endless loop, requiring a SIGKILL to stop the application.

Expected behavior

sls::Detector API should provide some kind of timeout mechanism. An additional timeout argument to the sls::DataSocket::Receive() family, used by sls::Module::sendToDetector() and co., might help to better deal with this kind of exceptions.

To Reproduce

Force a detector head buffer overrun and then stop the acquisition

Screenshots
Additional context
@alejandrohomsp alejandrohomsp added action - Bug Something isn't working as expected priority - Unclassified Priority not classified as yet status - Pending Task not yet started labels Jan 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
action - Bug Something isn't working as expected priority - Unclassified Priority not classified as yet status - Pending Task not yet started
Projects
None yet
Development

No branches or pull requests

1 participant