M org.apache.solr.core.**SolrDeletionPolicy
> updateCommits
> INFO: newest commit = 284
> Mar 15, 2013 11:56:36 AM org.apache.solr.search.**SolrIndexSearcher
> INFO: Opening Searcher@db4268b realtime
> Mar 15, 2013 11:56:36 AM org.apache.solr.update.**DirectUpdateHandler2
> commit
> INFO: end_commit_flush
>
>
>
> --
> Met vriendelijke groeten
>
> Arkadi Colson
>
> Smartbit bvba • Hoogstraat 13 • 3670 Meeuwen
> T +32 11 64 08 80 • F +32 11 64 08 81
>
>
--
Regards,
Prakhar Birla
+91 9739868086
use the backup feature of the
> replication handler.
>
> - Mark
>
> On Feb 23, 2013, at 3:54 AM, Prakhar Birla wrote:
>
> > Hi,
> >
> > We use Solr 4.0 for our main searcher so it is a very vital part. We have
> > set up a process called Index reassurance
an issue a hard commit with openSearcher set to
> false, to flush things to disk and cycle through transaction logs before
> they get huge. Solr will keep a few of the transaction logs around, and if
> they are huge, it can take a long time to replay them. You'll want to
> choose a hard commit interval that doesn't create giant transaction logs.
>
> If any of the info I've given here is wrong, someone should correct me!
>
> Thanks,
> Shawn
>
>
--
Regards,
Prakhar Birla
+91 9739868086
zero response
>
>
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/OR-OR-OR-tp4038836p4039179.html
> Sent from the Solr - User mailing list archive at Nabble.com.
>
--
Regards,
Prakhar Birla
+91 9739868086
r of results to return for each group. The default value is 1.
>
--
Regards,
Prakhar Birla
