[hibernate-dev] Fwd: Configuration for Infinispan cache working as directory provider in HSearch

Emmanuel Bernard emmanuel at hibernate.org
Thu Aug 20 13:04:12 EDT 2009 



Begin forwarded message:

> From: Emmanuel Bernard <emmanuel at hibernate.org>
> Date: 20 août 2009 13:03:37 UTC-04:00
> To: Łukasz Moreń <lukasz.moren at gmail.com>
> Subject: Re: [hibernate-dev] Configuration for Infinispan cache  
> working as  directory provider in HSearch
>

> Well except that if a CM has many Caches, you can close it only when  
> the last cache is closed. You can do that by keeping sone kind of  
> counter
>
> On 20 août 2009, at 11:08, Łukasz Moreń <lukasz.moren at gmail.com>  
> wrote:
>
>> Hmm, I have to think more about that. Caches close when  
>> DirectoryProvider stops, so CM could be also.
>>
>> 2009/8/20 Emmanuel Bernard <emmanuel at hibernate.org>
>> I don't want static code in HSearch if we can avoid that. It always  
>> creates unexpected issues. (In this case units tests will be quite  
>> messy at least).
>> Plus Caches and CacheManager don't have to be closed? They might  
>> need to be tied to the HSearch lifecycle or something.
>>
>>
>> On 20 août 09, at 09:18, Łukasz Moreń wrote:
>>
>>>
>>>
>>> 2009/8/20 Emmanuel Bernard <emmanuel at hibernate.org>
>>>
>>> On 18 août 09, at 17:35, Łukasz Moreń wrote:
>>>
>>>> Now, every directory provider creates new Infinispan CacheManager  
>>>> - factory for caches. Each manager creates cache with defined  
>>>> name. Caches with this same name make distributed one, so we can  
>>>> have one common cache, cache per directory, depends how they are  
>>>> named - that way cache is shared. This is really not efficient  
>>>> since heavy CacheManager is created with every indexed entity -   
>>>> ideally one per VM.
>>>> The better idea I think is to share one CacheManager between all  
>>>> directories in node.
>>>
>>> OK
>>>
>>>> Then shared are also caches objects locally - not like previously  
>>>> every time is created new one.
>>>
>>> I don't understand that sentence, can you detail a bit further.
>>>
>>>
>>> If one CM is used per VM: cache with defined name is created, then  
>>> if we want to get cache with this same name, new one is not  
>>> created, we get reference to existing one. So if we set up one  
>>> shared cache for all directories, locally we work on this same  
>>> object.
>>> Before with CM per lucene directory always each CM created new  
>>> cache - and they made connection, so even from same VM, data was  
>>> send over the network:).
>>>
>>>
>>>
>>>> HSearch started twice, independently, that both instances don't  
>>>> share resources - directories.? E.g. every time with different  
>>>> configuration?
>>>
>>> Yes, if you start HSearch twice, they should be totally  
>>> independent (ie not share resources like CacheManager etc.
>>>
>>>> To achieve that can be either created new CacheManager every HS  
>>>> start, or used one, but with different cache names per app.
>>>
>>> I like one CM per HS start but how do you think you can achieve  
>>> that?
>>>
>>> Actually I was thinking about one CM per app. Altough I think we  
>>> can maybe store CM's in some static Map and start HS every time  
>>> with different Infinispan setting: cluster name. Then cluster name  
>>> could be a map's key.
>>>
>>>>
>>>>
>>>> 2009/8/14 Emmanuel Bernard <emmanuel at hibernate.org>
>>>> How do you share the cache between different directories?
>>>> A static field would not work well as it would prevent HSearch to  
>>>> be started twice in a single app.
>>>>
>>>> Anyway if we share the cache, I would still like to use the per  
>>>> directory provider configuration strategy (from a config property  
>>>> point of view) and raise an exception if it turns out the  
>>>> Infinispan cache config is different between two different  
>>>> indexes. That way we can improve down the road.
>>>>
>>>> On 14 août 09, at 05:33, Łukasz Moreń wrote:
>>>>
>>>>> There is one cache for all indexes. In this case scoping  
>>>>> configuration will be hard.
>>>>> Yes, some default config will be provided. Right, different  
>>>>> propterties for xml and programmatic would be better.
>>>>>
>>>>> 2009/8/14 Emmanuel Bernard <emmanuel at hibernate.org>
>>>>> Question,
>>>>> Do we have one cache for all indexes (directories) or one per  
>>>>> directory?
>>>>>
>>>>> I feels wrong to see this configuration not scoped per index
>>>>> hibernate.search.default.directory_provider  
>>>>> blah.blah.InfinispanDirectoryProvider
>>>>> hibernate.search.default.infinispan_conf com.acme.CacheFactoryImpl
>>>>>
>>>>> hibernate.search.Address.directory_provider  
>>>>> blah.blah.InfinispanDirectoryProvider
>>>>> hibernate.search.Address.infinispan_conf conf.xml
>>>>>
>>>>> hibernate.search.User.directory_provider  
>>>>> blah.blah.InfinispanDirectoryProvider
>>>>> hibernate.search.User.infinispan_conf auto
>>>>>
>>>>> As Sanne pointed out, maybe we want different properties for  
>>>>> XML, programmatic and built-in configs. I kinda like the idea of  
>>>>> one config but it seems it will be hard to differenciate a class  
>>>>> from a config file.
>>>>>
>>>>> Emmanuel
>>>>>
>>>>>
>>>>> On 13 août 09, at 18:33, Łukasz Moreń wrote:
>>>>>
>>>>> I was thinking that maybe we can expose full conf options.  
>>>>> Infinispan supports programmatical and xml ways to configure  
>>>>> cache.
>>>>> To achieve first one, could be created some interface with  
>>>>> factory method that returns cache. User can implement that and  
>>>>> create cache as he wants.
>>>>>
>>>>> Something like that:
>>>>>
>>>>> <property name="hibernate.search.infinispan.conf"   
>>>>> value="org.hibernate.search.store.infinispan.CacheFactoryImpl" />
>>>>>
>>>>> and for xml
>>>>>
>>>>> <property name="hibernate.search.infinispan.conf"  value="xml- 
>>>>> conf.xml" />
>>>>>
>>>>>
>>>>> Exposing some configuration to infinispan makes sense. can you  
>>>>> start a thread explainig what is configurable and which one you  
>>>>> think we should expose to hsearch users. Ideally I would like to  
>>>>> offer one or two defaut config scenarios and allow to fallback  
>>>>> to a custom config.
>>>>>
>>>>> Cheers,
>>>>> Lukasz Moren
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hibernate-dev/attachments/20090820/cfeebb3a/attachment.html

More information about the hibernate-dev mailing list