<ul class="contains-task-list">
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox"> I have searched the <a href="https://github.com/apache/dubbo/issues">issues</a> of this repository and believe that this is not a duplicate.</li>
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox"> I have checked the <a href="https://github.com/apache/dubbo/blob/master/FAQ.md">FAQ</a> of this repository and believe that this is not a duplicate.</li>
</ul>
<h3 dir="auto">Environment</h3>
<ul dir="auto">
<li>Dubbo version: 2.6.5</li>
<li>Operating System version: Windows10</li>
<li>Java version: 1.8.0</li>
</ul>
<h3 dir="auto">Steps to reproduce this issue</h3>
<ol dir="auto">
<li>设置一个接口的响应时间为999999999ms；</li>
<li>进行泛化调用；</li>
<li>通过MethodConfig类设置方法的相关参数（方法名称、超时时间、重试次数）；</li>
<li>通过MethodConfig类中setRetries方法设置方法的重试次数为0；</li>
</ol>
<p dir="auto">Pls. provide [GitHub address] to reproduce this issue.</p>
<h3 dir="auto">Expected Result</h3>
<p dir="auto">What do you expected from the above steps？<br>
只会调用一次，在第一次调用失败后不会重试。</p>
<h3 dir="auto">Actual Result</h3>
<p dir="auto">What actually happens?<br>
在第一次调用失败后进行重试，总共会调用3次。</p>
<p dir="auto">What is the cause?<br>
在FailoverClusterInvoker的doInvoke方法中获取获取重试次数时：<br>
int len = this.getUrl().getMethodParameter(invocation.getMethodName(), "retries", 2) + 1;<br>
由于invocation.getMethodName()为$invoke，在URL中重试次数为methodName.retries，而从URL中获取$invoke.retries，获取结果为空，然后采用默认值2，从而导致上述情况。<br>
注：这里应该通过RpcUtil工具类中的getMethodName方法获取方法名称。</p>
<ul class="contains-task-list">
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox" checked=""> I have searched the <a href="https://github.com/apache/dubbo/issues">issues</a> of this repository and believe that this is not a duplicate.</li>
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox"> I have checked the <a href="https://github.com/apache/dubbo/blob/master/FAQ.md">FAQ</a> of this repository and believe that this is not a duplicate.</li>
</ul>
<h3 dir="auto">Environment</h3>
<ul dir="auto">
<li>Dubbo version: 2.6.X</li>
<li>Operating System version: linux</li>
<li>Java version: 1.8</li>
</ul>
<h3 dir="auto">Steps to reproduce this issue</h3>
<p dir="auto">1.修改zookeeper源码，在 SessionTrackerImpl 的 设置session过期状态 与 清理session临时节点 代码中增加30s延迟，以模拟网络波动导致标记session过期与清理临时节点不同步的情况。以源码的方式启动zookeeper。<br>
2.修改CuratorZookeeperClient，设置session过期时间为 5s ，并在createEphemeral中增加日志打印，当抛出NodeExistsException时，输出EphemeralOwner与当前的sessionId<br>
3.启动provider，并确保provider的临时节点已注册到zookeeper中。<br>
4.断开provider与zookeeper的网络连接，等待5s session过期后，恢复网络连接。</p>
<h3 dir="auto">Expected Result</h3>
<p dir="auto">EphemeralOwner 与 sessionId 未被输出，或输出的 EphemeralOwner 与 sessionId 相同。等待一段时间后，provider的注册信息在zookeeper中仍然存在。</p>
<h3 dir="auto">Actual Result</h3>
<p dir="auto">可以观察到日志打印的 EphemeralOwner 与 sessionId 不同，等待一段时间后，provider的注册信息被删除，且不再恢复。此时consumer调用时无法找到此provider。</p>