Community Tip - Learn all about the Community Ranking System, a fun gamification element of the PTC Community. X
We have a subscription to a data change event and a subscription to this event. Does the processing for the subscription of this event complete before the processing of the subscription for the subsequent event?
I think really the only clear way to ask this is through an example (I made up the names).
We have property `DOWNTIME`, we have a subscription to it's data change event called `REACT`.
----
`DOWNTIME` changes to 0 -> Starts `REACT` processing (PROC1) but does not finish.
`DOWNTIME` changes to 1 -> Do we start REACT processing (PROC2) right away or do we wait for PROC1 to finish?
Solved! Go to Solution.
It's pooled execution unless you restrict the number of threads to 1 in the Monitoring > Status > Subsystems > Event Processing page. I tried to test myself before I was shown this, and I attached the thing I used to test.
Basically I have a `val` and `output`, in a change subscription to `val` I wait `val` seconds then set `output` to `val`. I changed val to 15, then quickly to 5. Queued (from my understanding) would have set this to 15 first, then to 5 after, but what actually happened is it set to 5 after 5 seconds and 10 seconds later to 15. There is potentially a flaw in this in that I used setTimeout in the first place, which depending on the engine might be "pausing" the JS process for the subscription and then letting the next subscription get executed first. https://stackoverflow.com/questions/779379/why-is-settimeoutfn-0-sometimes-useful
I don't think that part really matters though. Unless otherwise stated somewhere explicitly I don't think there is any way of guaranteeing the order of execution of subscriptions on the same property. If you manage to test this and find something different let me know :)
It will wait to complete/queue up.
It's pooled execution unless you restrict the number of threads to 1 in the Monitoring > Status > Subsystems > Event Processing page. I tried to test myself before I was shown this, and I attached the thing I used to test.
Basically I have a `val` and `output`, in a change subscription to `val` I wait `val` seconds then set `output` to `val`. I changed val to 15, then quickly to 5. Queued (from my understanding) would have set this to 15 first, then to 5 after, but what actually happened is it set to 5 after 5 seconds and 10 seconds later to 15. There is potentially a flaw in this in that I used setTimeout in the first place, which depending on the engine might be "pausing" the JS process for the subscription and then letting the next subscription get executed first. https://stackoverflow.com/questions/779379/why-is-settimeoutfn-0-sometimes-useful
I don't think that part really matters though. Unless otherwise stated somewhere explicitly I don't think there is any way of guaranteeing the order of execution of subscriptions on the same property. If you manage to test this and find something different let me know :)