cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

ThingWorx Navigate is now Windchill Navigate Learn More

Translate the entire conversation x

Intermittent issue with mashup not refreshing automatically (WebSocket / GetProperties auto-update)

MA8731174
16-Pearl

Intermittent issue with mashup not refreshing automatically (WebSocket / GetProperties auto-update)

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!

ACCEPTED SOLUTION

Accepted Solutions

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:

  1. In recent version, WebSocket connections are automatically disconnected after a 5–minute timeout when a mashup is running in a background tab or window (configurable).
  2. Ensure that the LAST_IN_WINS binding policy is used on the WSCommunicationSubsystem

View solution in original post

4 REPLIES 4

Hi  @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,

Shashi Preetham,
+91 8099838001 | shashi@psptechhub.com,
PSPTechHub  ||  World of PTC Thingworx  ||  LinkedIn

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:

  1. In recent version, WebSocket connections are automatically disconnected after a 5–minute timeout when a mashup is running in a background tab or window (configurable).
  2. Ensure that the LAST_IN_WINS binding policy is used on the WSCommunicationSubsystem

Thank 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 ? 

 

 

MA8731174_0-1760606423823.png

 

@MA8731174

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

smainente_0-1760611532968.png

 

 

 

Announcements


Top Tags