test: fix 'address already in use' flaky fails #4008
Labels
Milestone
Comments
Totktonada
added
test-run.py
qa
This was referenced Apr 8, 2019
|
Not blocked anymore. |
avtikhon
added a commit
that referenced
this issue
Jun 5, 2019
Enabled use_unix_sockets and use_unix_sockets_iproto options to use unix sockets iproto instead of TcpPortDispatcher which was previously introduced to eliminate the race condition when two workers trying to use the same port: the idea was that each worker used its own ports range. Really these ports could race with client ports (from, say, net.box or replication), which typically didn't use bind() and so bound to a random available port (despite any dispatched ranges) and could produce 'Address already in use' error. Closes: #4008
avtikhon
added a commit
that referenced
this issue
Jun 7, 2019
Enabled use_unix_sockets_iproto option to use unix sockets iproto provides the new way to handle the problem with 'Address already in use' error. It lets test-run appoint unix sockets for LISTEN environment variable values. Before this change the TcpPortDispatcher was used to eliminate the race condition when two workers trying to use the same port: the idea was that each worker used its own ports range. Really these ports could race with client ports (from, say, net.box or replication), which typically didn't use bind() and so bound to a random available port (despite any dispatched ranges) and could produce 'Address already in use' error. Closes: #4008
kyukhin
pushed a commit
that referenced
this issue
Jun 7, 2019
Enabled use_unix_sockets_iproto option to use unix sockets iproto provides the new way to handle the problem with 'Address already in use' error. It lets test-run appoint unix sockets for LISTEN environment variable values. Before this change the TcpPortDispatcher was used to eliminate the race condition when two workers trying to use the same port: the idea was that each worker used its own ports range. Really these ports could race with client ports (from, say, net.box or replication), which typically didn't use bind() and so bound to a random available port (despite any dispatched ranges) and could produce 'Address already in use' error. Closes: #4008 (cherry picked from commit 60f84cb)
avtikhon
added a commit
that referenced
this issue
Jul 5, 2019
Use unix sockets for iproto connections in sql-tap suite. Enabled use_unix_sockets_iproto option to use unix sockets iproto provides the new way to handle the problem with 'Address already in use' error. It lets test-run appoint unix sockets for LISTEN environment variable values. Check the previous commit for the other suites: 60f84cb ('test: use unix sockets for iproto connections') Closes #4008
Totktonada
pushed a commit
that referenced
this issue
Jul 6, 2019
Enabled use_unix_sockets_iproto option to use unix sockets iproto provides the new way to handle the problem with 'Address already in use' error. It lets test-run appoint unix sockets for LISTEN environment variable values. Before this change the TcpPortDispatcher was used to eliminate the race condition when two workers trying to use the same port: the idea was that each worker used its own ports range. Really these ports could race with client ports (from, say, net.box or replication), which typically didn't use bind() and so bound to a random available port (despite any dispatched ranges) and could produce 'Address already in use' error. Closes: #4008 (cherry picked from commit 60f84cb)
avtikhon
added a commit
that referenced
this issue
Aug 15, 2019
Enable unix sockets for iproto connections in sql-tap suite and use it at sql-tap/gh-4077-iproto-execute-no-bind test. Enabled use_unix_sockets_iproto option to use unix sockets, which provides the new way to handle the problem with 'Address already in use' error. It lets test-run appoint unix sockets for LISTEN environment variable values. Check the previous commit for the other suites: 60f84cb ('test: use unix sockets for iproto connections') Follows up #4008
avtikhon
added a commit
that referenced
this issue
Aug 16, 2019
Set hard-coded unix sockets for iproto connections for all the tests that used LISTEN test-run environment variable at all *-tap suites which used core = app in suites.ini configuration files, because 'app' core in test-run didn't provide the ability to use unix sockets. It helped to handle the problem with 'Address already in use' error. Check the previous commit that set the use of sockets: 60f84cb ('test: use unix sockets for iproto connections') Follows up #4008
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Either fix tarantool/test-run#141 or enable
use_unix_socketsanduse_unix_sockets_iprotooptions where it is correct and possible. Former is cleaner, latter is easier.See also tarantool/test-run#115 for examples how to reproduce the error with good probability.
The text was updated successfully, but these errors were encountered: