[
https://issues.apache.org/jira/browse/TS-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Plevyak updated TS-39:
---------------------------
Attachment: cache-BZ59274.patch
This patch fixes the issue but leaves in the check for the infinite loop
and fixes some indentation and comments.
The FIXME comment is not correct as the lock is always held when
the write_pos is updated. Also the ??? in the comment is unnecessary
as the comment is correct.
> prior BZ59274 "fix" can result in a partition being cleared unnecessarily
> --------------------------------------------------------------------------
>
> Key: TS-39
> URL: https://issues.apache.org/jira/browse/TS-39
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
> Environment: All
> Reporter: John Plevyak
> Priority: Minor
> Attachments: cache-BZ59274.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The prior fix for BZ59274 clears the cache partition if recovery gets into a
> loop. This can occur if the last_write_pos == skip + len
> (the end of the cache partition). This can occur because the code which
> updates wraps the write_pos does so when it attempts
> the next write. The solution is to check for this at the top of recover and
> wrap recovery. Also, the variable which the prior patch used
> "prev_recover_pos" is stored in the CachePart when it is a purely local
> variable. I would suggest leaving in the check (it doesn't hurt
> if it never detects a problem). Patch forthcoming.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
