BewareMyPower commented on issue #1270:
URL:
https://github.com/apache/pulsar-client-go/issues/1270#issuecomment-2288549849
There is a case that the server side took 25 seconds to recover while the
client side failed with timeout.
> we have a gorotinue to check the timeout.
I didn't mean the Golang client does not check the timeout, let's take a
look at the following case (reusing the delay I ran before)
- 0.000: reconnect after 0.111s
- 0.111: reconnect after 0.213s
- 0.324: reconnect after 0.466s
- 0.790: reconnect after 0.940s
- 1.730: reconnect after 1.614s
- 3.344: reconnect after 3.383s
- 6.727: reconnect after 6.806s
- 13.533: reconnect after 15.159s
- 28.692: reconnect after 25.637s
- **29.500: assume the server was recovered at this moment**
- 30.000: the message in the pending queue failed with timeout
- 54.329: the reconnection succeeds. However, the message failed 20 seconds
ago
----
Let's see how Java client solves the issue.
```java
.setMandatoryStop(Math.max(100, conf.getSendTimeoutMs() - 100),
TimeUnit.MILLISECONDS)
```
```java
Backoff backoff = new Backoff(100, TimeUnit.MILLISECONDS, 60,
TimeUnit.SECONDS, 30000 - 100, TimeUnit.MILLISECONDS);
for (int i = 0; i < 10; i++) {
System.out.println(backoff.next());
}
```
```
100
195
398
799
1525
3136
6272
12157
24279
29355
```
Though it's a little different than I've thought. But generally, having a
delay greater than the send timeout does not make sense.
--
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]
