dapr / dapr/java-sdk

Remove Maven dependency to run apps in ITs and stop process leaks.

Open
#201 0 comments 0 reactions 0 assignees View on GitHub
area/test/integration-tests kind/enhancement P2 size/M triaged/resolved
Dominant language
Java
Stars
300
Forks
230
Avg merge
5d 1h
Merged PRs (30d)
5

Description

Integration tests invoke `dapr run` with a `mvn` command. Instead, change how services are invoked for ITs.

### 1. Use `daprd` instead of `dapr`
Follow instructions in [debugging with daprd in IntelliJ](https://github.com/dapr/docs/tree/master/howto/intellij-debugging-daprd) to understand how `daprd` can be invoked directly. Change [DaprRun.java](https://github.com/dapr/java-sdk/blob/master/sdk-tests/src/test/java/io/dapr/it/DaprRun.java) to invoke daprd in a separate process.

### 2. Run test app as a new thread in same JVM as tests
Now, instead of running the service application as a process by invoking `mvn`, run the main function directly as a new thread inside the same JVM as tests. This will avoid having to build a separate fatjar only for test apps. There are environment variables expected by the test app, and those cannot be changed at runtime. On the other hand, all environment variables defined in [Properties.java](https://github.com/dapr/java-sdk/blob/master/sdk/src/main/java/io/dapr/utils/Properties.java) can be overridden via System properties. Since System Properties are global, see this [work around](https://stackoverflow.com/questions/9579958/system-setproperty-used-by-a-thread-impacts-other-thread-in-communication-to-ext) on how to have System Properties in ThreadLocal (not ideal for production but OK for tests IMO).

### 3. Make test app optional in `DaprRun.java`
Some tests do not need a test app, they just need `daprd`. So, offer a new constructor in `DaprRun.java` that does not have a test app class. Remove [EmptyService.java](https://github.com/dapr/java-sdk/blob/master/sdk-tests/src/test/java/io/dapr/it/services/EmptyService.java) and use the new constructor for all previous uses of that class.

### 4. Stopping `daprd`
Make sure that `DaprRun.java` stops `daprd` in `stop()` method - try gracefully for 1 minute and then forcefully. Because we are not using `dapr` anymore, `dapr stop` will not work anymore. Stop the process from JVM directly.

### 5. Verify process leaks.
* Run ITs once and use Sysinternals' `pskill.exe` as `pskill daprd.exe` and validate no process was killed. For unix systems, use `ps auxwww | grep daprd` and validate there is no `daprd` process in the output, only the `grep` process. Feel free to use another solution to validate this if preferred.
* Artificially make one of the ITs fail an assertion and run ITs. Replay validation for no `daprd` process leaked.
* Artificially throw an exception in the `@Before` method of an IT and run ITs. Replay validation for no `daprd` process leaked.

Contributor guide

Open the contributing guide

Research direction

Start with sdk-tests/src/test/java/io/dapr/it/DaprRun.java and review sdk/src/main/java/io/dapr/utils/Properties.java for how IT services are launched and configured. Check all uses of sdk-tests/src/test/java/io/dapr/it/services/EmptyService.java, then run the integration tests and verify daprd is stopped after normal completion, assertion failures, and @Before exceptions without leaked processes.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
testing
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.