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

[Sanne Grinovero]

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).
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.

Cheers