summaryrefslogtreecommitdiffstats
path: root/net/disk_cache/entry_unittest.cc
Commit message (Collapse)AuthorAgeFilesLines
* Disable CancelSparseIO unit test while I see what's going on.rvargas@google.com2009-10-081-1/+1
| | | | | | | | | | BUG=none TEST=none TBR=nsylvain Review URL: http://codereview.chromium.org/265051 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28481 0039d316-1c4b-4281-b951-d872f2087c98
* Disk cache: Add a method to cancel pending sparse operations.rvargas@google.com2009-10-081-0/+47
| | | | | | | | | | | | | | | | | | | The sparse IO methods require exclusive use of the cache entry and they complain when that requirement is violated. When the user cancels a request and reissues another one to the same entry, we may be waiting for the previous operation to finish when we receive a new IO request, so we fail. This CL add a way for the HTTP cache to cancel IO operations and get a notification when the disk cache is able to operate on that entry again. BUG=23862 TEST=unittests Review URL: http://codereview.chromium.org/256090 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28475 0039d316-1c4b-4281-b951-d872f2087c98
* Fixing bugs in sparse cache when dealing with GetAvailableRange queries not ↵hclam@chromium.org2009-09-021-0/+15
| | | | | | | | | | | | | | | | | aligned TEST=net_unittests --gtest_filter=DiskCacheEntryTest.PartialSparseEntry In handling GetAvailableRange() queries, if the start offset is not aligned to 1KB, there was some strange behaviors: 1. The start offset found is smaller than the input offset 2. Number of continus bytes doesn't take into account offset in a block. This patch will fix the above problems. Review URL: http://codereview.chromium.org/186002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25225 0039d316-1c4b-4281-b951-d872f2087c98
* Fixing a crash in disk_cache::SparseControl::UpdateRange()hclam@chromium.org2009-09-021-1/+6
| | | | | | | | | | | | | | | TEST=net_unittests --gtest_filter=DiskCacheEntryTest::PArtialSparseEntry If we do a partial write with the following criteria, disk_cache::SparseControl will crash: 1. first_byte and last_byte in the same 1KB block 2. first_byte % 1024 != 0 3. (first_byte >> 10) % 32 == 31 Review URL: http://codereview.chromium.org/176067 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25134 0039d316-1c4b-4281-b951-d872f2087c98
* Fix DiskCacheEntryTest.MemoryOnlyDoomSparseEntryhclam@chromium.org2009-08-271-1/+1
| | | | | | | | | | | | | | BUG=12258 TEST=DiskCacheEntryTest.MemoryOnlyDoomSparseEntry The sequence that caused this test to break was to doom to the entry while it is still opened. Since closing the parent entry only delete itself and then child entries are not cleaned up. This is corrected by using InternalDoom() for destruction. Review URL: http://codereview.chromium.org/174592 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24594 0039d316-1c4b-4281-b951-d872f2087c98
* Disk cache: Reduce the chance of failing a unit test under Posix.rvargas@google.com2009-08-251-4/+15
| | | | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/174374 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24246 0039d316-1c4b-4281-b951-d872f2087c98
* Disk cache: Implement asynchronous IO for Posix.rvargas@google.com2009-08-211-4/+13
| | | | | | | | | | BUG=16507 TEST=Unittests Review URL: http://codereview.chromium.org/173170 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23990 0039d316-1c4b-4281-b951-d872f2087c98
* Revert cl 23919 to investigate valgrind failures.rvargas@google.com2009-08-211-13/+4
| | | | | | | | | | | TBR=willchan TEST=none BUG=none Review URL: http://codereview.chromium.org/174205 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23926 0039d316-1c4b-4281-b951-d872f2087c98
* Disk cache: Implement asynchronous IO for Posix.rvargas@google.com2009-08-211-4/+13
| | | | | | | | | | BUG=16507 TEST=Unittests Review URL: http://codereview.chromium.org/171085 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23919 0039d316-1c4b-4281-b951-d872f2087c98
* Disk Cache: Don't depend on the backend being enabled torvargas@google.com2009-08-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | be able to return the key of an open entry. Whenever a critical corruption is detected by the disk cache, the backend disables itself and starts failing all requests until it's able to re-create the backing store. Key's longer than 928 bytes are not stored inside the entry itself, so a file object is required to access them. The backend will reject any request for a file object after it is disabled, so a user's request for the key of an open entry will also fail. Now we keep a pointer to the related file object (if needed) so that we don't have to ask the backend for it when the user requests the current key. BUG=9952 TEST=unittest Review URL: http://codereview.chromium.org/165030 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22637 0039d316-1c4b-4281-b951-d872f2087c98
* Disk cache: Add support for having a sparse entry block thatrvargas@google.com2009-07-171-0/+117
| | | | | | | | | | | | | | | | | | is not totally filled. This is required to allow two consecutive writes to fill a given range without caring about the actual start offset of the second one (as long as it is right where the first one ended). This CL also takes care of all pending TODOs of the sparse disk cache. Sparse disk cache support is now feature complete. BUG=12258 TEST=unittests Review URL: http://codereview.chromium.org/155590 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20988 0039d316-1c4b-4281-b951-d872f2087c98
* Disk cache: Add explicit support for eviction / deletionrvargas@google.com2009-07-091-1/+58
| | | | | | | | | | | | | | | | | | | | | | | of sparse entries. I started to add code to modify the children_map of the parent entry when a child is evicted but that ended up being too much trouble for too little gain. We have to be prepared to handle the case of not finding a child entry because there is no way to make sure that the process doesn't go away at any time, so adding a lot of complexity just to avoid an extra entry lookup is just not worth it. On the other hand, potentially freeing up a lot of space when a sparse entry is deleted (insetad of just waiting for the eviction code to do the cleanup) seems like a good thing. BUG=12258 TEST=unittest Review URL: http://codereview.chromium.org/149306 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20325 0039d316-1c4b-4281-b951-d872f2087c98
* Sparse IO implementation for memory-only cachehclam@chromium.org2009-06-261-26/+102
| | | | | | | | | | | | | | Implemented the following methods: MemEntryImpl::ReadSparseData MemEntryImpl::WriteSparseData MemEntryImpl::GetAvailableRange TEST=DiskCacheEntryTest.Memory* original CL: http://codereview.chromium.org/140049 Review URL: http://codereview.chromium.org/147217 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19380 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "Implementation for memory only sparse caching" r19270.scherkus@chromium.org2009-06-251-102/+26
| | | | | | | | | | | TBR=rvargas TEST=none BUG=none Review URL: http://codereview.chromium.org/149041 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19308 0039d316-1c4b-4281-b951-d872f2087c98
* Implementation for memory only sparse cachinghclam@chromium.org2009-06-251-26/+102
| | | | | | | | | | | | Implemented the following methods for memory only cache: ReadSparseData WriteSparseData GetAvailableRange BUG=12258 Review URL: http://codereview.chromium.org/140049 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19270 0039d316-1c4b-4281-b951-d872f2087c98
* Disk Cache: Implement GetAvailableRange for the regular disk cache.rvargas@google.com2009-06-231-1/+55
| | | | | | | | | | | This is required to enable sparse caching. BUG=12258 TEST=unittest Review URL: http://codereview.chromium.org/146005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19069 0039d316-1c4b-4281-b951-d872f2087c98
* Disk cache: First pass to add support for sparse entries.rvargas@google.com2009-06-181-0/+135
| | | | | | | | | | | | | Adding Read/Write support. BUG=12258 TEST=unittests. original review: http://codereview.chromium.org/126179 Review URL: http://codereview.chromium.org/132031 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18772 0039d316-1c4b-4281-b951-d872f2087c98
* Revert cl 18723.rvargas@google.com2009-06-181-135/+0
| | | | | | | TBR=nsylvain git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18726 0039d316-1c4b-4281-b951-d872f2087c98
* Disk cache: First pass to add support for sparse entries.rvargas@google.com2009-06-181-0/+135
| | | | | | | | | | | | Adding Read/Write support. BUG=12258 TEST=unittests. Review URL: http://codereview.chromium.org/126179 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18723 0039d316-1c4b-4281-b951-d872f2087c98
* Introduce parent and child entries for MemEntryImplhclam@chromium.org2009-06-151-1/+45
| | | | | | | | | | | | | | | | | | | | | Defines enums for kParentEntry and kChildEntry in MemEntryImpl. Also has code in MemBackendImpl to create a slave entry. Parent entries are non-sparse entries until sparse API are called on them, and they would start to keep a list of child entries. Child entries hold partial content and are not susposed to be accessible from the public and are managed by the parent entry that created it. Child entries are registered in the backend's ranking list to allow individual eviction. More details about how child entries are to be used are in the comments. TEST=DiskCacheEntryTest.MemoryOnlyEnumerationWithSlaveEntries Review URL: http://codereview.chromium.org/120004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18432 0039d316-1c4b-4281-b951-d872f2087c98
* Disk Cache: Simplify CallbackTest.rvargas@google.com2009-06-091-35/+22
| | | | | | | | | | | Remove the callback id... it's not useful anymore. BUG=none TEST=current unit tests. Review URL: http://codereview.chromium.org/118407 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17924 0039d316-1c4b-4281-b951-d872f2087c98
* Remove code path that passes a file handle to the rendererhclam@chromium.org2009-05-291-99/+0
| | | | | | | | | | | | | | | | | | | | | | Since the code now does range request without any caching the code path for passing file handle is not used any more. Changes: 1. Remove response_data_file in webkit_glue::ResourceResponseHead 2. Remove response_data_file in net::ResourceInfo 3. Remove code that passes file handle using IPC 4. Remove code that passes file hadnle from network layer to ResourceDispatcherHost 5. Remove MediaResourceHandler 6. Remove code in disk_cache that expose the file handle 7. Remove ChromeURLRequestContext::CreateOffTheRecordForMedia() so no more OTR request context for media, in OTR mode simply memory cache is used 8. Reset cache size for media cache to default BUG=12249 BUG=12256 Review URL: http://codereview.chromium.org/113931 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17227 0039d316-1c4b-4281-b951-d872f2087c98
* Fixes CRLF and trailing white spaces.maruel@chromium.org2009-03-051-1/+1
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10982 0039d316-1c4b-4281-b951-d872f2087c98
* Proposed change to support resource loading for media files.hclam@chromium.org2009-03-021-0/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Highlights of changes: - Added methods to disk_cache::Entry: - Entry::PrepareTargetAsExternalFile(int index) Prepare a stream in an entry to use external file for storage. - Entry::GetExternalFile(int index) Get the external file backing the stream in the entry. - Added a property "CacheType type_" to HttpCache, along with setter and getter. There shall be two cache types, COMMON_CACHE and MEDIA_CACHE for distinguishing between different purpose of HttpCache. We have this property to trigger special behavior for caching needs of media files. - Added static methods to ChromeURLRequestContext - ChromeURLRequestContext::CreateOriginalForMedia Create a URLRequestContext for media files for the original profile. - ChromeURLRequestContext::CreateOffTheRecordForMedia Create a URLRequestContext for media files for off the record profile. - Added method to Profile interface. - GetRequestContextForMedia To get the request context for media files from the context. Design decissions: - Enforce writing to external file by calling methods to Entry rather than construct Backend by a different flag. Since we only want a valid and full response to go into an external file rather than redirection response or erroneous response, we should let HttpCache::Transaction to decide when to have an external file for response data. We eliminate a lot of useless external cache files. - Adding the CacheType enum and property to HttpCache, we could allow possible (?) future extensions to HttpCache to handle other different caching needs. And there's no need to add change constructors of HttpCache, but maybe we should add a specific constructor to accomodate a media HttpCache? - Adding Profile::GetRequestContextForMedia() Since we will need to use this new request context in ResourceDispatcherHost, I think the best place to keep it is in the profile. Also we will expose to user that there's a separate cache for media, so it's better to expose it in the Profile level to allow settings to the media cache, e.g. max file size, etc. Review URL: http://codereview.chromium.org/19747 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10745 0039d316-1c4b-4281-b951-d872f2087c98
* Extend the IOBuffer to the disk cache.rvargas@google.com2009-02-121-159/+202
| | | | | | | | | | | This is cleanup from bug 5325. Original code review: http://codereview.chromium.org/20134/show Review URL: http://codereview.chromium.org/20251 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9626 0039d316-1c4b-4281-b951-d872f2087c98
* Revert cl 9528 to fix mac test_shell_testsrvargas@google.com2009-02-101-174/+159
| | | | | | Review URL: http://codereview.chromium.org/21236 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9532 0039d316-1c4b-4281-b951-d872f2087c98
* Extend the IOBuffer to the disk cache.rvargas@google.com2009-02-101-159/+174
| | | | | | | | This is cleanup from bug 5325. Review URL: http://codereview.chromium.org/20134 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9528 0039d316-1c4b-4281-b951-d872f2087c98
* Try to consistently use arraysize() with strlcpy().deanm@chromium.org2009-01-021-9/+10
| | | | | | | | | For a char*, sizeof() == arraysize(), so there is nothing wrong with the current code. However I think it's important to be clear that the lcpy() functions work in characters and not bytes. The danger would be accidently using sizeof() with wcslcpy, for example copying some code as an example or modifying old code to use a wchar instead of a char. Review URL: http://codereview.chromium.org/17019 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7536 0039d316-1c4b-4281-b951-d872f2087c98
* Disk cache: Add support for an extra data stream for each cache entry.rvargas@google.com2008-12-041-0/+36
| | | | | | | | | | | | This is the first step to allow the http cache to store additional metadata for certain entries. The cache file format changes to version 2.0 so an effect of this cl is that the borwser will discard the old cache files. Review URL: http://codereview.chromium.org/12880 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6392 0039d316-1c4b-4281-b951-d872f2087c98
* Move Time, TimeDelta and TimeTicks into namespace base.dsh@google.com2008-10-271-0/+2
| | | | | | Review URL: http://codereview.chromium.org/7995 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@4022 0039d316-1c4b-4281-b951-d872f2087c98
* Run some disk cache unit tests on the Macmmentovai@google.com2008-08-281-1/+1
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1475 0039d316-1c4b-4281-b951-d872f2087c98
* Implement sync IO for the disk cache, and temporarily redirectrvargas@google.com2008-08-271-10/+12
| | | | | | | async IO to be performed synchronously. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1414 0039d316-1c4b-4281-b951-d872f2087c98
* Use a more compact license header in source files.license.bot2008-08-241-28/+4
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1287 0039d316-1c4b-4281-b951-d872f2087c98
* Disk cache: add a delay after TruncateData unit test to wait for IO completions.rvargas@google.com2008-08-211-0/+5
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1200 0039d316-1c4b-4281-b951-d872f2087c98
* Extend disk cache unit tests to include reuse of internal entries.rvargas@google.com2008-08-081-11/+27
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@591 0039d316-1c4b-4281-b951-d872f2087c98
* If a disk cache entry is stored as an external file, and it is reused ↵rvargas@google.com2008-08-021-0/+41
| | | | | | | | | (open/truncate/write/close), the current cache size should be modified accordingly. I'm also bumping up the version number for the cache files, to force re-creation with this revision. BUG=1305909 TEST=Unit test. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@291 0039d316-1c4b-4281-b951-d872f2087c98
* Add net to the repository.initial.commit2008-07-261-0/+713
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-24 21:07:09 +0000