So , is everyone now in favor of this feature? Who has a -1 on this? and what is the concern?
On Tue, Oct 20, 2009 at 3:56 PM, Mark Miller <markrmil...@gmail.com> wrote: > > > On Oct 20, 2009, at 12:12 AM, Shalin Shekhar Mangar < > shalinman...@gmail.com> wrote: > > I don't think the debate is about weak reference vs. soft references. >> > > There appears to be confusion between the two here no matter what the > debate - soft references are for cachinh, weak references are not so much. > Getting it right is important. > > I >> guess the point that Lance is making is that using such a technique will >> make application performance less predictable. There's also a good chance >> that a soft reference based cache will cause cache thrashing and will hide >> OOMs caused by inadequate cache sizes. So basically we trade an OOM for >> more >> CPU usage (due to re-computation of results). >> > > That's the whole point. Your not hiding anything. I don't follow you. > > > >> Personally, I think giving an option is fine. What if the user does not >> have >> enough RAM and he is willing to pay the price? Right now, there is no way >> he >> can do that at all. However, the most frequent reason behind OOMs is not >> having enough RAM to create the field caches and not Solr caches, so I'm >> not >> sure how important this is. >> > > How important is any feature? You don't have a use for it, so it's not > important to you - someone else does so it is important to them. Soft value > caches can be useful. > > > >> On Tue, Oct 20, 2009 at 8:41 AM, Mark Miller <markrmil...@gmail.com> >> wrote: >> >> There is a difference - weak references are not for very good for caches >>> - >>> soft references (soft values here) are good for caches in most jvms. They >>> can be very nice. Weak refs are eagerly reclaimed - it's suggested that >>> impls should not eagerly reclaim soft refs. >>> >>> - Mark >>> >>> http://www.lucidimagination.com (mobile) >>> >>> >>> On Oct 19, 2009, at 8:22 PM, Lance Norskog <goks...@gmail.com> wrote: >>> >>> "Soft references" then. "Weak pointers" is an older term. (They're >>> >>>> "weak" because some bully can steal their candy.) >>>> >>>> On Sun, Oct 18, 2009 at 8:37 PM, Jason Rutherglen >>>> <jason.rutherg...@gmail.com> wrote: >>>> >>>> Lance, >>>>> >>>>> Do you mean soft references? >>>>> >>>>> On Sun, Oct 18, 2009 at 3:59 PM, Lance Norskog <goks...@gmail.com> >>>>> wrote: >>>>> >>>>> -1 for weak references in caching. >>>>>> >>>>>> This makes memory management less deterministic (predictable) and at >>>>>> peak can cause cache-thrashing. In other words, the worst case gets >>>>>> even more worse. When designing a system I want predictability and I >>>>>> want to control the worst case, because system meltdowns are caused by >>>>>> the worst case. Having thousands of small weak references does the >>>>>> opposite. >>>>>> >>>>>> On Sat, Oct 17, 2009 at 2:00 AM, Noble Paul (JIRA) <j...@apache.org> >>>>>> wrote: >>>>>> >>>>>> >>>>>>> [ >>>>>>> >>>>>>> https://issues.apache.org/jira/browse/SOLR-1513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12766864#action_12766864 >>>>>>> ] >>>>>>> >>>>>>> Noble Paul commented on SOLR-1513: >>>>>>> ---------------------------------- >>>>>>> >>>>>>> bq.Google Collections is already checked in as a dependency of Carrot >>>>>>> clustering. >>>>>>> >>>>>>> in that e need to move it to core. >>>>>>> >>>>>>> Jason . We do not need to remove the original option. We can probably >>>>>>> add an extra parameter say softRef="true" or something. That way , we >>>>>>> are >>>>>>> not screwing up anything and perf benefits can be studied separately. >>>>>>> >>>>>>> >>>>>>> Use Google Collections in ConcurrentLRUCache >>>>>>> >>>>>>>> -------------------------------------------- >>>>>>>> >>>>>>>> Key: SOLR-1513 >>>>>>>> URL: https://issues.apache.org/jira/browse/SOLR-1513 >>>>>>>> Project: Solr >>>>>>>> Issue Type: Improvement >>>>>>>> Components: search >>>>>>>> Affects Versions: 1.4 >>>>>>>> Reporter: Jason Rutherglen >>>>>>>> Priority: Minor >>>>>>>> Fix For: 1.5 >>>>>>>> >>>>>>>> Attachments: google-collect-snapshot.jar, SOLR-1513.patch >>>>>>>> >>>>>>>> >>>>>>>> ConcurrentHashMap is used in ConcurrentLRUCache. The Google >>>>>>>> Colletions concurrent map implementation allows for soft values that >>>>>>>> are >>>>>>>> great for caches that potentially exceed the allocated heap. Though >>>>>>>> I >>>>>>>> suppose Solr caches usually don't use too much RAM? >>>>>>>> http://code.google.com/p/google-collections/ >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> This message is automatically generated by JIRA. >>>>>>> - >>>>>>> You can reply to this email to add a comment to the issue online. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Lance Norskog >>>>>> goks...@gmail.com >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> -- >>>> Lance Norskog >>>> goks...@gmail.com >>>> >>>> >>> >> >> -- >> Regards, >> Shalin Shekhar Mangar. >> > -- ----------------------------------------------------- Noble Paul | Principal Engineer| AOL | http://aol.com
