InitRequestCtx : Session is unknown or expired

[lchorley]

Hello team DocuVieware,

We have recently updated to the DocuVieware nuget package with version 3.2.27 (versions after this have another problem, I'll do a separate post for that)

On larger files we often have the prompt "InitRequestCtx : Session is unknown or expired" (see the attached image)

In order to load the document we have also recently swapped to LoadFromStream instead of LoadFromUri, but I don't see any other major change.

Have you got any ideas ?

Thanking you in advance for you help,
Loren

[Fabio]

Hello Loren,

I did not face this issue on our latest release.

Does the issue is reproducible every time or is it an inconstant one?
Could you please share an input file with a code snippet of the LoadFrom method? (if you have a custom way to set the DocuVieware's instance name or the SessionID that could also be helpful to share it)

From my understanding, the issue could be due to 2 things:
- 1: the DocuVieware session is really expired. There is nothing you can do except increase the DocuVieware session timeout (default set to 20 min).
- 2: the DocuVieware session is not expired: Your IIS pool restarted (default behavior) and DocuVieware session mode is set to Inproc. Solution: switch session mode to FileMode or enable IIS to be always on (not suggested).

Best regards,
Fabio

[lchorley]

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

[lchorley]

I've just seen that in our API Management not all the endpoints for the DocuVieware controller are mapped.
The endpoints that are allowed are baserequest, getresource, ping, and print. All with the verb GET apart from baserequest with POST.

Could it be that another one of endpoints being blocked is silently causing this problem ?

Thank you
Loren

[lchorley]

Hello Fabio

With our DevOps teams, we checked everything over and couldn't find anything wrong at the level of AKS. There doesn't seem to be any blockage there.
Though we still don't know why only when we deploy to several nodes at once, the problem occurs.
I've tested every node individually now one at a time, and there's never any problem.
So I'm forced to come back to you, I don't see anything else to check on my side.

I do have a small bit of extra information.
In the browser when I have the error message, the call to baserequest take around 11s. while the call normally takes around 1-2s depending.
The problem is after it comes back with a code 200 and no message apart from Session is unknown or expired.
The timeout in AKS on our side is set to 30s and there's nothing in log, so I can't imagine it's a timeout that we handle.

So I'm wondering if you know of a call that has a ~10s timeout from the baserequest endpoint and what it calls so that I can investigate it more thoroughly

Thanking you again for you time.
Loren

[lchorley]

Hello again Fabio,

I'm sorry for the huge post.
I was just wondering if you had a response to the very last post.
No need to read the rest in the end.

Thanking you in advance,
Loren