[GitHub] [dubbo] zrlw commented on issue #8675: [3.0] 单元测试org.apache.dubbo.config.spring.schema.GenericServiceTest的问题

[GitBox]

zrlw commented on issue #8675:
URL: https://github.com/apache/dubbo/issues/8675#issuecomment-913780054


   
前面92行的demoServiceRef.$invoke调用成功说明网络没有问题，日志里没有netty连接断开的信息，这两个Reference用的是一个长连接。
   
跟踪了一下checkInvokerAvailable，调用的是ServiceDiscoveryRegistryDirectory的isAvailable方法：
   ```
       public boolean isAvailable() {
           if (isDestroyed()) {
               return false; <== 如果已经destroyed，则会触发Failed to check the status
           }
           Map<String, Invoker<T>> localUrlInvokerMap = urlInvokerMap;  <== 
这个如果为空，那么也会触发
           if (localUrlInvokerMap != null && localUrlInvokerMap.size() > 0) {
               for (Invoker<T> invoker : new 
ArrayList<>(localUrlInvokerMap.values())) {
                   if (invoker.isAvailable()) {
                       return true;
                   }
               }
           }
           return false;
       }
   ```
   
日志里没看到和destroy相关的信息，怀疑urlInvokerMap这个东西是空导致的问题，看了代码，这个东西是refreshInvoker刷进来的，跟踪了一下，貌似刷新的线程和执行ReferenceConfig的init方法的线程不是一个，刷新的线程名是main-EventThread，执行init的线程是main线程。跟进去refreshInvoker方法，发现这个方法调用toInvokers先把当前的urlInvokerMap里面的内容全清掉，在this.urlInvokerMap
 = 
newUrlInvokerMap重新赋值前，如果执行init的main线程去执行isAvailable就会返回false，debug在toInvokers方法后暂停main-EventThread线程继续执行，就能重新这个场景。
   做了个PR，才发现最新3.0分支的GenericServiceTest拆成了两个测试类，分拆之后原来的代码出异常的概率可能就小了。


-- 
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: notifications-unsubscr...@dubbo.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscr...@dubbo.apache.org
For additional commands, e-mail: notifications-h...@dubbo.apache.org