concrete-issue.md

Implement a Future Using Managed Blocker in ForkJoinPool to Improve Concurrency

🆕🐥 First Timers Only

This issue is reserved for people who never contributed to Hedera or any open source project in general before. We know that the process of creating a pull request (PR) is a big barrier for new contributors. The goal of this issues and all other issues that are labeled by 'good first issue' is to help you doing your first contribution to Hedera.

👾 Description of the issue

This section descrips the issue that should be solved. We try to define the usecase and goal of the issue as concrete as possible. If you need more information please do not hesitate to reach out to us by leaving a comment.

Context:

In our current system, futures are implemented using a latch mechanism, which can block threads in a ForkJoinPool. This blocking behavior occurs because when a thread waits on a future, it is unable to perform other tasks, effectively reducing the concurrency level of the ForkJoinPool by one until the future is resolved.

Problem:

This reduction in concurrency is problematic for our system's efficiency, especially under high load, as it can lead to underutilization of CPU resources and increased task completion time.

Proposed Solution:

To address this issue, we propose the implementation of a new type of Future that utilizes the ManagedBlocker interface. This interface allows the ForkJoinPool to dynamically adjust its pool size and task assignments based on blocking states, potentially mitigating the reduction in concurrency.

Detailed Steps:

• Research ManagedBlocker: Understand how the java.util.concurrent.ForkJoinPool.ManagedBlocker interface works and how it can be used to manage thread states more effectively in a concurrency environment.
• Design a Future with ManagedBlocker: Create a new Future implementation that integrates with the ManagedBlocker. This involves designing a system where the future notifies the ForkJoinPool when it is about to block and when it is unblocked. The best module for that new API is swirlds-common.
• Implement the ManagedBlocker Future: Develop the code for this new Future, ensuring it adheres to the standard Future interface while enhancing the ForkJoinPool's ability to manage blocked threads.
• Testing: Write unit and integration tests to verify that the new Future implementation works as expected and improves the ForkJoinPool's efficiency.
• Documentation: Document the implementation details, usage examples, and the impact of the new Future on thread management and pool efficiency.

Expected Outcome:

The successful implementation of this feature should increase the overall efficiency of task execution in environments using ForkJoinPool by minimizing the negative impact of blocked threads on concurrency.

Assumed Skills Required:

• Java concurrency
• Familiarity with ForkJoinPool and Future interfaces
• Ability to write clean, efficient, and well-documented code

📋 Step by step guide to do a contribution

If you never contributed to an open source project at GitHub this guide give you an introduction of the workflow. A more detailed general documentation of the GitHub PR workflow can be found here. Next to that we recorded the full workflow as a YouTube video that can be found here (TODO).

• Claim this issue: Comment below that you are interested in working on the issue
• Wait for assignment: A community member with the given rights will add you as an assignee of the issue
• Fork the repository: You can simply do that in GitHub (by simply clicking the 'fork' button).
• Check out the forked repository
• Create a feature branch for the issue. We do not have any hard naming definition for branches but it is best practice to prefix the branch name with the issue id.
• Solve the issue in your branch.
• Commit your changes: Here it is important to add Signed-off-by info to the commit (see TODO) to accept the "Developer Certificate of Origin" (https://developercertificate.org).
• Start a Pull Request (PR): We have a pattern for naming pull request that is checked by a GitHub Action. We use that pattern to support the creation of automatic release notes. All information about our PR naming pattern can be found here (TODO).
• Check GitHub Actions: We have several GitHub Actions that will be triggered automatically for each PR. An overview of all actions and its definition can be found here (TODO). If a GitHub Action fails and you do not understand the cause of that error do not hesitate to add a comment to the PR and ask the Hedera developer community for support.
• Wait for reviews: Members of the Hedera developer community will review your PR. If a reviewer find some missing peaces or a problem he or she will start a discussion with you and describe the next steps how the problem can be solved.
• You did it 🎉: We will merge the fix in the develop branch. Thanks for being part of the Hedera community as an open source contributor ❤️

🎉 Contribute to Hacktoberfest

Solve this issue as part of the Hacktoberfest event and get a change to receive cool goodies like a T-Shirt. 🎽

🤔 Additional informantion

If you have any questions just ask us directly in this issue by adding a comment. Next to that you can join our community chat at (TODO: Discord, Slack?). A general manual about open source contributions can be found here.

NOTE: This concrete sample for an issue issues is based on hashgraph/hedera-services#11051