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

Use lock for instance status update. #1566

Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -106,6 +106,7 @@
*
* @author Karthik Ranganathan, Greg Kim
* @author Spencer Gibb
* @author Olga Maciaszek-Sharma
*
*/
@Singleton
Expand Down Expand Up @@ -149,6 +150,7 @@ public class DiscoveryClient implements EurekaClient {
private final PreRegistrationHandler preRegistrationHandler;
private final AtomicReference<Applications> localRegionApps = new AtomicReference<>();
private final Lock fetchRegistryUpdateLock = new ReentrantLock();
private final ReentrantLock instanceStatusUpdateLock = new ReentrantLock();
// monotonically increasing generation counter to ensure stale threads do not reset registry to an older version
private final AtomicLong fetchRegistryGeneration;
private final ApplicationInfoManager applicationInfoManager;
Expand Down Expand Up @@ -1381,15 +1383,26 @@ void refreshInstanceInfo() {
applicationInfoManager.refreshLeaseInfoIfRequired();

InstanceStatus status;
try {
status = getHealthCheckHandler().getStatus(instanceInfo.getStatus());
} catch (Exception e) {
logger.warn("Exception from healthcheckHandler.getStatus, setting status to DOWN", e);
status = InstanceStatus.DOWN;
}
if (instanceStatusUpdateLock.tryLock()) {

Choose a reason for hiding this comment

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

I'm not sure if we need the fix here? Since both threads will call healthcheck to find latest status, unless healthcheck itself is flipping, the status would be the same? Maybe there is a race in update sequence, but the value would be consistent?

Copy link
Contributor Author

@OlgaMaciaszek OlgaMaciaszek Jan 13, 2025

Choose a reason for hiding this comment

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

Hi @howardyuan, thanks for the comment. You're right. I've taken another look at it and I now think the approach to take could be to have a compareAndSet logic while changing InstanceInfo.InstanceStatus within DiscoveryClient#refreshInstanceInfo to prevent a situation where the status has been changed by the other thread between getting original status from the field and setting its transformed value there. Could be done by changing that field into an actual AtomicReference or, to remain consistent with the current class implementation and avoid having to change/ add too many methods, keeping it as a volatile field and adding a synchronized method in that class that would first compare the expected field value with the actual one and calling that new method within DiscoveryClient#refreshInstanceInfo. Let me know what you think.

Choose a reason for hiding this comment

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

I think your suggestions of comparing before setting should be safe.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will work on it soon.

try {
try {
status = getHealthCheckHandler().getStatus(instanceInfo.getStatus());
}
catch (Exception e) {
logger.warn("Exception from healthcheckHandler.getStatus, setting status to DOWN", e);
status = InstanceStatus.DOWN;
}

if (null != status) {
applicationInfoManager.setInstanceStatus(status);
if (null != status) {
applicationInfoManager.setInstanceStatus(status);
}
}
finally {
instanceStatusUpdateLock.unlock();
}
}
else {
logger.warn("Cannot acquire update lock, aborting instance status refresh");
}
}

Expand Down
Loading