Can we have multiple subscriptions on the same property or same "AnyDataChange" event.

[psaxena]

I want multiple subscriptions on same event or same property, is that possible?

[CarlesColl]

Not from the same thing, this is a huge limitation on the platform that R&D introduced silently on 6.5, still I don't find the reason ( we had long chats with R&D about this).

We had to build our own DataChange event system in order to overpass that huge limitation

[psaxena]

Even if we build our own event then also it wouldn't allow us to create multiple subscriptions on that same event?

[jgorsline]

Priyanshi,

Any update on this? Were any of the discusstion posts helpful? If so, could you click on the "correct answer" button and let us know?

[magrawal]

from the same thing you can add multiple subscriptions for:
-same event with different properties or,
-same property but events should be different

but if you want to add multiple subscriptions for same events with same property in same thing, I don't think there is need to write multiple subscriptions in this case. you can write your code in single subscription with different conditions according to your need.

Thanks,
Meenakshi

[ankigupta]

Hi Priyanshi Saxena​,

Multiple subscription to the same Thing property is not possible currently.

As a workaround you can write different services for different subscription and then call all the services in the single subscription code.

Hope it helps.

Thanks,

Ankit Gupta

[CarlesColl]

Hi Ankit/Meenakshi,

If you write different services for different subscription and then call all the services in the single subscription code, that's not really flexible when you have multiple ThingShapes interacting, and makes the solution not really flexible.

That's the  real reason on having multiple subscriptions to the same event from the same thing, making a really decoupled system, what you are proposing it's a coupled system which using in development it's a big problem for complex and flexible systems.

Best Regards,

Carles.

[ankigupta]

Hi Carles,

Thank you for your valuable input.

Could you please elaborate more on this. I would like to understand the pros of having multiple subscription to same Thing in a complex system.

As per my understanding having multiple subscription to same Thing had some cons. For example we didn't had control over which subscription will run first. So, if two or more subscription code is updating the same property we cannot confirm the final result. Somewhat like race condition in Threads.

Thanks,

Ankit Gupta

[CarlesColl]

Hi Ankit,

We can start a long discussion on this... We had a long discussion a while back when R&D decided to pull off this feature.

Your first point "we didn't had control over which subscription will run first" --> Neither you have control when Event will be Fired/Executed as it may be executed on different threads, your code should support parallelism, we are on a concurrent system, then this problem you are saying it's always there.

About having two or more subscription code updating the same property --> Same as before, this may happen always, not becouse of the subscriptions on the same event from the same thing, you can have timers, other subscriptions which writes to the same property, and so and so.

About the pros:

• I can write Services which subscribes to properties dynamically on demand, this subscriptions will be done on runtime and depending on Thing Instance, and I can have subscriptions generated from different ThingShapes becouse the event maters to some of them.
• Highly decoupled Thing Shapes system, they don't depend on a subscription pre-written with plenty of "if" conditions to check if it are needed to be triggered or not. We will generate lot's of dependencies on code becouse of this, and dependencies which aren't easily tracked.
• Two Thing Templates on a hierarchy chain can subscribe to the same event, and this subscription can be done dynamically which will be more efficient, If I don't need it I don't suscribe ( neither I have an "If" condition ... )

Best Regards,

Carles.

[StefanBode]

Hi Charles, absolutely agree!!

The race condition is hopefully not the reason for switching this off. Every MQTT Server does allow multiple subscriptions on keys and fire them in a non predictive way to the subscribers. No issue. there. You just have to be aware.

Secondly there are several other conditions like timer events that can also cause race conditions on property changes. You comments regarding the discussion with R&D makes me really scary.

[CarlesColl]

Hi Stefan,

Nice to meet you, yes you can be scared about this, the talk with R&D was tough (back in July 2015), still now I can't believe their answer, and as time passes we will see more and more complaining customers on this ( as IoT solutions get more complex as are our one ).

Best Regards,

Carles.

[rupadhyay]

Hi Carles Coll​ Good Morning ! 

Seeing your experience with this particular issue ,Though I am new to Thingworx funcationality ,  I have a point to make  :

