Hmmm, I'm not going to even try to talk about the code itself, but I will add a couple of clarifications:
Jetty has nothing to do with it. It's in Lucene, and it's used for sorting and sometimes faceting. The cache is associated with a reader on a machine used to search. When replication happens, that searcher should be closed and any data associated with the cache is returned to the system. Someone else will have to chime in on the underlying details <G>.. By the way, what version of Solr are you using? Because the memory requirements for string sorting and faceting have been drastically reduced on the trunk version. In a really rough test I've seen 75% reductions in memory requirements (note I was doing the worst things I could think of, so I don't necessarily expect your results to be as drastic). Best Erick On Tue, Jun 21, 2011 at 5:32 AM, Bernd Fehling <bernd.fehl...@uni-bielefeld.de> wrote: > I'm trying to understand the logic of/behind fieldCache. > > Who has written this peace of code or has good knowledge about it? > > Why is it under the hood of jetty? > > I see FieldCache$StringIndex with > - f_dccollection > - f_dcyear > - f_dctype > but also > - dctitle --> f_dctitle --> f_dccreator > - title --> f_dcyear > > There are some entries without further reference like the first examples > and some that have references to further HashMaps like a chain. > Why is it this way, what is the purpose? > > What is fieldCache doing if a server is replicated, will all old content > be cleaned up because of a new index with new content? > > Regards > Bernd > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
