sdslnmd / concurrentlinkedhashmap

Automatically exported from code.google.com/p/concurrentlinkedhashmap
Apache License 2.0
0 stars 0 forks source link

Remove catch-up executor (failed experiment) #32

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
The catchup executor is actually never used in the code except for one place: 
shouldDrainBuffers() checks if the executor is shut-down (which is true for the 
default executor). If not - no eviction is ever carried out.

Original issue reported on code.google.com by ron.pres...@gmail.com on 27 Feb 2012 at 11:52

GoogleCodeExporter commented 9 years ago
Hi Ron,

Please don't use catch-up. It was an experiment when we were trying different 
approaches for a policy in Guava. I shouldn't have released it in v1.2 and plan 
on removing it. I was trying the approaches in CLHM first since it has a richer 
set of tests, benchmarks, and is a more flexible design.

The approach we eventually settled on in Guava, Cache#cleanup(), is my 
preferred style. It will always do the work on user threads, but optionally 
allows a background thread to perform the work if there is not enough activity. 
This is more important in Guava as it supports expiration and soft/weak 
references, so a lack of activity was more pronounced.

The catchup executor disables draining on user threads and performs all of the 
work on the supplied Executor, if it was not shutdown. This has the negative 
effect that under a storm the buffers grow unbounded, so its not particularly 
safe. The eviction is carried out in the CatchUpTask and unit tested in 
EvictionTest.

The other approach that was suggested, but proved too inefficient, was to have 
user threads trigger the executor instead of running it on a schedule. This 
causes too much synchronization overhead, so that was thrown away.

I haven't been very active on CLHM since leaving Google, but I plan on removing 
the catch-up as a failed experiment for the next release. So please avoid it 
for now.

Original comment by Ben.Manes@gmail.com on 27 Feb 2012 at 7:35

GoogleCodeExporter commented 9 years ago
Oh, I see. This makes sense.

BTW, if you're no longer at Google, please consider moving this project to 
GitHub. It would make accepting code from other contributors that much easier. 
Also, it feels kind of... lonely here at Google Code. :)

Original comment by ron.pres...@gmail.com on 27 Feb 2012 at 7:44

GoogleCodeExporter commented 9 years ago
Removed in v1.3 (currently on trunk). Plan on releasing this week due to 
Cassandra feature request.

Original comment by Ben.Manes@gmail.com on 8 May 2012 at 7:21

GoogleCodeExporter commented 9 years ago
fyi, 
I *finally* migrated to git, so it should be easy for contributors to fork to 
github. I don't plan on switching to github for the project page for the time 
being.

Original comment by Ben.Manes@gmail.com on 20 Oct 2012 at 10:41