LBRYCommunity/ccache
1
0
Fork 0
Code Issues Pull requests Packages Projects Releases Wiki Activity
ccache/bucket_test.go

70 lines
1.4 KiB
Go
Raw Normal View History

initial tests
2013-10-19 14:36:33 +02:00
package ccache
import (
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
. "github.com/karlseguin/expect"
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
"testing"
"time"
initial tests
2013-10-19 14:36:33 +02:00
)
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
type BucketTests struct {
}
func Tests_Bucket(t *testing.T) {
Expectify(new(BucketTests), t)
}
blank identifier for tests
2014-11-14 01:41:22 +01:00
func (_ *BucketTests) GetMissFromBucket() {
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
bucket := testBucket()
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
Expect(bucket.get("invalid")).To.Equal(nil)
initial tests
2013-10-19 14:36:33 +02:00
}
blank identifier for tests
2014-11-14 01:41:22 +01:00
func (_ *BucketTests) GetHitFromBucket() {
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
bucket := testBucket()
item := bucket.get("power")
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
assertValue(item, "9000")
initial tests
2013-10-19 14:36:33 +02:00
}
blank identifier for tests
2014-11-14 01:41:22 +01:00
func (_ *BucketTests) DeleteItemFromBucket() {
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
bucket := testBucket()
bucket.delete("power")
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
Expect(bucket.get("power")).To.Equal(nil)
initial tests
2013-10-19 14:36:33 +02:00
}
blank identifier for tests
2014-11-14 01:41:22 +01:00
func (_ *BucketTests) SetsANewBucketItem() {
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
bucket := testBucket()
2 changes: 1 - Previously, we determined if an item should be promoted in the main getter thread. This required that we protect the item.promotions variable, as both the getter and the worker were concurrently accessing it. This change pushes the conditional promotion to the worker (from the getter's point of view, items are always promoted). Since only the worker ever accesses .promotions, we no longer must protect access to it. 2 - The total size of the cache was being maintained by both the worker thread and the calling code. This required that we protect access to cache.size. Now, only the worker ever changes the size. While this simplifies much of the code, it means that we can't easily replace an item (replacement either via Set or Replace). A replcement now involves creating a new object and deleting the old one (using the existing deletables and promotable infrastructure). The only noticeable impact frmo this change is that, despite previous documentation, Replace WILL cause the item to be promoted (but it still only does so if it exists and it still doesn't extend the original TTL).
2014-12-28 05:11:32 +01:00
item, existing := bucket.set("spice", TestValue("flow"), time.Minute)
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
assertValue(item, "flow")
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
item = bucket.get("spice")
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
assertValue(item, "flow")
2 changes: 1 - Previously, we determined if an item should be promoted in the main getter thread. This required that we protect the item.promotions variable, as both the getter and the worker were concurrently accessing it. This change pushes the conditional promotion to the worker (from the getter's point of view, items are always promoted). Since only the worker ever accesses .promotions, we no longer must protect access to it. 2 - The total size of the cache was being maintained by both the worker thread and the calling code. This required that we protect access to cache.size. Now, only the worker ever changes the size. While this simplifies much of the code, it means that we can't easily replace an item (replacement either via Set or Replace). A replcement now involves creating a new object and deleting the old one (using the existing deletables and promotable infrastructure). The only noticeable impact frmo this change is that, despite previous documentation, Replace WILL cause the item to be promoted (but it still only does so if it exists and it still doesn't extend the original TTL).
2014-12-28 05:11:32 +01:00
Expect(existing).To.Equal(nil)
initial tests
2013-10-19 14:36:33 +02:00
}
blank identifier for tests
2014-11-14 01:41:22 +01:00
func (_ *BucketTests) SetsAnExistingItem() {
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
bucket := testBucket()
2 changes: 1 - Previously, we determined if an item should be promoted in the main getter thread. This required that we protect the item.promotions variable, as both the getter and the worker were concurrently accessing it. This change pushes the conditional promotion to the worker (from the getter's point of view, items are always promoted). Since only the worker ever accesses .promotions, we no longer must protect access to it. 2 - The total size of the cache was being maintained by both the worker thread and the calling code. This required that we protect access to cache.size. Now, only the worker ever changes the size. While this simplifies much of the code, it means that we can't easily replace an item (replacement either via Set or Replace). A replcement now involves creating a new object and deleting the old one (using the existing deletables and promotable infrastructure). The only noticeable impact frmo this change is that, despite previous documentation, Replace WILL cause the item to be promoted (but it still only does so if it exists and it still doesn't extend the original TTL).
2014-12-28 05:11:32 +01:00
item, existing := bucket.set("power", TestValue("9001"), time.Minute)
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
assertValue(item, "9002")
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
item = bucket.get("power")
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
assertValue(item, "9002")
2 changes: 1 - Previously, we determined if an item should be promoted in the main getter thread. This required that we protect the item.promotions variable, as both the getter and the worker were concurrently accessing it. This change pushes the conditional promotion to the worker (from the getter's point of view, items are always promoted). Since only the worker ever accesses .promotions, we no longer must protect access to it. 2 - The total size of the cache was being maintained by both the worker thread and the calling code. This required that we protect access to cache.size. Now, only the worker ever changes the size. While this simplifies much of the code, it means that we can't easily replace an item (replacement either via Set or Replace). A replcement now involves creating a new object and deleting the old one (using the existing deletables and promotable infrastructure). The only noticeable impact frmo this change is that, despite previous documentation, Replace WILL cause the item to be promoted (but it still only does so if it exists and it still doesn't extend the original TTL).
2014-12-28 05:11:32 +01:00
assertValue(existing, "9001")
added replace method
2014-11-13 16:20:12 +01:00
}
Added documentation. Bucket and LayeredBucket are no longer exported.
2014-11-14 01:56:24 +01:00
func testBucket() *bucket {
b := &bucket{lookup: make(map[string]*Item)}
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
b.lookup["power"] = &Item{
key: "power",
value: TestValue("9000"),
}
return b
initial tests
2013-10-19 14:36:33 +02:00
}
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
func assertValue(item *Item, expected string) {
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
value := item.value.(TestValue)
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
Expect(value).To.Equal(TestValue(expected))
initial tests
2013-10-19 14:36:33 +02:00
}
clean up TestValue
2013-10-19 14:45:30 +02:00
type TestValue string
initial tests
2013-10-19 14:36:33 +02:00
clean up TestValue
2013-10-19 14:45:30 +02:00
func (v TestValue) Expires() time.Time {
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
return time.Now()
initial tests
2013-10-19 14:36:33 +02:00
}
Reference in a new issue Copy permalink