Re: [infinispan-dev] Feedback on Infinispan patch

Hi Łukasz, what are the news about the Lucene Directory? I'm very eager to test it, and have some time to help you if needed. Is there an updated patch to see? How are you testing it? Maybe I could help on that? Also we're going to need some "glue" to integrate the first part of your work (the jgroups backend) with the second part (the directory), as the jgroups backend will need to choose a single node to be used for indexwrites; if this node is removed from the cluster a new one should be elected. Manik had commented about this: "One way to do this is to use the JGroups coordinator as the master..." but since then the discussion on this was discontinued. Sanne 2009/8/26 Łukasz Moreń <lukasz.moren(a)gmail.com&gt;: > Hi, thanks for comments ant tips. I'm improving it. > Yes, I was checking with profiler tool and hashcode - even not so heavy - > was called often summary took some time. > There is one test where multiple threads can read or write from/to different > cache instances. However I think would be good to do some real test e.g. > with JMeter on sample app. > > > 2009/8/26 Manik Surtani <manik(a)jboss.org&gt; >> >> Hi there - all looks good. Some comments: >> >> Summary documentation - is this going to be published on a wiki page or >> something somewhere? Especially the Infinispan bit? I think people will >> find this info very useful... >> CacheKey - if this class is what everything is going to be used in the >> cache, for performance you should cache the hashcode. Calculate it once and >> then cache it as an instance variable. If this class is immutable it can be >> done on construction, even. Infinispan uses hashcode() a lot. :-) But >> then again, depending on how many entries live in the cache, the overhead of >> an extra int for every entry may be heavy ... >> LockCacheKey - is probably more performant if this is implemented as a >> boolean flag on CacheKey. Then you won't need to look at the class type >> when working out hashcodes >> Have you written any stress or performance tests? >> >> Cheers >> Manik >> On 23 Aug 2009, at 22:53, Łukasz Moreń wrote: >> >> Hi, >> Yes, I can adjust the patch next days. I've just noticed that I send >> summary in not friendly format :), better one is now attached. >> There is explanation for yours questions below. >> >> >> 2009/8/23 Emmanuel Bernard <emmanuel(a)hibernate.org&gt; >>> >>> Hey Lukasz, >>> Your patch looks quite good and pass tests on my side. >>> I encourage others to check out the patch before we apply it (ideally >>> another person form HSearch and one person from infinispan. >>> >>> Lukasz, I have a few questions/remarks though before applying it. Can you >>> answer / adjust the patch? >>> IndexWriterSetting >>> Why move to return Object in parsing from the initial int? >> >> IndexWriterSetting has to set up MergeScheduler in IndexWriter. Before, >> parsing was responsible for number conversion from String to int. Now I have >> to parse class name, and build/return MergeScheduler from it. >> >>> >>> Move DPHelper#createInfinispanCacheManager to IDP >>> this is not something that can be shared as it creates a hard dependency >>> on infinispan otherwise. >>> in createInfinispanCacheManager >>> Don't log in error the fact that xml is not used if a default config is >>> used. Just log in trace at best. >>> Rename InfinispanCacheManagerConfigurationImpl to >>> DefaultInfinispanCacheManagerConfiguration or even better with a name >>> describing nicely the behavior of the infinispan config. >>> in InfinispanIndexOutput, is it possible to get writeBytes bigger than >>> buffer size? If yes, does newCheck creates the appropriate numbers of >>> chunks? >> >> Yes it is possible. Writing process is divided into stages, during every >> stage can be written max: buffer_size bytes. At the end of the stage its >> checked if necessary is new chunk, if so new chunk is created. >> >>> >>> InfinispanDirectoryProvider >>> put the configuration proeprties available in the >>> InfinispanDirectoryProvider javadoc. >>> I think the default cache name should be "Hibernate Search" instead of >>> "HSInfinispanCache". We know it's in infinispan :) >>> what's the try catch opening and closing an IW about? It looks weird. >> >> IW is opened with create=true parameter, first index have to be >> initialized/created. Always next IW is opened with create=false parameter, >> then data is appended to exisitng index. Similar things are done in other >> DP's. >>> >>> in stop() >>> you don't close the CacheManager? How is that? >> >> Yes. Should be closed. >> >>> >>> InfinispanCacheManagerConfigurationImpl >>> What does "Infinispan-Cluster" correspond to? Why this name? Shouldn't it >>> be "Hibernate Search cluster"? >>> Is it safe to override the GlobalConfiguration? What if JBoss AS use >>> infinispan to run? >> >> This name is used to distinguish cluster used by HSearch - All nodes with >> the same name form a group. Yes, rather "Hibernate Search cluster" is better >> name. It is safe to modify GlobalConfiguration, there can be set up >> configuration for CacheManager like communication way (JGroups or something >> else), stack configuration for JGroups, etc.; where Configuration is used to >> configure specific cache. I think just the infinispan cluster name on JBoss >> AS have to be different from HSearch, then they will be independent. >> >>> >>> Why the use of DummyTransactionManagerLookup. Doesn't Infinispan guess >>> the right TM depending on the environment? e in JBoss As use the JBoss one >>> etc? I think GenericTransactionManagerLookup does that. >> >> Yes right, I was testing it with DummyTM and forgot to change it later. >> >>> >>> InfinispanCacheManagerConfiguration >>> some javadoc on the methods would be useful. I don't know what do >>> implement here. >>> >>> Is there a better name for Metadata? Like FileMetadata maybe? >> >> Better FileMetadata or maybe FileHeader. >>> >>> Where is ispn-cache-default-conf.xml used? For tests only? If not: is it >>> possible to use a programmatic version instead and what is "It's a movie >>> cache"? >> >> Yes in tests only so far. However it can be used as a provided default >> configuration. I will send maybe question to infinispan group about best >> configuration parameters. "It's a movie cache" it's the name for cache >> configured in ispn-cache-default-conf.xml. In tests in this cache are stored >> indexes for entity Movie. Indexes for all other entities are stored in >> default HSInfinispanCache. >>> >>> Emmanuel >>> >>> >>> Begin forwarded message: >>> >>> From: Łukasz Moreń <lukasz.moren(a)gmail.com&gt; >>> Date: 21 août 2009 02:11:03 HAEC >>> To: Emmanuel Bernard <emmanuel(a)hibernate.org&gt; >>> Subject: GSoC patch with Infinispan Directory Provider >>> I'm sending patch and piece of documentation - not much but necessary >>> information are included. >>> There are some todos but I didn't manage to finish it yet. >>> I changed maven jgroups dependency to 2.8.beta2, before version was >>> clashed with used by infinispan. >>> In pom file there was dependency on hibernate common annotations >>> 3.2.shapshot. It should't be 3.5? >>> Cheers, >>> Lukasz >>> >>> >>> >> >> <GSoC2009_summary.pdf>_______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> -- >> Manik Surtani >> manik(a)jboss.org >> Lead, Infinispan >> Lead, JBoss Cache >> http://www.infinispan.org >> http://www.jbosscache.org >> >> >> > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev >