Conversation
edwardalee
left a comment
There was a problem hiding this comment.
Looks great! The tests are quite nice. I wonder whether they will prove flaky, since there is always a risk of the launched federates taking an indeterminate amount of time to launch. Have you seen any flaky failures?
cmnrd
left a comment
There was a problem hiding this comment.
I have significant concerns about this approach, and I don't think that we should merge this lightheartedly without being clear about the benefits and the costs. See my comment in the discussion thread for an explanation.
I agree that there are chances of having the tests prove flaky... But I have not encountered such a case so far on my machine. As a proactive workaround, I increased the timeout in this commit 3503ee1. |
Thanks for the feedback, Christian! |
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
…ut the coordination and the target
…nerator.java Co-authored-by: Edward A. Lee <eal@eecs.berkeley.edu>
Co-authored-by: Edward A. Lee <eal@eecs.berkeley.edu>
…sts and reduce redundancy
… of launching time in transient federates. This is simply done by increasing the timeout to 3s instead of 2s, and adjusting the check accordingly
|
I have not reviewed the code, but tried a simple example that failed: Try starting it in the order:
As expected when r1 is started, he connects to RTI and gets a start tag and executes the startup reaction. But when r2 is started, it does not start, it is blocked, presumably waiting for r3 (but that's a transient federate). When r3 is started it crashes at once with a segfault, when run in debug mode an assertion fails because it has decoded a nonsense port. Only after r3 starts (and crashes) does r2 finally start |
|
I don't think there is support yet for decentralized coordination. |
|
Then a compilation error should be issued, a couple of other observations:
|
This PR replaces #1695.
The companion PR in
reactor-cis lf-lang/reactor-c#358.It implements the transient feature in the federation execution. Details of the implementation are documented in Discussion #2212.