Skip to content

Conversation

@YoWuwuuuw
Copy link
Contributor

@YoWuwuuuw YoWuwuuuw commented Jun 5, 2025

  • I have registered the PR changes.

Ⅰ. Describe what this PR did

Currently, seata-server uses netty to manage network requests, and HTTP request processing is executed synchronously with the io thread pool of netty itself. At the same time, due to the mechanism of multiple protocols on a single port, blocking may occur under high concurrency.
Therefore, an independent thread pool is added to process HTTP requests for processing of HTTP requests asynchronously. (align seata, grpc protocol asynchronous processing)

Ⅱ. Does this pull request fix one issue?

#7405

Ⅲ. Why don't you add test cases (unit test/integration test)?

Ⅳ. Describe how to verify it

Ⅴ. Special notes for reviews

@YongGoose YongGoose linked an issue Jun 5, 2025 that may be closed by this pull request
@YongGoose
Copy link
Member

@YoWuwuuuw

I think we need to address the issue below.

Error:  Failed to execute goal org.apache.maven.plugins:maven-pmd-plugin:3.8:check (pmd-check) on project seata-core: You have 1 PMD violation. For more details see: /home/runner/work/incubator-seata/incubator-seata/core/target/pmd.xml -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-pmd-plugin:3.8:check (pmd-check) on project seata-core: You have 1 PMD violation. For more details see: /home/runner/work/incubator-seata/incubator-seata/core/target/pmd.xml
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)

@YoWuwuuuw
Copy link
Contributor Author

@YoWuwuuuw

I think we need to address the issue below.

Error:  Failed to execute goal org.apache.maven.plugins:maven-pmd-plugin:3.8:check (pmd-check) on project seata-core: You have 1 PMD violation. For more details see: /home/runner/work/incubator-seata/incubator-seata/core/target/pmd.xml -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-pmd-plugin:3.8:check (pmd-check) on project seata-core: You have 1 PMD violation. For more details see: /home/runner/work/incubator-seata/incubator-seata/core/target/pmd.xml
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)

Strangely, I did not fail the pmd-check locally

@funky-eyes
Copy link
Contributor

This branch has conflicts that must be resolved
Use the web editor or the command line to resolve conflicts before continuing.

core/src/main/java/org/apache/seata/core/rpc/netty/http/HttpDispatchHandler.java

YoWuwuuuw added 2 commits June 6, 2025 11:37
# Conflicts:
#	core/src/main/java/org/apache/seata/core/rpc/netty/http/HttpDispatchHandler.java
Copy link
Contributor

@funky-eyes funky-eyes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Error: ClusterControllerTest.watch:97 expected: <200> but was: <500>
Error: ClusterControllerTest.watchTimeoutTest:66 expected: <304> but was: <500>

@funky-eyes funky-eyes added this to the 2.5.0 milestone Jun 6, 2025
Object[] args = ParameterParser.getArgValues(httpInvocation.getParamMetaData(), handleMethod,
requestDataNode, httpContext);
Object result = handleMethod.invoke(httpController, args);
Object result = handleMethod.invoke(httpController, args);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the code range that should be asynchronous is only between lines 132-138.

@codecov
Copy link

codecov bot commented Jun 7, 2025

Codecov Report

Attention: Patch coverage is 78.46154% with 14 lines in your changes missing coverage. Please review.

Project coverage is 59.09%. Comparing base (e4a87e6) to head (4e97d47).
Report is 1 commits behind head on 2.x.

Files with missing lines Patch % Lines
...seata/core/rpc/netty/http/HttpDispatchHandler.java 65.85% 12 Missing and 2 partials ⚠️
Additional details and impacted files
@@             Coverage Diff              @@
##                2.x    #7415      +/-   ##
============================================
- Coverage     59.11%   59.09%   -0.03%     
  Complexity      529      529              
============================================
  Files          1281     1281              
  Lines         46102    46142      +40     
  Branches       5562     5561       -1     
============================================
+ Hits          27255    27267      +12     
- Misses        16274    16312      +38     
+ Partials       2573     2563      -10     
Files with missing lines Coverage Δ
...ava/org/apache/seata/common/ConfigurationKeys.java 0.00% <ø> (ø)
...in/java/org/apache/seata/common/DefaultValues.java 100.00% <ø> (ø)
...apache/seata/core/rpc/netty/NettyServerConfig.java 70.88% <100.00%> (+3.28%) ⬆️
.../autoconfigure/properties/TransportProperties.java 95.89% <100.00%> (+1.15%) ⬆️
...seata/core/rpc/netty/http/HttpDispatchHandler.java 70.12% <65.85%> (+4.55%) ⬆️

... and 5 files with indirect coverage changes

Impacted file tree graph

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Copy link
Contributor

@funky-eyes funky-eyes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

private static boolean ENABLE_TC_SERVER_BATCH_SEND_RESPONSE = CONFIG.getBoolean(ConfigurationKeys.ENABLE_TC_SERVER_BATCH_SEND_RESPONSE,
DefaultValues.DEFAULT_ENABLE_TC_SERVER_BATCH_SEND_RESPONSE);

private static int minHttpPoolSize = CONFIG.getInt(ConfigurationKeys.MIN_HTTP_POOL_SIZE, 10);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@funky-eyes I have a little bit of a question

Currently, the thread pool for handling Seata and gRPC protocols uses System.getProperty for configuration:

private static int minServerPoolSize = Integer.parseInt(System.getProperty(ConfigurationKeys.MIN_SERVER_POOL_SIZE, "50")); 
private static int maxServerPoolSize = Integer.parseInt(System.getProperty(ConfigurationKeys.MAX_SERVER_POOL_SIZE, "500")); 
private static int maxTaskQueueSize = Integer.parseInt(System.getProperty(ConfigurationKeys.MAX_TASK_QUEUE_SIZE, "20000")); 
private static int keepAliveTime = Integer.parseInt(System.getProperty(ConfigurationKeys.KEEP_ALIVE_TIME, "500")); 

In older versions, System.getProperty was used for configurations, which seemingly limited modifications to only through JVM startup parameters in the command script.

Conversely, the HTTP thread pool is configured using CONFIG.getInt:

private static int minHttpPoolSize = CONFIG.getInt(ConfigurationKeys.MIN_HTTP_POOL_SIZE, 10); 
private static int maxHttpPoolSize = CONFIG.getInt(ConfigurationKeys.MAX_HTTP_POOL_SIZE, 100); 
private static int maxHttpTaskQueueSize = CONFIG.getInt(ConfigurationKeys.MAX_HTTP_TASK_QUEUE_SIZE, 1000); private static int httpKeepAliveTime = CONFIG.getInt(ConfigurationKeys.HTTP_POOL_KEEP_ALIVE_TIME, 500); 

CONFIG.getInt supports various configuration sources, including system properties, environment variables, configuration files (e.g., Spring Boot's application.yaml), and configuration centers.
To fully leverage this, these configurations should be integrated into the seata.spring.boot.autoconfigure module(for configuration files) and added to seata/blob/2.x/script/config-center/config.txt(for config-center).

Therefore, I believe if the HTTP message handling thread pool configuration uses CONFIG.getInt, then the thread pools for Seata and gRPC messages should also switch to this configuration method. This would enable support for Spring Boot's application.yaml and integrated configuration center modes.

Additionally, I think all System.getProperty usages should be updated to CONFIG.getInt, as CONFIG.getInt encompasses all functionalities of System.getProperty.

Can you answer my confusion, thank you.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with your point. You can submit a new PR to make the thread pool configurations for Seata and gRPC read from CONFIG as well.

@funky-eyes funky-eyes merged commit 1b2f845 into apache:2.x Jun 8, 2025
9 checks passed
slievrly pushed a commit to slievrly/fescar that referenced this pull request Oct 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Seata-Server: independent HTTP thread pool

3 participants