Re: [infinispan-dev] minutes from the monitoring&management meeting

On Wed, Aug 20, 2014 at 2:32 PM, Sanne Grinovero <sanne(a)infinispan.org&gt; wrote: > > On 20 August 2014 11:19, Dan Berindei <dan.berindei(a)gmail.com&gt; wrote: > > > > > > > > On Wed, Aug 20, 2014 at 1:08 PM, Sanne Grinovero <sanne(a)infinispan.org&gt; > > wrote: > >> > >> On 12 August 2014 21:41, Dan Berindei <dan.berindei(a)gmail.com&gt; wrote: > >> > > >> > > >> > > >> > On Tue, Aug 5, 2014 at 11:27 AM, Galder Zamarreño <galder(a)redhat.com&gt; > >> > wrote: > >> >> > >> >> Can’t comment on the document, so here are my thoughts: > >> >> > >> >> Re: “Get rid of lazy cache starting...all the caches run on all > >> >> nodes...it > >> >> should still be possible to start a cache at runtime, but it will be > >> >> run on > >> >> all nodes as well” > >> >> > >> >> ^ Though I like the idea, it might change a crucial aspect of how > >> >> default > >> >> cache configuration works (if we leave the concept of default cache > >> >> at > >> >> all). > >> >> Say you start a cache named “a” for which there’s no config. Up > >> >> until > >> >> now > >> >> we’d use the default cache configuration and create a cache “a” with > >> >> that > >> >> config. However, if caches are started cluster wide now, before you > >> >> can > >> >> do > >> >> that, you’d have to check that there’s no cache “a” configuration > >> >> anywhere > >> >> in the cluster. If there is, I guess the configuration would be > >> >> shipped > >> >> to > >> >> the node that starts the cache (if it does not have it) and create > >> >> the > >> >> cache > >> >> with it? Or are you assuming all nodes in the cluster must have all > >> >> configurations defined? > >> > > >> > > >> > +1 to remove the default cache as a default configuration. > >> > > >> > I like the idea of shipping the cache configuration to all the nodes. > >> > We > >> > will have to require any user-provided objects in the configuration > >> > to > >> > be > >> > serializable/externalizable, but I don't see a big problem with that. > >> > >> That would be nice but needs some care, say for example that I want to > >> inject a custom JDBCCacheStore by instance which has a reference to a > >> datasource (Extremely useful use case). > > > > > > Shouldn't the datasource be registered in JNDI anyway? If yes, you could > > serialize the JNDI name. > > You don't want to require the user to need to match configuration > settings in different configuration files of what he considers one > platform. > And we support many more options beyond JNDI. > Still, usually we want to share datasources for pooling, so the cache store should look up its datasource somewhere instead of creating a new connection pool for each cache.

> >> I could make it serializable by changing it from a CacheStore instance > >> to some kind of "CacheStoreLookupStrategy" but you'd need to give me > >> some hook we can react on to restore the references. Once again (as > >> asked previously) allowing to register custom components by instance > >> in the CacheManager's component Registry would solve this. > >> > > > > We already allow this: > > > > > > EmbeddedCacheManager.getGlobalComponentRegistry().registerComponent(instance, > > name) > > Can I use that before the CacheManager is started? Sure, all DefaultCacheManager.start() does is register some MBeans in JMX. > > > -- Sanne > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev