spring-cloud / spring-cloud/spring-cloud-commons
Refreshing via ContextRefresher pins virtual threads
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 751
- Forks
- 744
- Avg merge
- 1d 14h
- Merged PRs (30d)
- 9
Description
Describe the bug
With virtual threads enabled a call to /actuator/refresh pins virtual threads.
The ContextRefresher uses synchronized on both refresh and refreshEnvironment, so it seems they are not ready for use with virtual threads:
public synchronized Set<String> refresh() {
Set<String> keys = refreshEnvironment();
this.scope.refreshAll();
return keys;
}
public synchronized Set<String> refreshEnvironment() {
Map<String, Object> before = extract(this.context.getEnvironment().getPropertySources());
updateEnvironment();
Set<String> keys = changes(before, extract(this.context.getEnvironment().getPropertySources())).keySet();
this.context.publishEvent(new EnvironmentChangeEvent(this.context, keys));
return keys;
}
There could be more places of course
Are there plans to support virtual threads (with ReentrantLock)?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with ContextRefresher.refresh and refreshEnvironment, then inspect the surrounding refresh flow for other synchronized sections. Reproduce the /actuator/refresh path with virtual threads and compare the locking behavior; done means refresh operations no longer pin virtual threads while preserving safe concurrent environment and scope refreshes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, spring-boot
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100