Core: Handles possible heap data corruption of OAuth2Util.AuthSession#headers

[tlm365]

Closes #10591.

[snazy]

Maybe just a simple

Suggested change

	synchronized (lock) {
	synchronized (this) {

?

[adutra]

TBH I'm not convinced that a lock solves a real problem. In practice, this method cannot be called concurrently, therefore just dissociating reading the field and writing the field back is enough to clarify the intents here:

Map<String, String> headers = this.headers;
this.headers = RESTUtil.merge(headers, authHeaders(config.token()));

[tlm365]

@snazy @adutra thanks so much for reviewing

Maybe just a simple?

@snazy I just wanna avoid using synchronized on class. See: https://stackoverflow.com/questions/442564/avoid-synchronizedthis-in-java

TBH I'm not convinced that a lock solves a real problem. In practice, this method cannot be called concurrently, therefore just dissociating reading the field and writing the field back is enough to clarify the intents here:

@adutra "this method cannot be called concurrently" - could you explain why, pls? The RESTUtil.merge(...) function read a volatile variable (headers), so I think synchronized might make sense here.

[adutra]

@tlm365 AuthSession.refresh() is invoked from two places:

• fromAccessToken(): creates a new AuthSession instance each time, so no concurrent access can happen here.
• scheduleTokenRefresh(): cannot be called concurrently given the access patterns (it's called first on catalog initialization – which we can assume is single-threaded –, then called by itself recursively from within the refresh executor thread).

[amogh-jahagirdar]

I agree with @adutra , I don't think a lock is necessary here. You can just read the volatile value into a temporary variable and use that temporary variable when merging and assign that to the field.

[tlm365]

@adutra @amogh-jahagirdar thanks for reviewing, I've updated it.

[amogh-jahagirdar]

Thanks @tlm365 I will merge when checks pass.