Hello Fabio
Unfortunately it doesn't seem to be consistent.
I also haven't had any luck reproducing it running from Visual Studio or packaged in a docker container running locally.
The only place I've found the problem so far is running from within a docker container in Azure. (Deployed into AKS with an API Management in place, among other things)
I've done tests in several browsers and I can't find a pattern.
Sometimes there are long streaks where it works then the error comes back for 1 or several refreshes.
But sometimes it's just totally random as well.
It can even occur directly after clearing the browser cache, but not necessarily.
In terms of session id, it's different for every page refresh, we just generate a new guid : Guid.NewGuid().ToString()
I'm assuming the instance name is the same thing as the parameter ClientId in the constructor for DocuViewareControl ? In that case it's consistently the same thing, and it hasn't changed : DocuVieware1
We've left the timeout at the default of 20 minutes so I can't imagine that it's the problem since I can reproduce the problem directly after deploying
After that the settings we give are StickySession = false, DocuviewareSessionStateMode = DocuViewareSessionStateMode.File, the cache direction is Path.Combine(Directory.GetCurrentDirectory(), "cache"), the application url is "/" and the controller route is "is-pfd/api/viewer" which matches the route given the DocuVieware controller.
I've looked at the latest samples in the SDK for the 3.2.30, but I couldn't see any critical updates to the controller or other calls that I should update myself, do you have anything in mind that should look at in particular ?
We have since the beginning the attribute AllowAnonymous on the controller to avoid our authentication middleware and ApiController which I see is not or no longer in the examples.
For the LoadFrom call, I've tried the two following methods :
First method (Tested with 3.2.27)
var status = docuVieware.LoadFromUri(uri);
Second method (Tested with 3.2.27 and 3.2.30)
Getting a stream before hand via an HttpClient (ex reduced a bit)
HttpClient httpClient = _clientFactory.CreateClient();
HttpResponseMessage result = await httpClient.GetAsync(uri);
Stream stream = await result.Content.ReadAsStreamAsync();
var status = docuVieware.LoadFromStream(documentStream, true, documentName);
I made a very reduced version that doesn't depend on an external file that still reproduces the problem intermittently as usual (still only when deployed to our Azure environment) :
Stream GenerateStreamFromString(string s)
{
var stream = new MemoryStream();
var writer = new StreamWriter(stream);
writer.Write(s);
writer.Flush();
stream.Position = 0;
return stream;
}
var status = docuVieware.LoadFromStream(GenerateStreamFromString("plain text content"), true, "plaintext.txt");
Since it seems to be linked to the environment in Azure, I thought maybe there could be a blockage for one of the endpoints of the DocuVieware controller, but there are no errors in the browser console indicating a failed request. (I've had 404s before on "getresource" for example which was because of API Management that blocked the endpoint)
I'm not sure how else I can investigate that side of things though.
I'll have to investigate with our DevOps team I think.
If you've got any ideas about what could be malfunctioning I'd love to hear them.
Thank you very much for your help and I'm sorry for the quantity of info, I realised after writing that it's quite long
Loren