RainYuY commented on PR #15883: URL: https://github.com/apache/dubbo/pull/15883#issuecomment-3717707975
> > > > So you haven’t encountered the situation where invokers are refreshed late? From my understanding of your code, if a request is being routed, the invoker list cannot be refreshed. As a result, the refresh process will be blocked until routing is completed. However, if routing is ongoing continuously (e.g., a read lock is held persistently), the write lock will take much longer to be acquired. > > > > > > > > > you are right. I found that during the release period of a service provider, the overall Dubbo call time increased due to lock blocking until the service provider completed the release. So, I wonder if there is a better way to solve this problem, but currently all I can think of is to lock it first to ensure that the call can be made normally instead of being unable to call directly > > > > > > @vqianxiao I have checked this. This check is designed for the multiple chain design, so it cannot be removed. However, your issue also needs to be addressed. I still have concerns about this scenario, but after careful consideration, I think implementing a fair lock would be a viable solution—meaning write locks will be acquired before read locks attempt to acquire them. Although this may result in some performance overhead, it is acceptable for the sake of data consistency. Do you have time to verify whether the lock works as we designed it in high QPS scenarios? If it does not function correctly, we must consider refactoring this lock. Additionally, if you have a better solution, we will give it high priority for consideration. This issue is currently an important one that we need to address soon. > > I tested the fair lock and found that there would be some fluctuations in time consumption during the release period, but there would never be a situation where the entire service consumer could not be invoked at all and had to be restarted So how about modifying your Pull Request to use a fair lock? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
