Ours is a dwc based application Master Data Proxy Service (MDPS).
We are getting an error due to the required Dwc headers (dwc-tenant, dwc-subdomain, dwc-jwt) etc,
not being propagated to individual request contexts from a batch request.
I did some debugging on this and here are my observations:
We create a destination with DwcHeaderProvider as header provider with the following code:
DefaultHttpDestination.builder(megacliteUri + MEGACLITE_VERSION + serviceBinding)
.keyStore(dwcUtil.getKeyStore())
.keyStorePassword("changeit")
.proxyType(ProxyType.INTERNET)
.headerProviders(new DwcHeaderProvider()
// The destination that Megaclite should use to perform the request
.header(Constants.DESTINATION_NAME, Constants.DEFAULT_DESTINATION_VALUE)
.build();
DwcHeaderProvider in turns gets all the relevant headers including the dwc headers. But with the new version its not happening.
I can see that internally the headers are fetched from a headerFacade, which in the previous versions used to be DefaultRequestHeaderFacade.
Now the facade is getting initialized as com.sap.cds.integration.cloudsdk.facade.CdsRequestHeaderFacade and this comes from a jar
com/sap/cds/cds-integration-cloud-sdk/1.23.0/cds-integration-cloud-sdk-1.23.0.jar
cds-integration-cloud-sdk-1.23.0.jar
Can you look into it this? It is a high prio issue for us, since batch requests are completely not working, and our UI relies on such requests.
Thanks,
Sachin
Update: Please use CAP 1.24 - the issue is fixed already.
Until the problem is solved and a proper fix is released, can you try a workaround?
Before instantiating the destination run the following code snippet:
import com.sap.cloud.sdk.cloudplatform.requestheader.RequestHeaderAccessor;
import com.sap.cloud.sdk.cloudplatform.requestheader.DefaultRequestHeaderFacade;
RequestHeaderAccessor.setHeaderFacade(new DefaultRequestHeaderFacade());
Related
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!
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.
I am reading events from an Azure EventHub cluster synchronously via the receiveFromPartition method on the EventHubConsumerClient class.
I create the client once like so:
EventHubConsumerClient eventHubConsumerClient = new EventHubClientBuilder()
.connectionString(eventHubConnectionString)
.consumerGroup(consumerGroup)
.buildConsumerClient());
I then just use a ScheduledExecutorService to retrieve events every 1.5s via:
IterableStream<PartitionEvent> receivedEvents = eventHubConsumerClient.receiveFromPartition(
partitionId, 1, eventPosition);
The equivalent logic in V3 of the SDK worked fine (using PartitionReceivers), but now I am seeing OOMs in my JVM.
Running a profiler against a local version of the logic I see the majority of the heap (90%, mainly in OG) is being taken up by byte[]s, referenced by org.apache.qpid.proton.codex.CompositeReadableBuffer. This pattern is not present when I profile the V3 logic.
What could be causing a leak of the AMQP messages here, do I need to interact with the SDK further, for example close a connection that I'm not aware of after each call?
Any advise would be very appreciated, thanks!
Turns out it was a bug, solved here: https://github.com/Azure/azure-sdk-for-java/issues/13775
I'm new to using Azure DevOps. I continue to receive this error "Add-PnPApp : The request message was already sent. Cannot send the same request message multiple times."
Azure DevOps Release fails because of AddPnP error with "...same request".
Build shows version that changes my version (old) to a new version(gulp's version?).
Image of build
I'm told that it could be the version that starts with zero because SharePoint doesn't like it. I can't seem to change the new version to 1.0.0.1 because it seems like it's being changed in the gulp-file.js. Is there something else that I am missing?
image of release
Is it possible that you need the overwrite parameter in the AddPnP command? Or is it possible you would need to iterate the version between each release?
https://learn.microsoft.com/en-us/powershell/module/sharepoint-pnp/add-pnpapp?view=sharepoint-ps
In my case the same message
The request message was already sent. Cannot send the same request message multiple times
was misleading. I tried to update dynamically an .sppkg package (which is in fact a ZIP file) during an automated deployment, but the file _rels/.rels was getting lost in the process (because of the bug Unable to compress hidden files with Compress-Archive) and the resulting package was corrupted.
Once I fixed the package by making sure the file _rels/.rels was kept, the deployment would succeed.
I trigger a Post Function Import (Action in CDS), this would typically take about 2 minutes for processing. The POST operation was successfully completed in JAVA, however I get a Gateway Timeout.
How to increase the timeout of incoming requests? I had tried to set the property INCOMING_CONNECTION_TIMEOUT: 0 in mta.yaml of service project as well as using the command
cf set-env x-service-name-blue INCOMING_CONNECTION_TIMEOUT 0
cf restage x-service-name-blue
It did not work either.
Could you assist?
Update: I think the correct environment variable on the approuter is called SESSION_TIMEOUT. Can you try this one instead?
This is for the XS Advanced approuter, though I'm not sure if it still applies to the one used for CF apps, this documentation suggest that it's a property of the approuter, so you can try setting it there.
I'm new to service bus, I'm curious about RetryPolicy and how it works, as per the documentation, retry had happened automatically for transient exceptions(MessagingExcepitons, ServerBusy), and the default retry count is 3, but we can set out custom retry policy using RetryExponential class.
I want to see the logs does the RetryPolicy did actually trying to connect or not when exception occurs.
How can I check this, how to replicate MessagingExcepitons, ServerBusy exceptions, so that I can see the logs. I'm using azure service bus java sdk.
Can any one help me to understand this. Thanks in advance
The Java SDK is open source and looking for retryPolicy in these files shows how the underlying implementation uses it
CoreMessageSender
CoreMessageReceiver
For example, here's the flow for CoreMessageSender when an error is thrown
When an error occurs and if its a ServiceBusException, a retry is scheduled - See line
After waiting, it ensures the link is still open and increments the retry count - See line
This continues and on successful completion it resets the count - See line
As for logging, the Java SDK uses SLF4J and you can see the required logs with a line like this in your code
import org.apache.log4j.Level;
import org.apache.log4j.Logger;
Logger.getLogger("com.microsoft.azure.servicebus").setLevel(Level.WARN);