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

[Dan Berindei]

On Wed, Aug 20, 2014 at 2:32 PM, Sanne Grinovero <sanne at infinispan.org>
wrote:

> On 20 August 2014 11:19, Dan Berindei <dan.berindei at gmail.com> wrote:
> >
> >
> >
> > On Wed, Aug 20, 2014 at 1:08 PM, Sanne Grinovero <sanne at infinispan.org>
> > wrote:
> >>
> >> On 12 August 2014 21:41, Dan Berindei <dan.berindei at gmail.com> wrote:
> >> >
> >> >
> >> >
> >> > On Tue, Aug 5, 2014 at 11:27 AM, Galder Zamarreño <galder at redhat.com>
> >> > 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20140820/8a111bab/attachment.html