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

[Sanne Grinovero]

On 20 August 2014 16:36, Dan Berindei <dan.berindei at gmail.com> wrote:
>
>
> 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.

Yes that's exactly my point: I want to be able to share a pool I
already have with a CacheManager instance I'm creating.


>> >> 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
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev