Closed GoogleCodeExporter closed 9 years ago
If the value is a byte array, then Weighers#byteArray() can be used to specify
the weight as the length value.
If the value is deserialized and the desire is to use its byte[] equivalent as
the weight, then the simplest work around is to use a decorator. A custom
weigher could capture the weight by calling a #size() method. This would have
marginal overhead.
There are, of course, hacky ways to avoid that overhead. An example might be to
use a ThreadLocal to pass the the length through to the weigher. That's not to
say that I'd ever stomach the idea of doing this.
The additional methods would be easy, I agree. Before venturing down that path
I'd like to know if either of the first two approaches would be acceptable.
Original comment by Ben.Manes@gmail.com
on 20 Apr 2011 at 2:01
Using a decorator is certainly an option but I think that adding the additional
methods is worth the small effort and considering that this is meant to be a an
object cache I think others would appreciate the simplicity of having the
option of passing in a weight without having to bother with creating custom
weighter's.
Original comment by pariodeu...@googlemail.com
on 20 Apr 2011 at 10:47
I'm still playing with the idea, only because public API creep needs more due
diligence. I agree that its a reasonable request and non-invasive, so I'm prone
to making the change.
What are your thoughts on the following failure case that this would allow?
- Client constructs the map with the default weigher (value --> 1)
- All calls use new weighted method, so default weigher is never used
- New code (e.g. 1yr later) adds a feature and uses the regular Map APIs. This
lets some cached items to be incorrectly weighed.
- Application runs smoothly and tests don't detect the issue. It eventually
fails in production. It can only be reproduced there due to the load / uptime
requirements.
Is this scenario the library partially at fault for enabling innocent mistakes?
Original comment by Ben.Manes@gmail.com
on 20 Apr 2011 at 9:37
Sorry, poorly edited the last line. :)
-
In this scenario, is the library partially at fault for enabling innocent
mistakes?
Original comment by Ben.Manes@gmail.com
on 20 Apr 2011 at 9:38
Perhaps you could avoid this issue with the use of simple boolean flags that
indicate if the default weighter was used or not.
An alternative would be for the client to specify with an additional optional
builder method whether they want to use the weighter methods or the
default/specified weighter.
A call to the weighter methods when the user has not chosen to enable them
could return an exception/null/false or whatever and vice versa.
Original comment by pariodeu...@googlemail.com
on 21 Apr 2011 at 1:09
Some discussion on the group w.r.t. to this issue.
http://groups.google.com/group/concurrentlinkedhashmap/browse_thread/thread/a7ef
2ef3f4d63171
Original comment by Ben.Manes@gmail.com
on 5 May 2011 at 4:01
Can you respond to the last message in the group thread? I've finally getting
back to CLHM and am hoping to release this week.
Message copied below:
--
If you know the weight up-front for both the key and value, what is
the harm of using a wrapper and a custom weigher? The only issue I see
is that it requires an extra reference and int field, which is minor
memory-wise. This would allow you to work with the current APIs,
rather than needing new ones be added.
That was satisfactory before, even though not your preference. Is that
no longer the case?
Original comment by Ben.Manes@gmail.com
on 17 May 2011 at 7:57
While not perfect, at the moment I prefer the value decorator as a work around.
Please reopen if you disagree. I am happy to reconsider.
I plan on releasing tomorrow unless you speak up.
Thanks!
Ben
Original comment by Ben.Manes@gmail.com
on 20 May 2011 at 12:05
Original issue reported on code.google.com by
pariodeu...@googlemail.com
on 20 Apr 2011 at 1:24