[hibernate-dev] Hibernate Search: Master/Slave DirectoryProviders improvements proposal

Emmanuel Bernard emmanuel at hibernate.org
Mon Apr 28 16:36:34 EDT 2008


On  Apr 28, 2008, at 15:03, Sanne Grinovero wrote:

> Hello,
> Nice, I'm going to work on this as soon as my previous patch gets  
> applied.
>
> I've some more very minor issues to add to the new patch if you agree:
>
> service thread is started by:
> timer.scheduleAtFixedRate( task, period, period );
>
> I would think the first operation should start immediately, not  
> after period.

If you look at the code, the first operation is done synchronously in  
start() we can't strat HSearch until we have a working Directory ready.

>
> Also I would use schedule( task, long, long) instead of  
> scheduleAtFixedRate;
> the "atFixedRate" version means it will begin sooner if it started  
> too late,
> we don't require this (correct?).
> So I propose:
> timer.schedule( task, 0, period );

Well I kinda like scheduleAtFixedRate for the copy tasks, it sounds  
more admin friendly to me. Why do you like schedule better?

>
>
> Also the timer creates another thread, running concurrently to itself
> and skipping task if the previous is still working.
> What would I miss if I just let the Timer do the job, without needing
> the Executor around? (one less thread and less code to check
> current activity as the timer supports that check for us).

In the current scheme, the copy is run every n minutes unless the  
previous tasks takes more than n minutes. In the latter, the task is  
just skipped.
If you don't, then the tasks will pile up and the copy will run over  
and over (while the tasks try to catch up)

>
>
> Using the executor it would be nice to share the same
> executor among several Directory Providers, to have better
> resource bounds (serialize the copy for different instances
> of FSSlave/Master Providers).
> Would a static Executor instance be ugly?

Yes it would be ugly and would probably complicate hot redeployment.  
What would be the benefit really? I don't like very much the idea of  
one copy blocking all other copies. Plus there are some deadlocks  
issues between directories that HSearch deal with internally that  
might interfere as well if you share the same resource pool.

Threads are cheap.

>
>
> regards,
> Sanne
>
>
>
> 2008/4/28 Emmanuel Bernard <emmanuel at hibernate.org>:
>> One JIRA / patch is good
>> Self-conflict is not always bad "When fight begins within himself,  
>> a man's
>> worth something." - Sir Frederick Browning :)
>>
>>
>>
>> On  Apr 27, 2008, at 08:03, Sanne Grinovero wrote:
>>
>>
>>> I would like to address A and B first; may I
>>> open a single JIRA for both? both issues are related to the same  
>>> files
>>> and I would
>>> like to avoid having to produce two different patches, potentially
>> conflicting
>>> with myself.
>>>
>>
>>




More information about the hibernate-dev mailing list