[SERVER-44243] 4.2.1: test build/integration_tests/transport_layer_asio_integration_test can fail Created: 25/Oct/19 Updated: 03/Dec/19 Resolved: 03/Dec/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Testing Infrastructure |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | James P. Harvey | Assignee: | Benjamin Caimano (Inactive) |
| Resolution: | Incomplete | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Operating System: | ALL |
| Participants: |
| Description |
|
This test's results are inconsistent. I wanted to report this, especially in case it doesn't just affect the test but also mongodb in some way. It's probably not something I can really invest more time in, so I'm really hoping this is replicable by mongodb. It tends to succeed the first time I run it. It always seems to fail on additional runs, regardless of if I re-run the same (unmodified) binary that tested successful before, or start with a fresh copy of source and re-compile all over again without having rebooted. I've replicated this on another machine. `ps` doesn't seem to show anything is running, and `netstat` doesn't show anything is still bound to the port. I don't know if previous versions (<= 4.2.0) could successfully run this test run multiple times. I've certainly never had this test fail on previous versions, but I haven't re-ran tests before. I think I had this test fail a single time when it was the first run on fresh source after a reboot, but I can't say this with absolute certainty. All of my compilations use the asio supplied by mongodb. NONE of them use a system asio library. (Last time I checked, it wouldn't compile with the latest asio.) No firewalls are running on the systems I've tried this on. After a failure, I tried running the test 30 times in a row, and they all failed. Despite the output below, I've had the test both fail and pass regardless of if I'm running it directly or through resmoke. You can see the exact commands being ran here: https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=mongodb&id=70918cda9a4417bca1b5a6a1319dca464d098e8c I've also tried only running the `scons core`, `scons unittests` / `dbtest` / `integration_tests` and manually running this specific test, to rule out that it's another one of the tests that's leaving state changed.
When Test Fails
When Test Succeeds
|
| Comments |
| Comment by Benjamin Caimano (Inactive) [ 03/Dec/19 ] |
|
This ticket has gone a month without comment. I'm closing this out as incomplete. If more information is available, feel free to reopen. |
| Comment by Benjamin Caimano (Inactive) [ 29/Oct/19 ] |
|
jamespharvey20, I see that you're the active maintainer for https://aur.archlinux.org/packages/mongodb/. As a fellow arch user, nice to make your acquaintance. It looks like your failure case is a direct invocation of transport_layer_asio_integration_test. The integration tests are meant to be run with a mongodb service on the other side---traditionally a standalone mongod, a replica set, or a mongos cluster. If you have not started a service that is accessible via your connection string, it won't work at all. Effectively, these tests are on facets of our internal client driver, which is the underlying infrastructure for the mongo shell. buildscripts/resmoke.py is our test harness. When you run buildscripts/resmoke.py --suite integration_tests_standalone, it is running a mongod as well as the integration test. Do you have more complete logs for failures with resmoke.py? My first guess would be that a socket is remaining bound and that is causing follow on runs to fail. |