Background and Goal

Service Discovery

1. Well organized logs
2. Actuator endpoints
3. Tools

Relevant Skills

1. Familiar with Java
2. Familiar with Microservice architecture

Potential Mentors

1. Jun Liu, Apache Dubbo PMC Chair, junliu@apache.org
2. dev@dubbo.apache.org

    

Background and Goal

The concept of[ Proxyless Mesh|https://istio.io/v1.15/blog/2021/proxyless-grpc/] was first introduced in this blog. Please read it to learn more concept details.

We have started the development of Dubbo Proxyss Mesh for a while, so that means you don't have to start the project from scratch, anyone who gets involved can start with a specific task at hand. 

In this specific GSoC project, we need developers to mainly focus on implementing more traffic management features of Istio for Dubbo.

Relevant Skills

1. Familiar with Java
2. Familiar with Service Mesh, istio and Microservice architectures
3. Familiar with Kubernetes

Potential Mentors

1. Jun Liu, Apache Dubbo PMC Chair, junliu@apache.org

Background and Goal

Dubbo is an easy-to-use, high-performance microservice framework that provides both RPC and rich enterprise-level traffic management features.

The community has been working on the improvement of Dubbo's traffic management abilities, to make it support rich features like traffic spliting, canary release, a/b testing, circuit breaker, mocking, etc. The complete traffic management architecture in Dubbo consists of two major parts, Control Plane and Data Plane. In Dubbo, Control Plane refers to Dubbo Admin, with source code in apache/dubbo-kubernetes. Dubbo Data Plane is implemented by Dubbo sdk (Java, Go, etc)

The traffic management rules Dubbo ueses now is compatible with the rules in Istio. That means the rules generated by Dubbo Admin and sent to SDK is Istio compatible rules. In this project, we need developers to work mainly on Dubbo Admin to make sure it generates and sends those rules correctly.

Relevant Skills

1. Familiar with Golang
2. Familiar with Service Mesh, istio and Microservice architectures
3. Familiar with Kubernetes

Potential Mentors

1. Jun Liu, Apache Dubbo PMC Chair, junliu@apache.org
2. dev@dubbo.apache.org

Background and Goal

Currently, Dubbo Python exposes a serialization function interface that requires users to implement their own serialization methods. For commonly used serialization formats such as JSON and Protobuf, users must manually configure them each time. To streamline this process, we aim to build a built-in serialization layer that provides support for these common serialization formats by default.

Goal

We recommend using Pydantic to achieve this. Therefore, we expect the implementation to:

1. an internal serialization layer based on Pydantic, with support for at least JSON and Protobuf.

2. Leverage Pydantic's additional features, including data validation and other useful functionalities.

Relevant Skills

1. Familiar with Python

2. Familiar with RPC

Potential Mentors

1. Albumen Kevin, Apache Dubbo PMC, albumenj@apache.org
2. dev@dubbo.apache.org

    

    

   
   

Background and Goal

Dubbo is an easy-to-use, high-performance microservice framework that provides both RPC and rich enterprise-level traffic management features.

1. keep-alive
2. connection management
3. programming api
4. error code

Relevant Skills

1. Familiar with Golang
2. Familiar with RPC
3. Familiar HTTP/1/2/3 protocol

Potential Mentors

1. Jun Liu, Apache Dubbo PMC Chair, junliu@apache.org
2. dev@dubbo.apache.org

    

    

Background and Goal

In the API-First design paradigm, IDL (Interface Definition Language) and its corresponding generation tools have become essential. IDL files are the specifications for defining service interfaces, and generation tools can convert IDL files into executable code, thereby simplifying the development process and improving efficiency.
Currently, Apache Dubbo only provides a Maven IDL generation plugin, lacking a Gradle plugin. This brings inconvenience to developers using Gradle to build projects.

Necessity

1. Unify Build Tools: Gradle is the preferred build tool for Android projects and many Java projects. Providing a Dubbo Gradle IDL plugin can maintain the consistency of build tools and reduce the cost for developers to switch between different build tools.
2. Simplify Configuration: Gradle plugins can simplify the configuration and generation process of IDL files. Developers only need to add plugin dependencies and simple configurations in the `build.gradle` file to complete the generation of IDL files without manually executing complex commands.
3. Integrate Development Process: Gradle plugins can be better integrated with IDEs (Integrated Development Environments). Developers can directly execute Gradle tasks in the IDE, thereby realizing the automatic generation of IDL files and improving development efficiency.

Implementation Plan

1. Plugin Development: Develop a Gradle plugin that encapsulates the Dubbo IDL generation tool and provides a concise configuration interface.
2. Configuration: In the `build.gradle` file, developers can configure parameters such as the path of the IDL file and the directory of the generated code.
3. Task: The plugin provides a Gradle task for executing the generation of IDL files. Developers can execute the task through the command line or the IDE.
4. Dependency Management: The plugin can automatically manage the dependencies of the Dubbo IDL generation tool, ensuring that developers do not need to manually download and configure it.

Expected Results

• Developers can use Gradle to build Dubbo projects and easily generate the code corresponding to the IDL.
• Simplify the configuration and generation process of IDL files, and improve development efficiency.
• Better integration with IDEs to achieve automatic generation of IDL files.

Potential Mentors

1. Albumen Kevin, Apache Dubbo PMC, albumenj@apache.org
2. dev@dubbo.apache.org

    

    

Description

Synopsis

The current Apache Seata Server supports the Raft cluster mode, but the performance and throughput of the cluster are significantly limited due to the single leader in a single Raft group. Therefore, the goal is to extend Seata Server to support multi-raft capability.

Benefits to Community

Due to the characteristics of Raft, requests are processed on the leader node and the results are submitted to the followers through the Raft consensus protocol. As a result, a significant amount of computational load is placed on the leader node, while followers only need to receive the final computed result. This causes the CPU, memory, and other metrics of the leader to be much higher than those of the followers. Additionally, the throughput of a single leader is limited by the machine configuration of the highest-spec node in the cluster, making it difficult to balance the traffic effectively. Therefore, supporting multi-raft would make the load distribution more balanced across all nodes in the cluster, improving throughput and performance, while also reducing the waste of machine resources.

Deliverables

The expected delivery goal is to apply the multi-raft capability of the sofa-jraft component to Seata Server through detailed learning and practice

The step expected are the following:

• Learning and using the sofa-jraft component

• Understanding and practicing the transaction grouping capability in Seata

• Gaining a certain level of understanding of Seata's communication protocol

• Gaining a certain level of understanding of Seata's storage model, especially the Raft mode

• Ensuring compatibility between different versions

Useful links

• seata-raft-detailed-explanation

• transaction-group

• sofa-jraft

Mentor

• • Mentor: Jianbin Chen, Apache Seata(Incubating) PPMC Member jianbin@apache.org

Background

Apache Kvrocks is a distributed key-value NoSQL database that uses RocksDB as its storage engine and is compatible with Redis protocol.
 
In the past, basic Web UI capabilities have been provided for Apache Kvrocks Controller, including features such as cluster creation and migration. In the future, we aim to offer a better and more modern UI experience, also enhancing centralized visualization capabilities.

Objectives

The key objectives of the project include the following:

• Refactor the existing UI pages

• Enhance the visualization capabilities for cluster migration

• Provide a cluster Overview dashboard

Recommend Skills

1. Familiar with next.js & tailwind
2. Have a basic understanding of RESTFul
3. Have an experience of Apache Kvrocks

Mentor: Hulk Lin, Apache Apache Kvrocks PMC,  hulk@apache.org
Mailing List: dev@kvrocks.apache.org
Please leave comments if you want to be a mentor

This project consists in a series of tasks that build a sort of 'infra platform' for Beam. Some tasks include:

• Automated cleaning of infrastructure: [Task]: Build a cleaner for assets in the GCP test environment #33644
• Implement Infra-as-code for Beam infrastructure
  • Implement access permissions using IaC: [Task]: Build a cleaner for assets in the GCP test environment #33644
  • Implement drift detection for IaC resources for Beam
  • Implement 'best-practice' key management for Beam (i.e. force key rotation for service account keys, and store in secret manager secrets)

A quality proposal will include a series of features beyond the ones listed above. Some ideas:

• Detection of policy breakages, and nagging to fix
• Security detections based on cloud logging
• others?

The Apache Beam JupyterLab Sidepanel provides a valuable tool for interactive development and visualization of Apache Beam pipelines within the JupyterLab environment. This project aims to significantly enhance the sidepanel by achieving full compatibility with the latest JupyterLab 4.x release and implementing substantial UI/UX improvements. This will ensure seamless integration with modern JupyterLab workflows and provide a more intuitive and user-friendly experience for Apache Beam developers.

Apache Beam's YAML DSL provides a powerful and declarative way to define data processing pipelines. However, its adoption for complex use cases like Machine Learning (ML) and Managed IO (specifically Apache Iceberg and Kafka) is hindered by a lack of comprehensive documentation and practical examples. This project aims to significantly improve the Beam YAML documentation and create illustrative examples focused on ML workflows and Iceberg/Kafka integration, making these advanced features more accessible to users.

Apache Beam's YAML DSL provides a powerful and declarative way to define data processing pipelines. In particular, many users want to use Beam for machine learning use cases like feature generation, embedding generation, and retrieval augmented generation (RAG). Today, however, Beam integrates with a relatively limited set of feature stores and vector DBs for these use cases. This project aims to build out a rich ecosystem of connectors to systems like Pinecone and Tecton to enable these ML use cases.

Background

 
Apache RocketMQ is a distributed messaging and streaming platform that supports various messaging protocols. One of the key features of RocketMQ is its orderly message consumption capability, which guarantees that messages are processed in the order they are sent. However, there are existing issues with the POP Orderly consumption process that need to be addressed to enhance its reliability and performance.

 Current Challenges

Currently, the POP Orderly feature faces several shortcomings, particularly in scenarios where network instability leads to the loss of the attemptId carried by the consumer from the previous round. This issue can result in message consumption getting stuck until the acknowledgment response (ack) for the previous message pull times out. Such situations hinder the efficient processing of messages and reduce the overall effectiveness of the messaging system.

 Objectives

The primary objectives of this project are as follows:
●Refactor the POP Orderly Code: Analyze and redesign the existing codebase to improve its structure, maintainability, and performance.
●Optimize Performance: Implement performance enhancements that allow the POP Orderly feature to cope with network fluctuations and reduce the likelihood of consumption halting.
●Elegant Process Resolution: Develop a more graceful approach to handling the issue of consumption stalling, ensuring that the system can recover more smoothly from failures.

 Recommended Skills

1. Proficiency in Java programming.
2. Strong understanding of concurrent programming.
3. Excellent logical thinking and problem-solving skills.
4. Familiarity with message queue systems, particularly Apache RocketMQ.

Mentor

Rongtong Jin, Apache RocketMQ PMC, jinrongtong@apache.org

Potential Mentor

Juntao Ji, 3160102420@zju.edu.cn

Difficulty: Major
Project Size: ~350 hours (large)

Background

Apache RocketMQ is renowned as a cloud-native messaging and streaming platform, enabling the creation of event-driven applications with simplicity and flexibility. The RocketMQ Dashboard is a crucial component that provides users with insight into system performance and client interactions through intuitive graphs and statistical data. Despite its fundamental role, the current user interface (UI) of the RocketMQ Dashboard is outdated, affecting user experience and interaction efficiency. Additionally, while the Dashboard offers valuable functionalities, there is a pressing need to enhance its usability and ensure robust security. This project aims to refactor the RocketMQ Dashboard by redesigning its UI with a more contemporary and user-friendly approach, improving overall usability, and introducing effective security measures to safeguard data and user interactions.

Relevant Skills

• Strong Java development skills.
• Experience with modern front-end technologies and frameworks
• Proficiency in Spring Boot development.
• Understanding of UX/UI design principles. - Knowledge of security best practices in web applications.
• A keen interest in open-source projects and a willingness to learn and adapt.

Tasks

• Launch and experiment with the RocketMQ Dashboard to understand current functionalities.
• Refactor the UI of the RocketMQ Dashboard to align with modern user interface standards, ensuring it is intuitive and visually appealing.  
• Improve usability by streamlining workflows, enhancing navigation, and incorporating responsive design. 
• Integrate security features to protect user data, prevent unauthorized access, and mitigate potential vulnerabilities.
• Maintain compatibility with existing RocketMQ functionalities while focusing on enhancements. 

Learning Material

• RocketMQ HomePage: https://rocketmq.apache.org([https://rocketmq.apache.org|https://rocketmq.apache.org/])
• RocketMQ GitHub Repository: https://github.com/apache/rocketmq([https://github.com/apache/rocketmq]) 
• RocketMQ Dashboard GitHub Repository: https://github.com/apache/rocketmq-dashboard([https://github.com/apache/rocketmq-dashboard]) 

Mentor

Rongtong Jin, Apache RocketMQ PMC, jinrongtong@apache.org

Potential Mentor

Juntao Ji, 3160102420@zju.edu.cn

Overview:
The current implementation of the remote.FS interface only supports a local file system (via the implementation in local.go). This GSOC2025 project proposes to extend remote.FS with popular object storage services—namely AWS S3, Google Cloud Storage, and Azure Blob Storage. This enhancement will allow the project to support robust cloud-based backup and restore operations in addition to local storage.

Proposed Features:

1. AWS S3 Implementation:
   • Implement methods for Upload, Download, List, and Delete operations using the AWS S3 API.
2. Google Cloud Storage Implementation:
   • Provide a module that integrates with Google Cloud Storage to perform similar operations.
3. Azure Blob Storage Implementation:
   • Develop functionality to access and manage Azure Blob Storage via the remote.FS interface.

Implementation Details:

• Interface Compliance:
  Each object storage implementation must adhere to the remote.FS interface defined in remote.go.

• Error Handling & Resilience:
  Implement robust error handling, logging, and retry mechanisms to ensure reliable operations across different cloud services.

• Testing:
  Develop comprehensive unit and integration tests to cover edge cases and guarantee compatibility and stability.

• Documentation:
  Update the project documentation to detail configuration, deployment, and usage of each cloud storage option.

Apache HugeGraph(incubating) is a fast-speed and highly-scalable graph database/computing/AI ecosystem. Billions of vertices and edges can be easily stored into and queried from HugeGraph due to its excellent OLTP/OLAP ability.
 
Website: https://hugegraph.apache.org/
GitHub:

• https://github.com/apache/incubator-hugegraph/
• https://github.com/apache/incubator-hugegraph-ai/
   

  Description

Currently, we have implemented a basic GraphRAG that relies on fixed processing workflows (e.g., knowledge retrieval & graph structure updates using the same execution pipeline), leading to insufficient flexibility and high overhead in complex scenarios. The proposed task introduces an Agentic architecture based on the principles of "dynamic awareness, lightweight scheduling, concurrent execution," focusing on solving the following issues:

1. Rigid Intent Recognition: Existing systems cannot effectively distinguish between simple retrievals (e.g., entity queries) and complex operations (e.g., multi-hop reasoning), often defaulting to BFS-based template subgraph searches.
2. Coupled Execution Resources: Memory/computational resources are not isolated based on task characteristics, causing long-tail tasks to block high-priority requests.
3. Lack of Feedback Mechanisms: Absence of self-correction capabilities for erroneous operations (e.g., automatically switching to similar vertices/entities after path retrieval failures).

The task will include three core parts:

1. Dynamic Awareness Layer

• Implement an LLM-based real-time (as of February 14, 2025) intent classifier that categorizes tasks (L1 simple retrieval/L2 path reasoning/L3 graph computation/L4+ etc.) based on semantic features (verb types/entity complexity/temporal modifiers).
• Build a lightweight operation cache to generate feature hashes for high-frequency requests, enabling millisecond-level intent matching.

2. Task Orchestration Layer

• Introduce a suitable workflow/taskflow framework emphasizing low coupling, high performance, and flexibility.
• Adopt a preemptive scheduling mechanism allowing high-priority tasks to pause non-critical phases of low-priority tasks (e.g., suspending subgraph preloading without interrupting core computations).

3. Concurrent Execution

• Decouple traditional RAG pipelines into composable operations (entity recall → path validation → context enhancement → result refinement), with dynamic enable/disable support for each component.
• Implement automatic execution engine degradation, triggering fallback strategies upon sub-operation failures (e.g., switching to alternative methods if Gremlin queries timeout).

Recommended Skills

1. Proficiency in Python and familiarity with at least one open/closed-source LLM.
2. Experience with one LLM RAG/Agent framework like LangGraph/RAGflow/LLamaindex/Dify.
3. Knowledge of LLM optimization techniques and RAG construction (KG extraction/construction experience is a plus).
4. Strong algorithmic engineering skills (problem abstraction, algorithm research, big data processing, model tuning).
5. Familiarity with VectorDB/Graph/KG/HugeGraph read-write workflows and principles.
6. Understanding of graph algorithms (e.g., community detection, centrality, PageRank) and open-source community experience preferred.

Task List

• Develop a hierarchical triggering mechanism for the intent classifier to categorize L1~LN tasks within milliseconds (accuracy >90%).

• Semi-automatically generate Graph Schema/extraction prompts.

• Support dynamic routing and query decomposition.

• Design an execution trace tracker to log micro-operation resource consumption and generate optimization reports.

• Enhance retrieval with graph algorithms: Apply node importance evaluation, path search, etc., to optimize knowledge recall.

• Implement a dialogue memory management module for context-aware state tracking and information reuse.

Size

• Difficulty: Hard

• Project size: ~350 hours (full-time/large)

Potential Mentors

• Imba Jin: jin@apache.org (Apache HugeGraph PPMC)
• Simon: ming@apache.org (Apache HugeGraph PPMC)