Hi everyone,
I’m facing a strange issue related to automatic mashup refresh using the “Automatically update values when able” checkbox in combination with the ServiceInvokeCompleted event.
I have two mashups, and I’ve already implemented the known setup for real-time updates — using GetProperties with WebSocket subscription to property changes that the mashup is subscribed to. Everything works perfectly most of the time, and the mashup refreshes automatically when the source data changes.
However, once in a while (maybe once in a blue moon ), the mashup simply stops refreshing.
For example, today it worked fine for hours, and then suddenly it didn’t refresh anymore — even though no configuration changes were made.
Has anyone else experienced this kind of intermittent issue with automatic refresh or WebSocket subscription in ThingWorx mashups?
Any idea what could cause this — subscription loss, or something else?
Thanks in advance for any hints or similar experiences!
Solved! Go to Solution.
When this feature is enabled, the Mashup operates as a "full" AlwaysOn (JS) client, implementing mechanisms such as automatic re-connection, heartbeat, bindings — resulting in a complex runtime with multiple interacting components. You might want to open a support case for in depth investigation.
Some easy to test options:
LAST_IN_WINS
binding policy is used on the WSCommunicationSubsystemHi @MA8731174 ,
I got these issues once, a couple of years back. So, during the subscription, the data didn't get logged in to the DB; it was in the queue to get logged. Sometimes, due to heavy traffic (Incoming data), the queue becomes bigger, and we need to restart thingworx.
But once Thingworx is restarted, the fix should be fixed.
Later on, for the permanent solution, we decreased the frequency of incoming data & increased the RAM of the server where Thingworx was installed, which solved the issue
Thanks,
When this feature is enabled, the Mashup operates as a "full" AlwaysOn (JS) client, implementing mechanisms such as automatic re-connection, heartbeat, bindings — resulting in a complex runtime with multiple interacting components. You might want to open a support case for in depth investigation.
Some easy to test options:
LAST_IN_WINS
binding policy is used on the WSCommunicationSubsystemThank you @pshashipreetham and @smainente for your valuable feedbacks!
@smainente we are currently using Thingworx version 9.3.7 and as you can see below in screenshot the version 9.3.16 and 9.4.6 or later have this feature of MashupWebSocketConnectionAliveAfterTimeout in the platform-settings.json file. In our file i could not even find this flag and our version is also low. May be turning this option on can remove our this issue. and about your second point would you please explain it in detail? I mean how can i check that binding policy ?
1. The MashupWebSocketConnectionAliveAfterTimeout option is not available in 9.3.7.
2. Choosing the LAST_IN_WINS bind protection policy on the WSCommunicationSubsystem will facilitate re-connection of any AlwaysOn device