[hibernate-dev] Configuration for Infinispan cache working as directory provider in HSearch
Emmanuel Bernard
emmanuel at hibernate.org
Thu Aug 20 14:24:13 EDT 2009
On 20 août 2009, at 13:25, Łukasz Moreń <lukasz.moren at gmail.com>
wrote:
> Yes, that's right, and also CM can close all its caches.
> If CM is single per HS start it could be stored as a field somewhere
> in SearchFactoryImplementor, but code won't be too clean then.
I don't want that. That would be pure pollution :)
> Another idea is to add non-static CM field to IspnDirectoryProvider
> and it will be initialized by first indexed entity that use such
> directory. Next entities will get CM from DP already initialized and
> stored in SearchFactoryImplementor.
That's one way. Try and explore that by having a specific interface
for dir providers that expose CMs
I am not sure though that a dp has access to other dps
>
>
> 2009/8/20 Emmanuel Bernard <emmanuel at hibernate.org>
> 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/d6d927a4/attachment.html
More information about the hibernate-dev
mailing list