In this current IoT age leading to increased complexity  , we might  have to implement multiple subscription (I mean other places where this can be achieved ) sooner than we expect and when we have such huge use of concurrency , thread safe mechanism and data structure , this should not be an issue at all.  And we can not say to customers that our applications is not fully thread safe , as it should be.

The Pros and cons of have multi threaded environment is always there , however we do prefer use of thread safe mechanism where the need is.

I agree that there are certain disadvantages like

• general: increased complexity
• synchronization of shared resources (Things , Properties )
• difficult to debug, result is sometimes unpredictable
• potential deadlocks
• "starvation": some threads may not be served with a bad design
• constructing and synchronizing threads is CPU/memory intensive

However at same time , we also have advantages of using multi threaded environment like

• better use of system resources
• parallelize tasks
• enhanced performance on multi-processor machines
• better availability

I may be going little out of context , however I believe there is several reasons for us to provide  thread safe data structures in spite , it will add to complexity and development needs to think and work in direction sooner the better .

Please let me know if I am in wrong direction on this topic .

[CarlesColl]

But this limitation doesn't maters on a Thread Safe data structure, this limitation in fact increases complexity --> On our case we had to build our own multi-subscription system in order to reach customer requirements --> It increased a lot our solution complexity.

[rupadhyay]

okay , I understand now . So would be solution for this ? Custom solution by customer or by PTC to get this resolved ?

As you correctly  pointed out that there would be increasing demands of such functionality , do we have any road map to address this issue in near future ? Or we would suggest to avoid such designs ?

[CarlesColl]

R&D removed this feature silently on 6.5, previous to 6.5 you where able to have multiple subscriptions to the same thing/event from the same thing. We discovered becouse everything failed on 6.5, and we had to build our own solution.

Roadmap, as you see, they removed it, we will have to push them to get it back on the product, how? I don't know.

It's impossible to avoid such designs, the problem here it's the limitation not that complex uncoupled designs, coupled designs are a big deal/problem.

Best Regards,

Carles.

[raghunayak]

Hi @CarlesColl,

"On our case we had to build our own multi-subscription system in order to reach customer requirements" 

Did you guys ended up building this as an outside component (using things like MQTT server) or did you build an extension within Thingworx using SDK ?

Thanks

[CarlesColl]

Hello,

Not as an outside component, we have a Generic Thing Shape plugged to all the things which subscribes to AnyDataChangeEvent, and it handles triggering a fake DataChange event for each property based on a Infotable that keeps track of DataChange subscriptions for properties, adding lost multi-subscription feature, and also some nice features like prioritized and optionally delayed DataChange event execution. 

Regards,

Carles.

[raghunayak]

thank you!

[smainente]

Starting from 8.4, it should be possible to create multiple (named) subscriptions for a single event.

[CarlesColl]

That sounds promising, what are named subscriptions? it will apply to all types of subscriptions Static/Dynamic?

[smainente]

Static subscriptions have a name in 8.4 (to be able to differentiate multiple subscriptions on the same event).

It is also possible to create multiple dynamic Subscriptions on the same event (dynamic one are not named).

All this is pending official 8.4 release.

[raghunayak]

hi what is the official release date for 8.4 ? and where can I find that info on support site ?

[smainente]

There is no foretasted date yet for ThingWorx 8.4 in the Product Calendar

[rupadhyay]

Thankyou Carles Coll​ for sharing your understanding and opinion. I understood the issue .

Priyanshi Saxena​ You wont be able to achieve this in Thingworx , as if now .

[mbratz]

This is also an issue in the ThingWorx Utilities because the FileTransferEvent is already "catched" by a subscription implemented in TW.RSM.Template.AssetWithTunnelsAndFileTransfer. Therefore no inheriting ThingTemplate can implement a subscription to the FileTransferEvent.

Unfortunately this issue is still not solved, see Thing Subscriptions:

"Duplicate subscriptions are not supported in ThingWorx version 6.5.1 and later. For example, if a thing template has a subscription to the AnyDataChange event, you cannot add a AnyDataChange event to the thing that uses the thing template."

[mbratz]

For the mentioned FileTransferEvent issue there seem to be an improvement in TWX Utilities 7.3.0, see Capturing File Transfer History.