The stress test often has connections time out, because it overwhelms the framework. This is normally in the order of 1%. We should assert that this is the case in the test for passing connections. For example, we don't want 90% of connections to timeout, even though the rest passes and matches.
Metadata Update from @firstyear: - Custom field type adjusted to defect - Issue assigned to firstyear - Issue tagged with: Easyfix, Nunc Stans
<img alt="0001-Ticket-49154-Nunc-Stans-stress-should-assert-it-has-.patch" src="/389-ds-base/issue/raw/files/eaa577a543544b3b19e3b1b9a0b064be1157e0073921d946377abb73f1b1ae6b-0001-Ticket-49154-Nunc-Stans-stress-should-assert-it-has-.patch" />
Metadata Update from @firstyear: - Custom field reviewstatus adjusted to review
<img alt="0001-Ticket-49154-Nunc-Stans-stress-should-assert-it-has-.patch" src="/389-ds-base/issue/raw/files/4f9b7a2f54249d3459e58029b9b54cf76368af4a706690de9b9c620d28a5f177-0001-Ticket-49154-Nunc-Stans-stress-should-assert-it-has-.patch" />
<img alt="0001-Ticket-49154-Nunc-Stans-stress-should-assert-it-has-.patch" src="/389-ds-base/issue/raw/files/2da0c98a0f707499e8c1b7459aeb03e1feebda469486b41e4128859b22444be4-0001-Ticket-49154-Nunc-Stans-stress-should-assert-it-has-.patch" />
With the latest patch building in brew/mock fails on nuncstans test:
3 server_listen_accept: accept error for job [0x120578] -5971 Process open FD table is full 3 FAIL: Socket failed, -5971 -> (null)
I wonder if the limits should be adjusted in chroot or this test is too agressive?
The test has to be aggresive: We need to really "stress" the nunc-stans system to be sure it works. I can try turning it down a bit and see if that's better. What's the FD limit in chroots?
I have 1024 in mock, I asssume brew/koji has the same default.
If the test has to be aggressive and we really want to push nunc-stans to the limits, shouldn't we not abuse the build system and run stress tests on a dedicated hardware in a controlled environment?
tl;dr - I will make a second test that does a smaller number under the 1024 fd mark (maybe under 512 even).
The reason I want this test here is that it often shows issues on different architectures like dropping connections or otherwise. It's hard for me to get access to any machines or platforms within RH. I only have my home lab, and it's x86_64 only.
We want to be finding these issues sooner rather than later. And now, it may be inconvenient during the build while we iron out the kinks, but I would rather have a build fail, then see a dodgy nunc-stans ever make it's way to a customer.
As a result, I think I will make a smaller test, that quickly checks a few of these assertions and threads. I think it's important for us to find these early. We can save the larger test for QE or for developers.
Okay, this patch makes the situation much better. I split it up to have two tests, a small and large. The small caps at 256 connections, ie 512 fds. This should keep us within the boundaries of mock, but still providing a quick sanity check that our work is correct. RPMS all build correctly, so lets see how this one goes.
<img alt="0001-Ticket-49154-Nunc-Stans-stress-should-assert-it-has-.patch" src="/389-ds-base/issue/raw/files/091e73b1e286e2ac649be54fd1f65e0f91e78aaa3433952ed106b92350979a90-0001-Ticket-49154-Nunc-Stans-stress-should-assert-it-has-.patch" />
Build passes in brew/koji/mock now. Thanks!
Metadata Update from @vashirov: - Custom field reviewstatus adjusted to ack (was: review)
commit 09ce17bb51ae500f9a110cd9c43ac3ff6c76babc To ssh://git@pagure.io/389-ds-base.git 8dbfff1..b1b0574 master -> master
Metadata Update from @firstyear: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/2213
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: fixed)
Login to comment on this ticket.