yadavay-amzn opened a new pull request, #57252:
URL: https://github.com/apache/spark/pull/57252

   ### What changes were proposed in this pull request?
   
   Follow-up to 
[SPARK-57891](https://issues.apache.org/jira/browse/SPARK-57891) (#57191). A 
review comment on the merged PR pointed out a contradiction in the 
thread-safety documentation:
   
   - `CredentialProvider` says: *"Implementations must be thread-safe: 
`resolve()` may be called concurrently from multiple threads after `init()` 
completes."*
   - `CredentialProviderLoader` said: *"the returned `CredentialProvider` 
instances are not guaranteed to be thread-safe; callers should synchronize on 
the provider or confine it to a single thread."*
   
   These conflict. The intended contract is thread-safe-required: 
`CredentialProviderLoader` caches and shares a single provider instance across 
callers, and `resolve()` may be invoked concurrently (e.g., credential 
refresh), so implementations must be thread-safe. This corrects the 
`CredentialProviderLoader` Javadoc to state that a returned (shared) instance 
may be used concurrently per the `CredentialProvider` contract, while keeping 
the note that the loader itself synchronizes its cached-provider access.
   
   ### Why are the changes needed?
   
   To remove the contradictory guidance so the SPI's thread-safety contract is 
unambiguous for provider implementers.
   
   ### Does this PR introduce _any_ user-facing change?
   
   No. Documentation-only change; no behavior change.
   
   ### How was this patch tested?
   
   Documentation-only. `core` compiles and `dev/lint-java` (checkstyle) passes.
   
   ### Was this patch authored or co-authored using generative AI tooling?
   
   Authored with assistance by Claude Opus 4.8.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to