Skip to main content
16-Pearl
January 8, 2020
Solved

Session timeout topics

  • January 8, 2020
  • 2 replies
  • 5321 views

Dear Thingworx community,
I am facing behavior I cannot explain and I am looking for some expertise. I have two scenarios/questions, loosely related.


1. I have a very simple mashup, just showing a counter from a thing. The GetProperties Service is called once when the mashup is loaded. I set the "Automatically update values when able" checkmark to true. I let it run until my session gets closed automatically by the system because I hit idle session timeout. I would expect the counter to stop but it doesn't, the websocket seems to remain open and I continuously retrieve the counter information. I am very certain that my session is closed because a) I get the login window on other tabs and b) I also get the login window when refreshing my mashup (F5). Why is that?


2. I noticed the Autorefresh widget keeps the session alive. So in one plant we have one particular mashup (not my counter test from 1.) permanently open. It contains one Autorefresh widget and as expected the session remains open beyond the idle session timeout. So far so good. Unfortunately after a few days (~5-8 days, apparently randomly) the session is closed out of nowhere, the shopfloor operators don't get information anymore. I am pretty sure it was not closed manually (no admin was there over christmas). Any ideas how this can happen?

 

Thank you
Benny

Best answer by CarlesColl

About the 1) WebSocket Property Updates aren't bound to User Session, they bound to another session, you can see it on RemoteThings, they are named "PersistentSessionNNNN...", thouse Thing/Sessions are created auto-magically when you open the Mashup which has de service GetProperties with the Automatically Update Check  marked.

2 replies

20-Turquoise
January 8, 2020

1). Is the counter activity condition bound to the session timeout?

 

2).  If this is not an accidental user mistake, would it be possible to export that mashup for us to inspect? It shouldn't expire if the autorefresh inteval is less than the session timeout.

BennyB16-PearlAuthor
16-Pearl
January 9, 2020

Thanks for your feedback, @posipova .

 

  1. No? How would I do this? It's almost the simplest Thing you can think of, using Timer Template, one Counter property and one Subscription to increment.
    So I understand you also do not expect this behavior?
  2. Users have no access to the screen. And even if they had, the mashup has no logout button. I don't want to waste your time checking my Mashup (including contained Mashups and several data providing Things). I will try to add logging to better understand the situation there. My best guess is temporary network interruption since the connection is going over VPN. But this still should be no problem, the session timeout is set to 1440 mins = 1 day, already pretty high from my point of view.
BennyB16-PearlAuthor
16-Pearl
January 9, 2020

In case this is usefuly, our running Thingworx version is 8.4.4-b2319

1-Visitor
June 11, 2020

About the 1) WebSocket Property Updates aren't bound to User Session, they bound to another session, you can see it on RemoteThings, they are named "PersistentSessionNNNN...", thouse Thing/Sessions are created auto-magically when you open the Mashup which has de service GetProperties with the Automatically Update Check  marked.