Bug 454463
| Summary: | topic tests fails to complete - not delivering all msgs | ||
|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | David Sommerseth <davids> |
| Component: | qpid-cpp | Assignee: | Kim van der Riet <kim.vdriet> |
| Status: | CLOSED NOTABUG | QA Contact: | Kim van der Riet <kim.vdriet> |
| Severity: | high | Docs Contact: | |
| Priority: | urgent | ||
| Version: | 1.0 | CC: | ovasik |
| Target Milestone: | 1.0.1 | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-07-15 20:26:26 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
David Sommerseth
2008-07-08 16:44:12 UTC
It seems to happen also without --transactional ... Is reproducible with rhts_topictests.py from marple testkit. rhts_topictests.py --rhts-mode -v -B /usr/sbin --topic-path /usr/bin --broker-params "--data-dir /tmp/topic-qpiddata" -L 50 --publisher-params "--batches 30 --durable" --listener-params "--durable" Reproduced on dell-pe1420-01.rhts.bos.redhat.com (RHTS managed) Is it possible that not all the listeners have registered their queues before the publisher is started? Gordon was spot on. The rhts_topictests.py script appears to wait 3 sec between starting 50 listeners (in the example above) and the publisher. However, when the test is run in durable mode, the store must create journal files for each of the 50 queues. This can take around 10-20 secs for normal disks - each journal has 8 files of 1.5MB. I increased the wait time to 60 secs in the script, and the tests passed ok. Ideally some kind of callback should be used when all the listeners have finished initializing, but this would need support from the topic_listener program. Note that the above scenario is for running the test on a clean journal dir where the creation of durable queues for the first time results in journal files being initialized on disk. If the 50 queues already exist, then time is taken when the broker starts to recover the 50 journals - this could take several seconds, but not as long as creating from scratch. In this case, once the broker is recovered, starting the 50 listeners could fall within the 3 second window because the queue already exists on the broker - or it could be a borderline case. Much depends on the disk hardware for durable tests. |