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

[Łukasz Moreń]

Ok, thanks for advice. I think it has as each DP has an access
to SearchFactoryImplementor

2009/8/20 Emmanuel Bernard <emmanuel at hibernate.org>

>
>
> 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>
> 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>
>> 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><emmanuel at hibernate.org>
>> 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><emmanuel at hibernate.org>
>>> 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><emmanuel at hibernate.org>
>>>> 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><emmanuel at hibernate.org>
>>>>> 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> <hibernate-dev at lists.jboss.org>
>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>>  <https://lists.jboss.org/mailman/listinfo/hibernate-dev><https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>>>>>> 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/04948254/attachment.html