Ok, thanks for advice. I think it has as each DP has an access to SearchFactoryImplementor <br><br><div class="gmail_quote">2009/8/20 Emmanuel Bernard <span dir="ltr"><<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div bgcolor="#FFFFFF"><div class="im"><div><br><br>On 20 août 2009, at 13:25, Łukasz Moreń <<a href="mailto:lukasz.moren@gmail.com" target="_blank">lukasz.moren@gmail.com</a>> wrote:<br>
<br></div><div></div><blockquote type="cite"><div>Yes, that's right, and also CM can close all its caches. <div>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.</div>
</div></blockquote><div><br></div></div><div>I don't want that. That would be pure pollution :)</div><div class="im"><br><blockquote type="cite"><div><div>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.</div>
</div></blockquote><div><br></div></div><div>That's one way. Try and explore that by having a specific interface for dir providers that expose CMs</div><div><br></div><div>I am not sure though that a dp has access to other dps</div>
<div><div></div><div class="h5"><br><blockquote type="cite"><div><div> </div>
<div><br><div class="gmail_quote">2009/8/20 Emmanuel Bernard <span dir="ltr"><<a href="mailto:emmanuel@hibernate.org" target="_blank"></a><a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF"><div>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<div><div></div><div><br><br>On 20 août 2009, at 11:08, Łukasz Moreń <<a href="mailto:lukasz.moren@gmail.com" target="_blank"></a><a href="mailto:lukasz.moren@gmail.com" target="_blank">lukasz.moren@gmail.com</a>> wrote:<br>
<br></div></div></div><div><div></div><div><div></div><blockquote type="cite"><div>Hmm, I have to think more about that. Caches close when DirectoryProvider stops, so CM could be also.<br><br><div class="gmail_quote">
2009/8/20 Emmanuel Bernard <span dir="ltr"><<a href="mailto:emmanuel@hibernate.org" target="_blank"></a><a href="mailto:emmanuel@hibernate.org" target="_blank"></a><a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">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).<div>
Plus Caches and CacheManager don't have to be closed? They might need to be tied to the HSearch lifecycle or something.<div><div></div><div><br><div><br><div><div>On 20 août 09, at 09:18, Łukasz Moreń wrote:</div>
<br><blockquote type="cite"><br><br><div class="gmail_quote">2009/8/20 Emmanuel Bernard <span dir="ltr"><<a href="mailto:emmanuel@hibernate.org" target="_blank"></a><a href="mailto:emmanuel@hibernate.org" target="_blank"></a><a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><br><div><div><div>On 18 août 09, at 17:35, Łukasz Moreń wrote:</div><br><blockquote type="cite">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.<div>
The better idea I think is to share one CacheManager between all directories in node.</div></blockquote><div><br></div></div><div>OK</div><div><br><blockquote type="cite"><div> Then shared are also caches objects locally - not like previously every time is created new one. </div>
</blockquote><div><br></div></div><div>I don't understand that sentence, can you detail a bit further.</div></div></div></blockquote><div><br></div><div><br></div><div><div>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.</div>
<div>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:).</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div></div><div><br><blockquote type="cite"><div>HSearch started twice, independently, that both instances don't share resources - directories.? E.g. every time with different configuration? </div>
</blockquote><div><br></div></div><div>Yes, if you start HSearch twice, they should be totally independent (ie not share resources like CacheManager etc.</div><div><br><blockquote type="cite"> <div>To achieve that can be either created new CacheManager every HS start, or used one, but with different cache names per app.</div>
</blockquote><div><br></div></div><div>I like one CM per HS start but how do you think you can achieve that?</div></div></div></blockquote><div><br></div><div>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.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div style="word-wrap:break-word"><div><div></div><div><div></div><div><div><br></div><blockquote type="cite"><div> </div>
<div><br></div><div><div class="gmail_quote">2009/8/14 Emmanuel Bernard <span dir="ltr"><<a href="mailto:emmanuel@hibernate.org" target="_blank"></a><a href="mailto:emmanuel@hibernate.org" target="_blank"></a><a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">How do you share the cache between different directories? <div>A static field would not work well as it would prevent HSearch to be started twice in a single app.</div> <div><br></div><div>
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.</div>
<div><div></div><div><div><br><div><div>On 14 août 09, at 05:33, Łukasz Moreń wrote:</div><br><blockquote type="cite">There is one cache for all indexes. In this case scoping configuration will be hard.<div>Yes, some default config will be provided. Right, different propterties for xml and programmatic would be better.</div>
<div><br><div class="gmail_quote"> 2009/8/14 Emmanuel Bernard <span dir="ltr"><<a href="mailto:emmanuel@hibernate.org" target="_blank"></a><a href="mailto:emmanuel@hibernate.org" target="_blank"></a><a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Question,<br> Do we have one cache for all indexes (directories) or one per directory?<br> <br> I feels wrong to see this configuration not scoped per index<br> hibernate.search.default.directory_provider blah.blah.InfinispanDirectoryProvider<br>
hibernate.search.default.infinispan_conf com.acme.CacheFactoryImpl<br> <br> hibernate.search.Address.directory_provider blah.blah.InfinispanDirectoryProvider<br> hibernate.search.Address.infinispan_conf conf.xml<br> <br>
hibernate.search.User.directory_provider blah.blah.InfinispanDirectoryProvider<br> hibernate.search.User.infinispan_conf auto<br> <br> 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.<br>
<font color="#888888"> <br> Emmanuel</font><div><div></div><div><br> <br> On 13 août 09, at 18:33, Łukasz Moreń wrote:<br> <br> </div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div></div><div> I was thinking that maybe we can expose full conf options. Infinispan supports programmatical and xml ways to configure cache.<br> 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.<br>
<br> Something like that:<br> <br> <property name="hibernate.search.infinispan.conf" value="org.hibernate.search.store.infinispan.CacheFactoryImpl" /><br> <br> and for xml<br> <br> <property name="hibernate.search.infinispan.conf" value="xml-conf.xml" /><br>
<br> <br> 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.<br>
<br> Cheers,<br> Lukasz Moren<br></div></div><div> _______________________________________________<br> hibernate-dev mailing list<br> <a href="mailto:hibernate-dev@lists.jboss.org" target="_blank"></a><a href="mailto:hibernate-dev@lists.jboss.org" target="_blank"></a><a href="mailto:hibernate-dev@lists.jboss.org" target="_blank">hibernate-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/hibernate-dev" target="_blank"></a><a href="https://lists.jboss.org/mailman/listinfo/hibernate-dev" target="_blank"></a><a href="https://lists.jboss.org/mailman/listinfo/hibernate-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/hibernate-dev</a><br>
</div></blockquote> <br> </blockquote></div><br></div></blockquote></div><br>
</div></div></div></div></blockquote></div><br></div></blockquote></div></div></div><br></div></blockquote></div><br></blockquote></div><br></div></div></div></div></div></blockquote></div><br>
</div></blockquote></div></div></div></blockquote></div><br></div>
</div></blockquote></div></div></div></blockquote></div><br>