INFO: glb_pool.c:400: Pool 0: added connection, (total pool connections: 1)
DEBUG: glb_pool.c:727: pool_handle_write() to server: 0
INFO: glb_pool.c:685: Async connection to 10.21.32.1:3305 failed: 111 (Connection refused)
INFO: glb_pool.c:697: Reconnecting to 10.21.32.1:3304
INFO: glb_listener.c:100: Accepted connection from 10.21.32.1:52057 to 10.21.32.1:3305
INFO: glb_pool.c:400: Pool 0: added connection, (total pool connections: 42949672961)
glbd: glb_pool.c:733: pool_handle_write: Assertion `dst->end != POOL_END_INCOMPLETE' failed.
INFO: glb_signal.c:42: Received signal 6. Terminating.
Aborted
Interestingly, this (client hanging, not assert) happens on CentOS, but does not seem to happen on Ubuntu...
It looks like the process goes into tight loop here:
Thread 4 (Thread 0x7f59c0114700 (LWP 19458)):
#0 0x00007f59c01fdf43 in epoll_wait () from /lib64/libc.so.6
#1 0x000000000040c901 in pool_fds_wait (pool=0x7f59c0a5c058) at glb_pool.c:260
#2 0x000000000040df81 in pool_thread (arg=0x7f59c0a5c058) at glb_pool.c:829
#3 0x00007f59c04af851 in start_thread () from /lib64/libpthread.so.0
#4 0x00007f59c01fd94d in clone () from /lib64/libc.so.6
If the first tried destination is unavailable, the connecting client gets hung. The following patch seems to get it working:
But debug build asserts:
Interestingly, this (client hanging, not assert) happens on CentOS, but does not seem to happen on Ubuntu...
It looks like the process goes into tight loop here: