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

158 lines
4.3 KiB
Go
Raw Permalink Normal View History

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
package ccache
import (
"strconv"
removed print line to fix #1
2014-03-23 00:52:26 +01:00
"testing"
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
"time"
Fetch does not return stale items
2016-02-03 16:07:59 +01: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
)
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
type CacheTests struct{}
func Test_Cache(t *testing.T) {
Expectify(new(CacheTests), t)
}
Move size tracking to a variable, away from simply using the length of the list. This paves the way for more complex size tracking.
2014-11-20 01:03:59 +01:00
func (_ CacheTests) DeletesAValue() {
fixed possible nil panic when item is deleted immediately after being added
2014-10-25 07:24:52 +02:00
cache := New(Configure())
cache.Set("spice", "flow", time.Minute)
cache.Set("worm", "sand", time.Minute)
cache.Delete("spice")
Expect(cache.Get("spice")).To.Equal(nil)
Get now returns the *Item rather than the item's value. Get no longer actively purges stale items. Combining these two changes, CCache can now be used to implement both of Varnish's grace and saint mode.
2014-10-25 12:15:47 +02:00
Expect(cache.Get("worm").Value()).To.Equal("sand")
fixed possible nil panic when item is deleted immediately after being added
2014-10-25 07:24:52 +02:00
}
Fetch does not return stale items
2016-02-03 16:07:59 +01:00
func (_ CacheTests) FetchesExpiredItems() {
cache := New(Configure())
fn := func() (interface{}, error) { return "moo-moo", nil }
Better test
2016-02-05 14:34:58 +01:00
cache.Set("beef", "moo", time.Second*-1)
Fetch does not return stale items
2016-02-03 16:07:59 +01:00
Expect(cache.Get("beef").Value()).To.Equal("moo")
out, _ := cache.Fetch("beef", time.Second, fn)
Better test
2016-02-05 14:34:58 +01:00
Expect(out.Value()).To.Equal("moo-moo")
Fetch does not return stale items
2016-02-03 16:07:59 +01:00
}
Move size tracking to a variable, away from simply using the length of the list. This paves the way for more complex size tracking.
2014-11-20 01:03:59 +01:00
func (_ CacheTests) GCsTheOldestItems() {
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
cache := New(Configure().ItemsToPrune(10))
for i := 0; i < 500; i++ {
cache.Set(strconv.Itoa(i), i, time.Minute)
}
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
//let the items get promoted (and added to our list)
time.Sleep(time.Millisecond * 10)
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
cache.gc()
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
Expect(cache.Get("9")).To.Equal(nil)
Get now returns the *Item rather than the item's value. Get no longer actively purges stale items. Combining these two changes, CCache can now be used to implement both of Varnish's grace and saint mode.
2014-10-25 12:15:47 +02:00
Expect(cache.Get("10").Value()).To.Equal(10)
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
}
Move size tracking to a variable, away from simply using the length of the list. This paves the way for more complex size tracking.
2014-11-20 01:03:59 +01:00
func (_ CacheTests) PromotedItemsDontGetPruned() {
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
cache := New(Configure().ItemsToPrune(10).GetsPerPromote(1))
for i := 0; i < 500; i++ {
cache.Set(strconv.Itoa(i), i, time.Minute)
}
fixed tests
2014-02-28 16:50:42 +01:00
time.Sleep(time.Millisecond * 10) //run the worker once to init the list
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
cache.Get("9")
time.Sleep(time.Millisecond * 10)
cache.gc()
Get now returns the *Item rather than the item's value. Get no longer actively purges stale items. Combining these two changes, CCache can now be used to implement both of Varnish's grace and saint mode.
2014-10-25 12:15:47 +02:00
Expect(cache.Get("9").Value()).To.Equal(9)
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
Expect(cache.Get("10")).To.Equal(nil)
Get now returns the *Item rather than the item's value. Get no longer actively purges stale items. Combining these two changes, CCache can now be used to implement both of Varnish's grace and saint mode.
2014-10-25 12:15:47 +02:00
Expect(cache.Get("11").Value()).To.Equal(11)
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
}
Move size tracking to a variable, away from simply using the length of the list. This paves the way for more complex size tracking.
2014-11-20 01:03:59 +01:00
func (_ CacheTests) TrackerDoesNotCleanupHeldInstance() {
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
cache := New(Configure().ItemsToPrune(10).Track())
for i := 0; i < 10; i++ {
cache.Set(strconv.Itoa(i), i, time.Minute)
}
item := cache.TrackingGet("0")
time.Sleep(time.Millisecond * 10)
cache.gc()
Get now returns the *Item rather than the item's value. Get no longer actively purges stale items. Combining these two changes, CCache can now be used to implement both of Varnish's grace and saint mode.
2014-10-25 12:15:47 +02:00
Expect(cache.Get("0").Value()).To.Equal(0)
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
Expect(cache.Get("1")).To.Equal(nil)
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.Release()
cache.gc()
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
Expect(cache.Get("0")).To.Equal(nil)
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
}
This is a sad commit. How do you decide you need to purge your cache? Relying on runtime.ReadMemStats sucks for two reasons. First, it's a stop-the-world call, which is pretty bad in general and down right stupid for a supposedly concurrent-focused package. Secondly, it only tells you the total memory usage, but most time you really want to limit the amount of memory the cache itself uses. Since there's no great way to determine the size of an object, that means users need to supply the size. One way is to make it so that any cached item satisfies a simple interface which exposes a Size() method. With this, we can track how much memory is set put and a delete releases. But it's hard for consumers to know how much memory they're taking when storing complex object (the entire point of an in-process cache is to avoid having to serialize the data). Since any Size() is bound to be a rough guess, we can simplify the entire thing by evicting based on # of items. This works really bad when items vary greatly in size (an HTTP cache), but in a lot of other cases it works great. Furthermore, even for an HTTP cache, given enough values, it should average out in most cases. Whatever. This improve performance and should improve the usability of the cache. It is a pretty big breaking change though.
2014-04-08 17:36:28 +02:00
Move size tracking to a variable, away from simply using the length of the list. This paves the way for more complex size tracking.
2014-11-20 01:03:59 +01:00
func (_ CacheTests) RemovesOldestItemWhenFull() {
renamed MaxItems to MaxSize, updated readme
2014-11-21 09:06:27 +01:00
cache := New(Configure().MaxSize(5).ItemsToPrune(1))
This is a sad commit. How do you decide you need to purge your cache? Relying on runtime.ReadMemStats sucks for two reasons. First, it's a stop-the-world call, which is pretty bad in general and down right stupid for a supposedly concurrent-focused package. Secondly, it only tells you the total memory usage, but most time you really want to limit the amount of memory the cache itself uses. Since there's no great way to determine the size of an object, that means users need to supply the size. One way is to make it so that any cached item satisfies a simple interface which exposes a Size() method. With this, we can track how much memory is set put and a delete releases. But it's hard for consumers to know how much memory they're taking when storing complex object (the entire point of an in-process cache is to avoid having to serialize the data). Since any Size() is bound to be a rough guess, we can simplify the entire thing by evicting based on # of items. This works really bad when items vary greatly in size (an HTTP cache), but in a lot of other cases it works great. Furthermore, even for an HTTP cache, given enough values, it should average out in most cases. Whatever. This improve performance and should improve the usability of the cache. It is a pretty big breaking change though.
2014-04-08 17:36:28 +02:00
for i := 0; i < 7; i++ {
cache.Set(strconv.Itoa(i), i, time.Minute)
}
time.Sleep(time.Millisecond * 10)
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
Expect(cache.Get("0")).To.Equal(nil)
Expect(cache.Get("1")).To.Equal(nil)
Get now returns the *Item rather than the item's value. Get no longer actively purges stale items. Combining these two changes, CCache can now be used to implement both of Varnish's grace and saint mode.
2014-10-25 12:15:47 +02:00
Expect(cache.Get("2").Value()).To.Equal(2)
This is a sad commit. How do you decide you need to purge your cache? Relying on runtime.ReadMemStats sucks for two reasons. First, it's a stop-the-world call, which is pretty bad in general and down right stupid for a supposedly concurrent-focused package. Secondly, it only tells you the total memory usage, but most time you really want to limit the amount of memory the cache itself uses. Since there's no great way to determine the size of an object, that means users need to supply the size. One way is to make it so that any cached item satisfies a simple interface which exposes a Size() method. With this, we can track how much memory is set put and a delete releases. But it's hard for consumers to know how much memory they're taking when storing complex object (the entire point of an in-process cache is to avoid having to serialize the data). Since any Size() is bound to be a rough guess, we can simplify the entire thing by evicting based on # of items. This works really bad when items vary greatly in size (an HTTP cache), but in a lot of other cases it works great. Furthermore, even for an HTTP cache, given enough values, it should average out in most cases. Whatever. This improve performance and should improve the usability of the cache. It is a pretty big breaking change though.
2014-04-08 17:36:28 +02:00
}
test + fix for actual size function
2014-11-21 08:59:04 +01:00
func (_ CacheTests) RemovesOldestItemWhenFullBySizer() {
renamed MaxItems to MaxSize, updated readme
2014-11-21 09:06:27 +01:00
cache := New(Configure().MaxSize(9).ItemsToPrune(2))
test + fix for actual size function
2014-11-21 08:59:04 +01:00
for i := 0; i < 7; i++ {
cache.Set(strconv.Itoa(i), &SizedItem{i, 2}, time.Minute)
}
time.Sleep(time.Millisecond * 10)
Expect(cache.Get("0")).To.Equal(nil)
Expect(cache.Get("1")).To.Equal(nil)
Expect(cache.Get("2")).To.Equal(nil)
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(cache.Get("3")).To.Equal(nil)
Expect(cache.Get("4").Value().(*SizedItem).id).To.Equal(4)
test + fix for actual size function
2014-11-21 08:59:04 +01:00
}
func (_ CacheTests) SetUpdatesSizeOnDelta() {
cache := New(Configure())
cache.Set("a", &SizedItem{0, 2}, time.Minute)
cache.Set("b", &SizedItem{0, 3}, time.Minute)
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
time.Sleep(time.Millisecond * 5)
test + fix for actual size function
2014-11-21 08:59:04 +01:00
Expect(cache.size).To.Equal(int64(5))
cache.Set("b", &SizedItem{0, 3}, time.Minute)
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
time.Sleep(time.Millisecond * 5)
test + fix for actual size function
2014-11-21 08:59:04 +01:00
Expect(cache.size).To.Equal(int64(5))
cache.Set("b", &SizedItem{0, 4}, time.Minute)
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
time.Sleep(time.Millisecond * 5)
test + fix for actual size function
2014-11-21 08:59:04 +01:00
Expect(cache.size).To.Equal(int64(6))
cache.Set("b", &SizedItem{0, 2}, time.Minute)
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
time.Sleep(time.Millisecond * 5)
test + fix for actual size function
2014-11-21 08:59:04 +01:00
Expect(cache.size).To.Equal(int64(4))
cache.Delete("b")
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
time.Sleep(time.Millisecond * 100)
test + fix for actual size function
2014-11-21 08:59:04 +01:00
Expect(cache.size).To.Equal(int64(2))
}
replace is size-aware
2014-11-21 09:45:11 +01:00
func (_ CacheTests) ReplaceDoesNotchangeSizeIfNotSet() {
cache := New(Configure())
cache.Set("1", &SizedItem{1, 2}, time.Minute)
cache.Set("2", &SizedItem{1, 2}, time.Minute)
cache.Set("3", &SizedItem{1, 2}, time.Minute)
cache.Replace("4", &SizedItem{1, 2})
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
time.Sleep(time.Millisecond * 5)
replace is size-aware
2014-11-21 09:45:11 +01:00
Expect(cache.size).To.Equal(int64(6))
}
func (_ CacheTests) ReplaceChangesSize() {
cache := New(Configure())
cache.Set("1", &SizedItem{1, 2}, time.Minute)
cache.Set("2", &SizedItem{1, 2}, time.Minute)
cache.Replace("2", &SizedItem{1, 2})
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
time.Sleep(time.Millisecond * 5)
replace is size-aware
2014-11-21 09:45:11 +01:00
Expect(cache.size).To.Equal(int64(4))
cache.Replace("2", &SizedItem{1, 1})
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
time.Sleep(time.Millisecond * 5)
replace is size-aware
2014-11-21 09:45:11 +01:00
Expect(cache.size).To.Equal(int64(3))
cache.Replace("2", &SizedItem{1, 3})
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
time.Sleep(time.Millisecond * 5)
replace is size-aware
2014-11-21 09:45:11 +01:00
Expect(cache.size).To.Equal(int64(5))
}
test + fix for actual size function
2014-11-21 08:59:04 +01:00
type SizedItem struct {
id int
s int64
}
func (s *SizedItem) Size() int64 {
return s.s
}
Reference in a new issue Copy permalink