Unresponsive after timeout

PowerShell Universal
21

Great find! I’ll give this a shot today.

22

Confirmed working ok in v1.5.18 (PSU running via IIS)

23

I’ve noticed this still seems to happen every now and then - the dashboard is still going in to an unresponsive state, with a Show-UDToast command resulting in the message “Cannot send data if the connection is not in the ‘Connected’ State.” popping up from the bottom of the window…

[Album] imgur.com

This is hosted via IIS. PSU 1.8.18
App Pool settings:
Start Mode: AlwaysRunning
Idle Time-out: (minutes) 0
Recycling: none checked

web.config:
<aspNetCore processPath="D:\***\Universal.Server.exe" arguments="" forwardWindowsAuthToken="true" stdoutLogEnabled="true" stdoutLogFile=".\logs\log" hostingModel="InProcess" />

appsettings.json:
"Authentication" : { "Windows": { "Enabled": "true"
"SessionTimeout": "25"
"DashboardStartupTimeout": 10

Just a question:
If I ran this as normal/as a service - instead of via IIS would it be more stable in this regard (becoming unresponsive) - and if so, would I still be able to use Windows auth for single sign on?

Cheers,
Steve.

24 
Product: PowerShell Universal
Version: 2.0.0
UniversalDashboard: 3.4.0

I was just about to open a post about this.
We am running PSU with Kestrel as a service and we still get the unresponsive behavior after a while.
Checking the browser, the only thing we can see is:

DevTools failed to load source map: Could not load content for https://redacted.net:5000/api/internal/javascript/index.195bf21b3c091cbc60ab.bundle.map: HTTP error: status code 500, net::ERR_HTTP_RESPONSE_CODE_FAILURE
DevTools failed to load source map: Could not load content for https://redacted.net:5000/index.9876ec7f936300d6a330.bundle.map: Load canceled due to load timeout

In appsettings.json the following is set:

    "OIDC": {
      "Enabled": "true",
      "CallbackPath": "/auth/signin-oidc",
      "ClientID": "RedactedGuid",
      "ClientSecret": "RedactedSecret",
      "Resource": "",
      "Authority": "https://redacted.net/adfs/",
      "ResponseType": "code",
      "SaveTokens": "false",
      "CorrelationCookieSameSite": "",
      "UseTokenLifetime": false
    },
    "SessionTimeout": "600"

We also tested with changing the dashboards.ps1 to “-SessionTimeout 600”, but still we don’t get teh 10 hours we would like.

Is there something we have missed?

25

We are looking into implementing some manual retries for this issue. The problem is that we rely on SignalR for web socket communication but it seems to disconnect after some time and no amount of configuration seems to resolve it. It’s flaky and different in every environment. It’s supposed to automatically reconnect but that doesn’t seem to happen all the time for some reason. I’ve heard reports of this disconnecting as soon as 8 minutes after opening the page.

Here’s some information on the underlying technology.

In 2.1, we’ll be introducing some additional logging and a manual reconnect to try to avoid this issue.

26

Can anyone verify what browser they are using? It looks like a change to Chrome earlier this year has caused issues with SignalR. It’s been resolved but PSU will need to update to the latest version to take advantage of the fix.

27

We are using Edge, which is guess would be the same issue.

28

Chrome here [Version 91.0.4472.114 (Official Build) (64-bit)]