From: Emmanuel Bernard <emmanuel(a)hibernate.org>
Date: 20 août 2009 13:03:37 UTC-04:00
To: Łukasz Moreń <lukasz.moren(a)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(a)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(a)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(a)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(a)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(a)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(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>>
>>>
>>>
>>
>>
>
>