Skip to main content
M
malwatt1-Visitor
1-Visitor
April 11, 2019
Solved

Are subscriptions to the same event processed in order? (Pooled vs queued)

  • April 11, 2019
  • 2 replies
  • 2419 views

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?

Best answer by malwatt

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 🙂

2 replies

P
posipova20-Turquoise
20-Turquoise
April 12, 2019

It will wait to complete/queue up.

M
malwatt1-VisitorAuthorAnswer
1-Visitor
April 15, 2019

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 🙂

Terms & ConditionsAccessibility statement