[tester] Start synchronization mechanism

[kriegfrj]

Executive Summary

The tester needs a mechanism to disable automatic starting of the tester loop and have it run under programmatic control.

Detail

While playing with the various attempts to move to a more DS-oriented implementation of Bndtools (#5004), I think I have managed to robustly solve many of the startup issues that caused race conditions during testing.

However, there is one that is proving intractable. Fundamentally, the problem is as follows:

• The Eclipse Workbench must start on the main thread.
• Consequently, the Eclipse Workbench does not start until the launcher launches the main runnable.
• Because the Workbench must run on the main thread, the tester cannot. Hence, the tester runs in a mode where it spawns its own thread. This thread is spawned and started as soon as the tester bundle is activated.
• The main runnable is never launched until after the launcher has activated all of the bundles (including the tester).

The nett result of all this is that there is always a window where the tester bundle will start trying to run before the launcher has launched the Eclipse workbench. This window can be minimised (by giving the tester bundle the highest startlevel and making it start last), but it cannot be completely eliminated, and there is no mechanism in the tester to synchronize its start with any external process.

The problem is that the tester, as part of its ordinary operation, will attempt to load and execute the test cases. The process of loading the classes (and triggering lazy activation) often sets off a chain of dependencies that ultimately depends on the presence of a running workbench. Because of the small window above, this can sometimes lead to failures.

For the quickfix tests, we seem to have struck upon a combination that works most of the time, but it seems delicately balanced, and I think we still get the odd failure here and there. But it really made it clear just how delicately balanced it is when I started working on #5004 and re-introduced a whole new set of startup timing issues again that required delicate re-balancing.

Possibly, implementing #4587 would provide such a mechanism for my particular use case (add a global beforeAllBundles callback which blocks until the workbench is running). But that would still only happen after the tester bundle had done its discovery. I there might also be a case for allowing a manual/programmatic start mechanism for the tester so that even the discovery can be delayed until the time that is convenient for the system-under-test.

[bjhargrave]

Sounds reasonable.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution.

[github-actions]

This issue has been automatically closed due to inactivity. If you can reproduce this on a recent version of Bnd/Bndtools or if you have a good use case for this feature, please feel free to reopen the issue with steps to reproduce, a quick explanation of your use case or a high-quality pull request.

[kriegfrj]

I think I need this one to get the CI tests working properly.

[pkriens]

@kriegfrj could you move this to the 7.1 project and close this?

[kriegfrj]

I'm happy to do it if I can figure out how?

[pkriens]

Moved to project https:/orgs/bndtools/projects/1