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

DeferredResult not thread-safe for isSetOrExpired call [SPR-13451] #18031

Closed
spring-projects-issues opened this issue Sep 9, 2015 · 3 comments
Closed
Assignees
Labels
in: web status: backported type: bug
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Sep 9, 2015

Jamie Hodkinson opened SPR-13451 and commented

The use of DeferredResult is usually from other threads than the one it was created on.

Clients may call isSetOrExpired to check the state of the result: however this may return stale information as it has no synchronization, unlike the setResultInternal method, which synchronizes.


Affects: 3.2.14, 4.1.7, 4.2.1

Issue Links:

  • #15118 Deadlocks with DeferredResult timeout handling on Tomcat
  • #15232 Make result-data accessible in onCompletion Event in DeferredResult
  • #19544 Concurrency problem in DeferredResult: potential double execution of handleResult

Referenced from: commits 73a2407, ae0d945, 045016e

Backported to: 4.1.8, 3.2.15

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Sep 10, 2015

Juergen Hoeller commented

It should be sufficient to declare the result and expired fields as volatile here, and to consistently access them with one reference per call only (which requires slight recoding of getResult). Full synchronization is only really necessary for result handler invocations.

Juergen

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Sep 10, 2015

Jamie Hodkinson commented

Agreed. Not sure what the policy is here for synchronization, but given this class may be subclassed, synchronizing on the instance of this class rather than a private lock could cause problems if its subclasses (or even other classes) do the same.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Sep 10, 2015

Juergen Hoeller commented

Indeed, in particular when trying to check the current state while another thread holds a full lock, volatile fields are preferable. This fix should not cause any regressions compared to the previous code, just make visibility of those fields more consistent.

Juergen

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web status: backported type: bug
Projects
None yet
Development

No branches or pull requests

2 participants