kurts
kurts

Reputation: 79

Could not get HttpClient cache - No ThreadContext available for thread id=1

I'm working on upgrading our service to use 3.63.0 (upgrading from 3.57.0) and I've noticed the following warning (with stack trace) shows up in the logs that wasn't there on the previous version:

2022-02-18 14:03:41.038  WARN 1088 --- [           main] c.s.c.s.c.c.AbstractHttpClientCache      : Could not get HttpClient cache.

com.sap.cloud.sdk.cloudplatform.thread.exception.ThreadContextAccessException: No ThreadContext available for thread id=1.
    at com.sap.cloud.sdk.cloudplatform.thread.ThreadLocalThreadContextFacade.lambda$tryGetCurrentContext$0(ThreadLocalThreadContextFacade.java:39) ~[cloudplatform-core-3.63.0.jar:na]
    at io.vavr.Value.toTry(Value.java:1414) ~[vavr-0.10.4.jar:na]
    at com.sap.cloud.sdk.cloudplatform.thread.ThreadLocalThreadContextFacade.tryGetCurrentContext(ThreadLocalThreadContextFacade.java:37) ~[cloudplatform-core-3.63.0.jar:na]
    at io.vavr.control.Try.flatMapTry(Try.java:490) ~[vavr-0.10.4.jar:na]
    at io.vavr.control.Try.flatMap(Try.java:472) ~[vavr-0.10.4.jar:na]
    at com.sap.cloud.sdk.cloudplatform.thread.ThreadContextAccessor.tryGetCurrentContext(ThreadContextAccessor.java:84) ~[cloudplatform-core-3.63.0.jar:na]
    at com.sap.cloud.sdk.cloudplatform.connectivity.RequestScopedHttpClientCache.getCache(RequestScopedHttpClientCache.java:28) ~[cloudplatform-connectivity-3.63.0.jar:na]
    at com.sap.cloud.sdk.cloudplatform.connectivity.AbstractHttpClientCache.tryGetOrCreateHttpClient(AbstractHttpClientCache.java:78) ~[cloudplatform-connectivity-3.63.0.jar:na]
    at com.sap.cloud.sdk.cloudplatform.connectivity.AbstractHttpClientCache.tryGetHttpClient(AbstractHttpClientCache.java:46) ~[cloudplatform-connectivity-3.63.0.jar:na]
    at com.sap.cloud.sdk.cloudplatform.connectivity.HttpClientAccessor.tryGetHttpClient(HttpClientAccessor.java:153) ~[cloudplatform-connectivity-3.63.0.jar:na]
    at com.sap.cloud.sdk.cloudplatform.connectivity.HttpClientAccessor.getHttpClient(HttpClientAccessor.java:131) ~[cloudplatform-connectivity-3.63.0.jar:na]
    at com.octanner.mca.service.MarketingCloudApiContactService.uploadContacts(MarketingCloudApiContactService.java:138) ~[classes/:na]
    ...

This happens when the following calls are made...

Using the lower level API

HttpClient httpClient = HttpClientAccessor.getHttpClient(destination); // warning happens here
ODataRequestResultMultipartGeneric batchResult = requestBatch.execute(httpClient);

Using the higher level API

service
  .getAllContactOriginData()
  .withQueryParameter("$expand", "AdditionalIDs")
  .top(size)
  .filter(filter)
  .executeRequest(destination)); // warning happens here

Even though this warning shows up in the logs the service requests do continue to work as expected. It's just a little concerning to see this and I'm wondering if maybe I have something misconfigured. I reviewed all of the java docs and the troubleshooting page and didn't see anything out of the ordinary other than how I am fetching my destination, but even using the DestinationAccessor didn't seem to make a difference. Also, I'm not doing any asynchronous or multi-tenant processing.

Any help you or guidance you can give on this would be appreciated!

Cheers!

Upvotes: 0

Views: 682

Answers (1)

Johannes Schneider
Johannes Schneider

Reputation: 184

Such an issue is often the result of missing Spring Boot annotations - especially in synchronous executions.

Please refer to our documentation to learn more about the SAP Cloud SDK Spring Boot integration.


Edit Feb. 28th 2022

It is safe to ignore the logged warning if your application does not need any of the SAP Cloud SDK's multitenancy features.

Error Cause

The SAP Cloud SDK for Java recently (in version 3.63.0) introduced a change to the thread propagation behavior of the HttpClientCache. With that change, we also adapted the logging in case the propagation didn't work as expected - this is often caused by not using the ThreadContextExecutor for wrapping asynchronous operations. This is the reason for logs like the one described by the issue author.

Planned Mitigation

In the meanwhile, we realized that these WARN logs are causing confusion on the consumer side. We are working on improving the situation by degrading the log level to INFO for the message and to DEBUG for the exception.

Upvotes: 1

Related Questions