Is it possible to keep session variables when a websocket is unexpectedly closed

I have a customer who is super security conscious. One of their many firewalls is unexpectedly closing the websockets for their Perspective sessions.

Is it possible to keep session variables when this happens? The entire session is getting reset when this happens.

This shouldn't be happening, as the session is established with ephemeral cookies in the client browser. Breaking the websocket should recover without losing the session.

Something more than just websocket breakage is happening. (Load balancer sending to a different front-end, perhaps?)

1 Like

This is what appears in the logs when it happens (randomly every 10-15 minutes)

The Ignition Gateway is hosted in AWS and I am VPN into their plant floor so many places for something to go wrong. If it is just my client then it won't be a problem but I assumed it was all clients (rolling out to production soon).

Hmm. Looks like something the firewall deliberately injected, instead of just cutting off.

After further investigation I opened a client in Chrome instead of Firefox and this problem didn't occur anymore. I then re-installed Firefox after not being able to identify what setting was causing the problem and the initial problem went away.

So this was a client-side problem caused by unknown settings in Firefox.

1 Like

Fwiw, I've seen other strange things with Firefox like rendering abnormalities, where both edge and Chrome are fine :person_shrugging: I never use Firefox because of this

1 Like

A new issue appeared and I figured I'd just keep this forum thread alive instead of opening a new one since it is the same end-result for me (Ignition 8.1.47 Perspective).

Periodically the following request URL is sent and everything works fine. The session doesn't get reset.

http://digitalfactory.customername.com:8088/data/perspective/keepalive/CNCMachines/31ec32e1/4390683237901289

But once in a while the following request URL gets sent.

http://digitalfactory.customername.com:8088/data/perspective/hello/CNCMachines/31ec32e1

And the second request URL appears to be causing a refresh of the project.

Does anyone know what the /data/perspective/hello is about?

This is what the initiator looks like.

The hello route is part of session initialization - I suspect it's a symptom, as in once that's happening whatever is breaking has already broken.

2 Likes

I went and swapped my session variables to memory tags to overcome this particular issue for this particular customer instead of spending several days trying to debug what is happening.

err, these work in completely different ways though: session props are session-scoped (a set for each session), tags are gateway-scoped (one set for everything). You were either incorrectly using sessions props to begin with, or you've messed it up now for individual sessions (unless you're using datasets with rows per session, sets of memory tags per session dynamically created, or something similar)

now i've become a bit nerdsniped wondering how you'd best simulate session props with memory tags....probably a user-model UDT with per user ID instancing?

You wouldn't, you would just use session props :stuck_out_tongue:
But yes, that's probably what I would do. Per-user or per-session, I guess it depends what your aim is. Probably use the Perspective session startup event to initialise it all.

This might be one way to maintain user preferences across sessions?

1 Like

well, unless you wanted to historize them

Yes, this is true but it doesn't explain what is resetting my sessions. Anyways, there were too many variables and no time to go through them all.

1 Like