Community Tip - Did you get an answer that solved your problem? Please mark it as an Accepted Solution so others with the same problem can find the answer easily. X
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
Solved! Go to Solution.
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.
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.
Thanks for your feedback, @posipova .
In case this is usefuly, our running Thingworx version is 8.4.4-b2319
Hi @bbeuckSIG , any update on issue #2? I am also investigating something similar.
Hello @eferent and @bbeuckSIG,
For #2 check the logs for java.lang.OutOfMemoryError -- I heard that under some circumstances Tomcat may try to serialize user sessions to disk or simply drop them if it starts running out of memory. I've never seen it with my own eyes though.
/ Constantine
Hello @eferent and @Constantine ,
we are still chasing this issue, among others we have opened a support ticket. So far we have learned more but are still facing the problem.
The logs do not show an OutOfMemoryError but attached you can find the messages we get from Tomcat and StdErr.
Our latest assumption is that the issue is caused by our network infrastructure and not by Thingworx.
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.