lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcelo Schneider <marcelo.schnei...@digitro.com.br>
Subject Re: Spawn an indexing thread on every update
Date Fri, 12 Sep 2008 11:56:06 GMT
Our application does exactly that: a background thread 
(Thread.MIN_PRIORITY) that buffers every "waiting" document and indexes 
every ~3 minutes, then reopens the searcher. No problems so far...


*
--
*Marcelo Frantz Schneider
SIC - TCO - Tecnologia em Engenharia do Conhecimento
DÍGITRO TECNOLOGIA*

*
Simon Willnauer escreveu:
> I guess similar problems have been discussed on the list over and over again.
> Why don't you use a single update thread which takes care of batch
> processing, commit threshold or performs commits after a certain time
> span.
> This would at least prevent you from spawning all the threads which
> is, as far as I can tell not necessary.
> Your update thread could also notify you searcher to reopen the index
> as soon as a change or a batch was commited.
> If you are looking for examples you might find some good examples in
> the Solr code.
>
> - simon
>
> On Fri, Sep 12, 2008 at 11:29 AM, Ian Lea <ian.lea@gmail.com> wrote:
>   
>> Hi
>>
>>
>> Why 15 mins?  Can you try lower values to get a balance between load
>> and freshness?
>>
>>
>>
>> --
>> Ian.
>>
>>
>> On Thu, Sep 11, 2008 at 9:43 PM, nobody <dailykos@budweiser.com> wrote:
>>     
>>> Hi,
>>>
>>>  In our application, I want users to be able to search for the updates they
>>> make almost immediately. Hence, whenever they update, I spawn a thread
>>> immediately to index. However, when the load on the application is very high
>>> the number of threads spawned increases, and this results in "cannot create
>>> native thread" error.
>>>
>>> We are thinking of running the indexing thread once in every 15 mins,
>>> through a scheduler, and buffer all the writes till the thread runs.
>>> However, this will result in stale results on the search. Please advice what
>>> is the best approach in this regard.
>>>
>>> -thanks
>>> --
>>>       
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-user-help@lucene.apache.org
>>
>>
>>     
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>   

-- 
Esta mensagem foi verificada pelo sistema de antivírus da Dígitro e
acredita-se estar livre de perigo.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org


Mime
View raw message