天谋科技（北京）有限公司用户5908
IoTDB Singleton Pattern Enhancement Plan
输入“/”快速插入内容
IoTDB Singleton Pattern Enhancement Plan
IoTDB Singleton Pattern Enhancement Plan
用户3386用户3386用户7042用户70422024年8月5日修改
英文版
Background
Using singletons is probably the simplest way to make various components gain access to each other, while maintaing their own lifecycle. To me, there is no simpler way to do this.
Currently we are using singletons everywhere, where one component needs access to another component. Most significantly wherever configuration options are needed.
Current issues
While singletons are very simple to use, they come with quite a number of disadvantages:
1.
There can only be one instance of a singleton in a Java VM. This is particularly problematic when running tests in parallel. Due to our excessive usage of singletons, it is not possible to use Maven and JUnit options to run tests in parallel, making most use of a multi-core CI/CD server or local developer machine.
2.
Even when running tests serially, settings from one test can leak to another. If in every test not every setting is made sure to be reset, the order in which test are run can greatly impact the output. Usually tests should be run randomly. The use of singletons hereby can greatly cause flaky and hard to diagnose tests.
3.
When running IoTDB in "embedded mode", like it is done in the CtrlX App and is planned for other Apps, such as the AWS, Phoenix Contact and others, where an instance of IoTDB is started and after changing the configuration partially needs to be reconfigured, the only way to achieve this was, by adding a long sequence of reset calls to make singletons manually reset themselves. Every time a new component is added, this needs to be adjusted and if this is forgotten, unexpected behaviour can happen.
4.
In most cases, it is impossible to run Unit-Tests. Usually a unit-test would test the functionalitiy of a component in "lab-conditions" by mocking away secondary dependencies and testing the component on it's own. Due to our current usage of using singletons everywhere, it is currently generally impossible to do so. We therefore generally rely on Integration-Tests, which have the big disadvantage of being much more heavy weight. So, in order to test the same functionality, a lot more cpu, IO and memory resources are needed. The downside of Integration-Tests are, that while it is very easy to test the "happy path" (expected usage pattern), testing the "unhappy path" is very difficult and is mostly simply skipped. This results in code where we ensured correct functionality under correct and ideal conditions, however most of the code is left untested under non-idal conditions.
5.
As most of our tests are currently integration tests, because these need other components in order to be able to run them, they are located outside of the modules containing the functionality we want to test. As the directory/package-structure seems separated from that of the original component it is very hard to spot where a test for a given component is located. In general will one integration test be testing functionality in various components, so will it not be possible to allign the test structure to simplify the correlation of test and component.
6.
As running the integration-test takes a long time, most developers rely on GitHub Actions CI/CD pipeline for actually running the test. This adds a long roundtrip-time for feedback to the developer, but also wastes a lot of our GitHub Actions credits.
7.
While the separation of integration test and component make it very difficult for developers to see which tests need to be run in order to test changes that have been done, it generally makes this impossible for tooling to do. Currently there are many tools available that would run the tests related to changes first, giving a developer quicker feedback on if his changes are causing issues. Other tools would only run tests that touch code that has been changed, which would greatly speed up feedback time and drastically reduce our overall resource-consumption on the GitHub Actions CI/CD infrastructure. Tools like Develocity will only be able to provide very minor improvements.
8.
Many of the existing tests, fork IoTDB instances. Not in all cases are these cleanly taken down after the test or if a test failed. Quite often I re-run the build and it fails because of the inability of a test to start an instance of IoTDB due to already used ports. The only option in these cases is to run "killall -9 java" before running the testsuite.
Technical research
Current test-coverage of code inside a module:
Config-Node:
When running all tests in the module with coverage recording in IntelliJ this is the output I get:
18% class coverage is really bad and 11% line coverage would be considered reckless. I know a lot of the coverage is coming from the integration-test module, however I wanted to point out that in general in software engineering is is considered that a test-pyramide should exist (https://circleci.com/blog/unit-testing-vs-integration-testing/#c-consent-modal)
This implies that the most amount of testing should happen in the unit-test part of the project, followed by integration-tests, but what we are currently doing, is running allmost all tests in the E2E test phase (as we're running most integration-tests based on the distribution using a forked VM)
Data-Node: