You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As shown in the code on the left, "executor.execute(new ProcessTask(ctx, cmd))" inserts the result into the response future through the thread pool. In high concurrency scenarios, the thread pool may be overloaded, resulting in rejected requests. How to solve this problem? By adding more machine nodes or customizing thread pool monitoring?
Your scenes
Under high concurrency requests
Your advice
As a framework, custom thread pool has been implemented, which provides great convenience for developers, but also poses some hidden dangers. The thread pool also has corresponding bottlenecks. Are there any corresponding practical solutions to monitor the thread pool situation or properly configure the deployment of multiple nodes in certain ranges?
Environment
SOFABolt version:1.6.6
The text was updated successfully, but these errors were encountered:
As you described, this thread pool can be customized and its metrics can be reported to your monitoring system.
Additionally, thread pool parameter configuration is strongly related to the business scenario and needs to be adjusted through stress testing analysis. I do not think there is a silver bullet solution.
Your question
com.alipay.remoting.rpc.protocol.RpcRequestProcessor#process
As shown in the code on the left, "executor.execute(new ProcessTask(ctx, cmd))" inserts the result into the response future through the thread pool. In high concurrency scenarios, the thread pool may be overloaded, resulting in rejected requests. How to solve this problem? By adding more machine nodes or customizing thread pool monitoring?
Your scenes
Under high concurrency requests
Your advice
As a framework, custom thread pool has been implemented, which provides great convenience for developers, but also poses some hidden dangers. The thread pool also has corresponding bottlenecks. Are there any corresponding practical solutions to monitor the thread pool situation or properly configure the deployment of multiple nodes in certain ranges?
Environment
The text was updated successfully, but these errors were encountered: