Multiple fixes for federated programs with TypeScript target #1752
Conversation
|
Known error: The |
…possibly coming from the TargetProperty).
I fixed this by preventing the federateConfig.keepAlive from being overwritten by the app parameter in 3b1ad06 There are still errors in |
|
The check boxes in the PR description are meant to track progress of the PR, so we should only lists the tests that are failing, and check off the ones that we fixed... |
|
I suggest merging this PR first by moving failed tests to the failing folder. Because fixing all failed tests pass requires lots of time and makes this PR too heavy. Currently, just 27/42 Python federated tests are passing. Also, I realized that we have to add PTAG handling to fix the remaining failing tests in Because we get some improvements (finding the fault of the script and fixing some TypeScript federated Tests) with this PR, I think it's fine to merge this PR first and create other PRs that solve Python tests and TypeScript tests. |
For some reason, creating a trap for SIGTERM results in SIGTERM not causing the program to exit. In any case, we really do not want the program to exit without killing the RTI and federates under any circumstance unless we are sure that the program terminated successfully. Therefore, it seems safest to require positive confirmation via an EXITED_SUCCESSFULLY flag that the program really did exit successfully.
This replaces all instances in the test/Python/src directory.
This is not the right solution. The right solution is not to do the files property merging in the first place. This has been discusssed. I think everyone agrees about this, but probably it will not be fixed until the package manager is more complete.
Fixes for Python federated tests
Only the oldest test output is deleted.
This makes the test too computationally intensive and more importantly results in too much debugging output.
StringBuffers differ from StringBuilders mainly in that they are synchronized. It is not entirely clear to me where the concurrent accesses would be coming from since there is only one thread writing to this StringBuffer (right?) but it is one more thing to check.
petervdonovan
changed the title
After fixing the launch script so that its exit code reflects that when the RTI cannot be found this amounts to an error, it became clear that quite a few of the federated tests were failing.
Of those failing tests, the following were successfully repaired:
ChainWithDelay.lfDistributedCount.lfDistributedCountPhysical.lfDistributedDoublePort.lfDistributedLoopedAction.lfDistributedLoopedPhysicalAction.lfDistributedStop.lfDistributedStopZero.lfHelloDistributed.lfStopAtShutdown.lfTopLevelArtifacts.lfThe following tests need more work and have temporarily been marked as
failing:DistributedCountPhysicalAfterDelay.lfLoopDistributedCentralized.lfLoopDistributedDouble.lfPingPongDistributed.lfPingPongDistributedPhysical.lfSimpleFederated.lfRelevant PR: lf-lang/reactor-ts#152