SimIntToolkit / cpswt-core

Foundational codebase with support for java federates
MIT License
1 stars 3 forks source link

Sometimes a federate will not receive updates to its subscribed objects #60

Open sperka opened 7 years ago

sperka commented 7 years ago
Excerpt from the input source log:
16:29:19.002 [SimpleAdderObjects.InputSource.main()] INFO  SimpleAdderObjects.InputSource - t=64.0
16:29:19.003 [SimpleAdderObjects.InputSource.main()] INFO  SimpleAdderObjects.InputSource -              operand=6
16:29:19.003 [SimpleAdderObjects.InputSource.main()] INFO  SimpleAdderObjects.InputSource -              operand=6
16:29:19.003 [SimpleAdderObjects.InputSource.main()] INFO  SimpleAdderObjects.InputSource -              operand=5
16:29:20.009 [SimpleAdderObjects.InputSource.main()] INFO  SimpleAdderObjects.InputSource - t=65.0
16:29:20.009 [SimpleAdderObjects.InputSource.main()] INFO  SimpleAdderObjects.InputSource -              operand=6
16:29:20.009 [SimpleAdderObjects.InputSource.main()] INFO  SimpleAdderObjects.InputSource -              operand=2
16:29:20.009 [SimpleAdderObjects.InputSource.main()] INFO  SimpleAdderObjects.InputSource -              operand=4
16:29:21.011 [SimpleAdderObjects.InputSource.main()] INFO  SimpleAdderObjects.InputSource - t=66.0
16:29:21.011 [SimpleAdderObjects.InputSource.main()] INFO  SimpleAdderObjects.InputSource -              operand=6
16:29:21.011 [SimpleAdderObjects.InputSource.main()] INFO  SimpleAdderObjects.InputSource -              operand=2
16:29:21.011 [SimpleAdderObjects.InputSource.main()] INFO  SimpleAdderObjects.InputSource -              operand=4

Excerpt from the adder log:
16:29:20.009 [SimpleAdderObjects.Adder.main()] INFO  SimpleAdderObjects.Adder - t=65.0
16:29:20.009 [SimpleAdderObjects.Adder.main()] INFO  SimpleAdderObjects.Adder -                received operand with value=6
16:29:20.009 [SimpleAdderObjects.Adder.main()] INFO  SimpleAdderObjects.Adder - Object received and handled: Main Loop
16:29:20.009 [SimpleAdderObjects.Adder.main()] INFO  SimpleAdderObjects.Adder -                received operand with value=6
16:29:20.009 [SimpleAdderObjects.Adder.main()] INFO  SimpleAdderObjects.Adder - Object received and handled: Main Loop
16:29:20.010 [SimpleAdderObjects.Adder.main()] INFO  SimpleAdderObjects.Adder -                received operand with value=5
16:29:20.010 [SimpleAdderObjects.Adder.main()] INFO  SimpleAdderObjects.Adder - Object received and handled: Main Loop
16:29:20.010 [SimpleAdderObjects.Adder.main()] INFO  SimpleAdderObjects.Adder -                calculated sum=17
16:29:21.010 [SimpleAdderObjects.Adder.main()] INFO  SimpleAdderObjects.Adder - t=66.0
16:29:21.010 [SimpleAdderObjects.Adder.main()] INFO  SimpleAdderObjects.Adder -                received operand with value=2
16:29:21.010 [SimpleAdderObjects.Adder.main()] INFO  SimpleAdderObjects.Adder - Object received and handled: Main Loop
16:29:21.011 [SimpleAdderObjects.Adder.main()] INFO  SimpleAdderObjects.Adder -                received operand with value=4
16:29:21.011 [SimpleAdderObjects.Adder.main()] INFO  SimpleAdderObjects.Adder - Object received and handled: Main Loop
16:29:21.011 [SimpleAdderObjects.Adder.main()] INFO  SimpleAdderObjects.Adder -                calculated sum=6
16:29:22.006 [SimpleAdderObjects.Adder.main()] INFO  SimpleAdderObjects.Adder - t=67.0
16:29:22.006 [SimpleAdderObjects.Adder.main()] INFO  SimpleAdderObjects.Adder -                calculated sum=0
sperka commented 7 years ago

@tpr1 isn't it because using UDP ?

tpr1 commented 7 years ago

portico implements a reliable protocol on top of UDP that should guarantee delivery of the attribute updates. both of these federates were also set with isLateJoiner false, which should make them both time constrained and time regulating, which makes a stronger guarantee that the updates should be delivered the next logical time step.

hneema08 commented 7 years ago

Tom, The object 'attributes' have two parameters (like interactions), viz. 1: order {timestamp, receive} 2: Delivery {reliable, best_effort} Can you make sure that the model this showed up in has the 'Delivery' set to 'reliable' for all attributes? Does the problem still exist after doing this? If it does, then it's a bug then we would need to look into.

tpr1 commented 7 years ago

the attribute output in the logs is set to reliable and timestamp.

this issue has persisted since the dawn of time; well before the recent commits.