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

[Sanne Grinovero]

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.


>> 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?

-- Sanne