You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by "John Plevyak (JIRA)" <ji...@apache.org> on 2009/12/02 19:38:21 UTC

[jira] Assigned: (TS-39) prior BZ59274 "fix" can result in a partition being cleared unnecessarily

     [ https://issues.apache.org/jira/browse/TS-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Plevyak reassigned TS-39:
------------------------------

    Assignee: John Plevyak

> 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
>            Assignee: 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.