bryancall opened a new pull request, #12712: URL: https://github.com/apache/trafficserver/pull/12712
## Problem The `test_cache_Populated_Cache` unit test was failing with "Subprocess aborted" showing thousands of repeated reenable calls on the same CacheVC object. The Jenkins CI logs showed an infinite loop of reenable messages: https://ci.trafficserver.apache.org/job/master/job/os_build/47228/console ## Root Cause In `src/iocore/cache/unit_tests/main.cc`, the `CacheReadTest::read_event` handler was calling `process_event()` **inside the while loop** that consumes data blocks: ```cpp case VC_EVENT_READ_READY: { while (this->_reader->block_read_avail()) { // ... consume block ... this->process_event(event); // ❌ Called for EVERY block } break; } ``` This meant `reenable()` was being called for every block of data, which is incorrect. When reading from a populated cache with many blocks, this resulted in excessive reenables and triggered the test abort. ## The Fix Move the `process_event()` call **outside the while loop** so `reenable()` is only called **once per event** after all available data has been consumed: ```cpp case VC_EVENT_READ_READY: { while (this->_reader->block_read_avail()) { // ... consume block ... } this->process_event(event); // ✅ Called once after consuming all data break; } ``` This matches the pattern used in `CacheTestSM` (the production regression test code) and follows standard async I/O patterns: consume all available data, then signal readiness for more. ## Testing - ✅ `test_cache_Cache` - Passed (fresh cache) - ✅ `test_cache_Populated_Cache` - **Passed** (previously failing) The fix reduces reenable calls from thousands to just a handful per test run. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
