When ZNC hits a timeout condition it doesn't try the next server ip in a dns round robin scenario. Instead it will try the same ip it just timed out on which may or may not continue to timeout depending on if the server is down or if it might just be very slow to respond. As it stands the timeout is about 4 minutes or so which makes for a long wait.
Example server: Freenode's round robin load balancing server address.
When ZNC hits a timeout condition it doesn't try the next server ip in a dns round robin scenario. Instead it will try the same ip it just timed out on which may or may not continue to timeout depending on if the server is down or if it might just be very slow to respond. As it stands the timeout is about 4 minutes or so which makes for a long wait.
Example server: Freenode's round robin load balancing server address.
<!-- github-sync-id:166720190 -->
Just found out that the person that reported this to me (since I can't reproduce it myself -- don't have a scenario to test on) is on ZNC 1.1-git-11-89f586d
Just found out that the person that reported this to me (since I can't reproduce it myself -- don't have a scenario to test on) is on ZNC 1.1-git-11-89f586d
<!-- github-comment-id:234135534 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
When ZNC hits a timeout condition it doesn't try the next server ip in a dns round robin scenario. Instead it will try the same ip it just timed out on which may or may not continue to timeout depending on if the server is down or if it might just be very slow to respond. As it stands the timeout is about 4 minutes or so which makes for a long wait.
Example server: Freenode's round robin load balancing server address.
Just found out that the person that reported this to me (since I can't reproduce it myself -- don't have a scenario to test on) is on ZNC 1.1-git-11-89f586d
Disregard ticket. It seems it is doing the round robin correctly based on a test I setup.
It was fixed in 1.6.0
And the original issue was #133.