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

[Łukasz Moreń]

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/8c2d1865/attachment.html