Details
-
Bug
-
Resolution: Done
-
Major - P3
-
3.2.2
-
None
Description
From BaseCluster#selectServer():
long startTimeNanos = System.nanoTime();
|
long endTimeNanos = startTimeNanos + getUseableTimeoutInNanoseconds();
|
long curTimeNanos = startTimeNanos;
|
|
|
while (true) {
|
throwIfIncompatible(curDescription);
|
|
|
if (server != null) {
|
return server;
|
}
|
|
|
if (curTimeNanos > endTimeNanos) {
|
throw createTimeoutException(serverSelector, curDescription);
|
}
|
private long getUseableTimeoutInNanoseconds() {
|
if (settings.getServerSelectionTimeout(NANOSECONDS) < 0) {
|
return Long.MAX_VALUE;
|
}
|
return settings.getServerSelectionTimeout(NANOSECONDS);
|
}
|
|
When the server selection timeout is less than 0 (to produce 'infinite' waiting), endTimeNanos will overflow, and curTimeNanos > endTimeNanos will be trivially true.
I guess the work-around is to use a reasonably big value instead of something less-than-0, and hope the issue is fixed before that value leads to overflows ![]()
Note that master has the same issue (determined by looking at the code), also note that the #getUseableTimeoutInNanoseconds() is called from multiple places, and at least #getDescription() has the same issue.