0

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!

kurts
  • 79
  • 6

1 Answers1

1

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.

Johannes Schneider
  • 156
  • 6
  • We didn't have these before because `@SpringBootApplication` includes component scanning by default on the root package. I explicitly included the component scans as you recommended and I am seeing the same behavior. – kurts Feb 22 '22 at 16:22
  • 1
    Are you running your OData request in an asynchronous manner? If so, please check [our documentation](https://sap.github.io/cloud-sdk/docs/java/features/multi-tenancy/multi-tenancy-thread-context#running-asynchronous-operations) about how to properly propagate the Cloud SDK's `ThreadContext` to sub-threads. That should help to get rid of the warning. – Johannes Schneider Feb 23 '22 at 11:03
  • So right now I'm just testing out the 3.63.0 version by running a local integration @SpringBootTest. It simply makes a call to the service endpoint to update a contact in SAP Marketing Cloud. For context, I am testing to make sure my [feature request](https://github.com/SAP/cloud-sdk/issues/505) is working as expected. – kurts Feb 23 '22 at 17:24
  • The Cloud SDK uses a [context object](https://sap.github.io/cloud-sdk/docs/java/features/multi-tenancy/multi-tenancy-thread-context#what-is-a-thread-context) to implement multi-tenancy. In case that is relevant for your use case I'd recommend to follow the documentation linked by Johannes. – MatKuhr Feb 23 '22 at 22:00
  • (1/2) Turns out someone opened [a similar issue](https://github.com/SAP/cloud-sdk/issues/698) a day before my post. As I mentioned above, I am not doing anything asynchronously nor do I require multitenancy. Per your recommendations I wrapped my calls in a `ThreadContextExecutor` and the warnings disappeared, however, this is not desired based on the synchronous manner of our background jobs. I would agree with the other poster (SpaceCondor) that the documentation wasn't clear, i.e. because I'm doing doing multitenancy I assumed I didn't need to create ThreadContexts. – kurts Feb 24 '22 at 16:24
  • (2/2) Shoot, SO won't let me edit my previous comment now. That was supposed to say "...because I am not doing multi-tenancy..." I also agree that it would be nice to disable these multi-tenant features and not need to wrap every call in a ThreadContext. So my question is this... do you see any issue if I continue to make synchronous calls without multi-tenancy and simply ignore the warnings about the missing ThreadContexts? – kurts Feb 24 '22 at 16:32
  • _"do you see any issue if I continue to make synchronous calls without multi-tenancy and simply ignore the warnings about the missing ThreadContexts?"_ In general: No, you should be fine ignoring this warning for now. We are also working on degrading the log level to `INFO` while the causing exception will even be logged on `DEBUG` level only - **presumably**, the change is not yet merged. Please also note that you will lose your HTTP client (and therefore any cookies, headers, etc.) in between calls when not propagating the `ThreadContext` - this **could** lead to issues in some cases. – Johannes Schneider Feb 25 '22 at 07:34
  • Ok, perfect! That should definitely work for our needs. Thank you so much for all of your feedback and for the enhancements and improvements you are continually making to this library! – kurts Feb 25 '22 at 16:59
  • @JohannesSchneider you mention your documentation which advises to use `ThreadContextExecutors`. Where exactly can this class (plural, not ``ThreadContextExecutor`) be found? – Datz Feb 06 '23 at 07:33
  • `ThreadContextExecutors` is in lib cloudplatform-core. I used an outdated version where it was missing! – Datz Feb 06 '23 at 08:04