-
Notifications
You must be signed in to change notification settings - Fork 642
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ISSUE #4630] Fix concurrency problem and split task handle threadpool #4679
Conversation
@ConfigFiled(field = "tcp.taskHandleExecutorPoolSize") | ||
private int eventMeshTcpTaskHandleExecutorPoolSize = Runtime.getRuntime().availableProcessors(); | ||
private int eventMeshTcpTaskHandleExecutorPoolSize = 2 * Runtime.getRuntime().availableProcessors(); | ||
|
||
@ConfigFiled(field = "tcp.sendExecutorPoolSize") | ||
private int eventMeshTcpMsgSendExecutorPoolSize = 2 * Runtime.getRuntime().availableProcessors(); | ||
|
||
@ConfigFiled(field = "tcp.replyExecutorPoolSize") | ||
private int eventMeshTcpMsgReplyExecutorPoolSize = 2 * Runtime.getRuntime().availableProcessors(); | ||
|
||
@ConfigFiled(field = "tcp.ackExecutorPoolSize") | ||
private int eventMeshTcpMsgAckExecutorPoolSize = 2 * Runtime.getRuntime().availableProcessors(); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although this is an IO-intensive scenario, with the original single thread pool being split into four, and each thread pool having twice the coreSize as before, the number of threads is 8 times the original. Considering that the 1-RTT time in EventMesh is relatively short, I suggest setting the coreSize
of each thread pool to the number of physical CPU cores and the maxSize
to double that. What do you think?
CI failed; please have a check. Besides, the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lrhkobe CI needs to fix it
log.error("client purpose config is error:{}", session.getClient().getPurpose()); | ||
final String clientGroup = session.getClient().getGroup(); | ||
if (!lockMap.containsKey(clientGroup)) { | ||
lockMap.putIfAbsent(clientGroup, new Object()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can if (!lockMap.containsKey(clientGroup))
be omitted here?
eventMeshTCPConfiguration.getEventMeshTcpMsgAckExecutorPoolSize(), | ||
new LinkedBlockingQueue<>(eventMeshTCPConfiguration.getEventMeshTcpMsgAckExecutorQueueSize()), | ||
new EventMeshThreadFactory("eventMesh-tcp-msg-ack", true)); | ||
|
||
broadcastMsgDownstreamExecutorService = ThreadPoolFactory.createThreadPoolExecutor( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we change the queue length from a hard-coded value to a configurable value for this ExecutorService, like that of ExecutorServices above?
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #4679 +/- ##
============================================
+ Coverage 17.39% 17.40% +0.01%
- Complexity 1759 1760 +1
============================================
Files 797 797
Lines 29795 29844 +49
Branches 2578 2579 +1
============================================
+ Hits 5182 5194 +12
- Misses 24132 24170 +38
+ Partials 481 480 -1 ☔ View full report in Codecov by Sentry. |
Fixes #4630.
Motivation
Modifications