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

From: Emmanuel Bernard <emmanuel(a)hibernate.org&gt; Date: 20 août 2009 13:03:37 UTC-04:00 To: Łukasz Moreń <lukasz.moren(a)gmail.com&gt; 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&gt; 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&gt; > 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&gt; >> >> 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&gt; >>> 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&gt; >>>> 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 >>>> >>>> >>> >>> >> >> > >