Apr 19 2018 02:53 AM - edited Apr 19 2018 05:48 AM
We're currently developing a solution that involves several types of Taxonomy operations:
In our logic many of the operations need to be combined to achieve our desired results. We're using .NET Managed CSOM. We're experiencing very inconsistent behavior in using the Taxonomy API's. Running the same code with the same input several times can have different results:
The Taxonomy API doesn't seem to be very robust. We've currently implemented retry mechanisms with delays in our code so that ultimately everything ends up in the desired state, but this feels very dirty. Since most of the time the results are what we expect, I can't imagine the problems are caused by our usage. I would expect consistently bad results if the problem was in our API usage, not this random behavior.
Does anyone have similar experiences? What are your approaches in usage and error handling?
Apr 19 2018 07:58 AM
Hi Paul this sounds like a SharePoint timer or indexing issue. Some things to try out and test:
If either of the above resolves the issue there are 2 ways off the top of my head for handling this:
Hope these ideas help and there may be more. If you need assistance, my company specializes in these things and may be able to help. Click here for assistance in a new browser tab.
Apr 19 2018 11:07 PM - edited Apr 19 2018 11:07 PM
Hi Joel,
Thanks for your response! Sorry I forgot to mention the environment I'm working in is SharePoint Online so no option to increase hardware.
The logic is running in an Azure Function App by queueu-triggered Functions. I have also written some Unit Tests where I see the same happening (e.g. Unit Tests succeed most of the times, but frequently fail due to one of the errors liststed above). Very unpredictable...
Apr 20 2018 05:50 AM
Ahh yeah there is a max memory usage on functions, but I doubt you are hitting it with taxonomy changes. Similarly though if you are using large amounts, try scaling down the load and see what happens. A bit painful for performance testing unless you have some "real" performance testing tools at your disposal that play nicely with Azure. Good luck or hopefully someone can give a better answer than me!
Max: 1,536MB
Source: https://azure.microsoft.com/en-us/pricing/details/functions/
Jun 04 2018 10:47 PM
Hi Paul -
I'm curious if you've made progress on this this. I am also seeing the error:
The HTTP service located at http://usr19769-643:32843/3115c78f4d804003b5964d1cb5b56042/MetadataWebService.svc is unavailable
In my case, I was using PnP PowerShell (Apply-PnPProvisioningTemplate) to deploy new Managed Metadata fields and anchor them to an existing term set. I was running this after creating a new site. I added a Sleep for 120 seconds after site creation and before applying the template. I still saw this error. Then I set it to sleep for 180 seconds and I did not see the error. I need to do more testing to see if 180 seconds is sufficient in all cases or if I'll need to implement retries as you have done.
Regards,
Tom Castiglia
Jun 04 2018 11:21 PM
Hi Tom,
No real progress regarding this on my side. My code is full of retry-mechanisms (basically try-catch-retry) to work around the errors I've listed and the end-results are fine now…
Hope your workaround suffices too!
Regards,
Paul
Oct 17 2018 01:01 PM
Hi Tom,
Having the sleep for 180 seconds fixed it for me too. Have you found any other way to get this working other than putting in some delay?
Thank you.
Oct 25 2018 06:35 AM - edited Oct 31 2018 04:37 AM
I implemented the follow extension to get around the problem.
public static async Task ExecuteQueryRetry(this ClientContext clientContext, int delaySeconds = 2)
{
while (delaySeconds < 30)
{
try
{
clientContext.ExecuteQuery();
return;
}
catch (ServerException ex)
{
var retry = ex.Message != null ?
ex.Message.Contains("MetadataWebService.svc")
|| ex.Message.Contains("GetDefaultSiteCollectionTermStore") : false;
if (!retry)
{
throw;
}
var delay = TimeSpan.FromSeconds(delaySeconds);
await Task.Delay(delay);
delaySeconds = delaySeconds * 2;
}
}
throw new TimeoutException("Stopped retrying ExecuteQuery after 30 seconds.");
}