Re: disable caches in real time

2010-05-19 Thread Marco Martinez
Hi Chris, Thank you for your answer. I've always undestand that if you do a commit (replication does it), a new searcher is open, and you lose performance (queries per second) while the caches are regenerated. I think i don't explain correctly my situation before, with my schema i want to avoid

Re: disable caches in real time

2010-05-19 Thread Chris Hostetter
: I've always undestand that if you do a commit (replication does it), a new : searcher is open, and you lose performance (queries per second) while the : caches are regenerated. I think i don't explain correctly my situation not if you configure your caches with autowarming -- then solr will

RE: disable caches in real time

2010-05-19 Thread Nagelberg, Kallin
by a commit is not seen by users until it has been warmed, at which point it is atomically swapped. -Kallin Nagelberg -Original Message- From: Chris Hostetter [mailto:hossman_luc...@fucit.org] Sent: Wednesday, May 19, 2010 2:38 PM To: solr-user@lucene.apache.org Subject: Re: disable caches

Re: disable caches in real time

2010-05-18 Thread Chris Hostetter
: I want to know if there is any approach to disable caches in a specific core : from a multicore server. only via hte config. : I have a multicore server where the core0 will be listen to the queries and : other core (core1) that will be replicated from a master server. Once the : replication

Re: disable caches in real time

2010-05-17 Thread Marco Martinez
Any suggestions? I have thought in have two configurations per server and reload each one with the appropiated config file but i would prefer another solution if its possible. Thanks, Marco Martínez Bautista http://www.paradigmatecnologico.com Avenida de Europa, 26. Ática 5. 3ª Planta 28224

disable caches in real time

2010-05-14 Thread Marco Martinez
Hi, I want to know if there is any approach to disable caches in a specific core from a multicore server. My situation is the next: I have a multicore server where the core0 will be listen to the queries and other core (core1) that will be replicated from a master server. Once the replication