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

fix: added timeouts for reading data/getting connection #1361

Merged
merged 6 commits into from
Mar 5, 2024

Conversation

geneross
Copy link
Contributor

No description provided.

@sruehl sruehl requested a review from chrisdutz January 25, 2024 13:05
@chrisdutz
Copy link
Contributor

LGTM

@chrisdutz
Copy link
Contributor

However a bit more explanations on what a PR is about would have been nice ;-)

@geneross
Copy link
Contributor Author

geneross commented Mar 5, 2024

Thanks for paying attention. I was desperate to get an answer. Lost in permissions etc.
In general we've faced with case when TriggeredScraperImpl threads just silently dies partially because of network malfunction partially because of server bugs.
So TriggeredScraperImpl got 2 debug threads that watch on working threads and it static get connection method now re-throw unchecked PlcRuntimeException because otherwise it might re-throw checked exception that leads to working thread termination.
Second. PlcReadRequest.builder from LeasedPlcConnection now return class with execution timeout for innerPlcReadRequest.
Third. ConnectionContainer set container value to null when it can't get connection from the manager while trying to invalidate cached connection. Otherwise it created new LeasedConnection with same broken connection.

My apologies for brevity, I have to recall what I did 2 month ago. ))

@@ -120,14 +126,18 @@ public PlcReadRequest build() {
return new PlcReadRequest(){
@Override
public CompletableFuture<? extends PlcReadResponse> execute() {
CompletableFuture<? extends PlcReadResponse> future = innerPlcReadRequest.execute();
CompletableFuture<? extends PlcReadResponse> future =
innerPlcReadRequest.execute().orTimeout(Math.min(1000,maxUseDuration.toMillis()), TimeUnit.MILLISECONDS);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So as far as I remember the ConnectionPool ... that used to have a timer to invalidate a connection if being used too long ... but I guess in that case possibly the read operation never timed out, right? So this is an additional abort on the side of the user, correct?

@chrisdutz chrisdutz merged commit f5269b5 into apache:develop Mar 5, 2024
14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants