[infinispan-dev] (Not-so-)optional cachestores
Tristan Tarrant
ttarrant at redhat.com
Tue Jan 26 10:50:30 EST 2016
Actually, after our IRC dicussions, I've come to think that
marshallers/filters/converters are different from a cachestore because
they don't need to be configured, so not sure how far we should take it.
Tristan
On 26/01/2016 16:46, Sebastian Laskawiec wrote:
> Thanks for the explanation Tristan! Great example!
>
> Following our discussion on IRC - would it make sense to make this
> refactoring a bit broader and take Marshallers/Filter/Converters into
> consideration (we don't need to implement everything in a single step...
> just get the big pictures how all those pieces combine together)?
>
> On Tue, Jan 26, 2016 at 9:17 AM, Tristan Tarrant <ttarrant at redhat.com
> <mailto:ttarrant at redhat.com>> wrote:
>
> So let's see what an implementation of #4 would entail:
>
>
> A mini-subsystem per cache-store which can parse the following:
>
> <subsystem xmlns="urn:infinispan:server:cachestore:cassandra:8.2">
> <cassandra-store name="mycassandrastore"
> auto-create-keyspace="true" keyspace="TestKeyspace"
> entry-table="TestEntryTable"
> consistency-level="LOCAL_ONE"
> serial-consistency-level="SERIAL">
> <cassandra-server host="127.0.0.1" port="9042" />
> <cassandra-server host="127.0.0.1" port="9041" />
> <connection-pool heartbeat-interval-seconds="30"
> idle-timeout-seconds="120"
> pool-timeout-millis="5" />
> </cassandra-store>
> </subsystem>
>
> The subsystem would be responsible for parsing the configuration and
> registering an appropriate StoreConfigurationBuilder under a named
> Service within the server. We need to be careful about class loader
> visibility, but the datasource subsystem does something similar, so it
> should be possible.
>
> The main Infinispan subsystem would need to be extended to be able to
> parse the following (simplified):
>
> <subsystem xmlns="urn:infinispan:server:core:8.2">
> <cache-container name="clustered">
> <distributed-cache name="default">
> <store ref="infinispan/cachestore/cassandra/mycassandrastore"
> passivation="true" fetch-state="true" preload="true"
> purge="false" />
> </distributed-cache>
> </cache-container>
> </subsystem>
>
> It would also not be difficult, for symmetry, to support a compatible
> schema for the embedded use-case.
>
> The cachestores would be distributed both as a simple jar for embedded
> use-cases and as a zip containing the necessary modules for server.
> Note that this would not leverage the deployable cachestores machinery
> as subsystems need to be installed as modules.
>
> Tristan
>
>
> On 25/01/2016 16:01, Sebastian Laskawiec wrote:
> > Is it possible to have #3 and use a dedicated configuration schema per
> > Cache Store? Otherwise the only way to configure a Cache Store it to use
> > properties (key/value pairs).
> >
> > If it's not possible to have a custom configuration schema - I would
> > vote for #4.
> >
> > On Mon, Jan 25, 2016 at 3:42 PM, Tristan Tarrant <ttarrant at redhat.com <mailto:ttarrant at redhat.com>
> > <mailto:ttarrant at redhat.com <mailto:ttarrant at redhat.com>>> wrote:
> >
> > Yes, that would be nice.
> >
> > I found another "cons" for #4: an embedded config would not
> translate
> > 1:1 to server. Well, it doesn't translate directly now
> either, but at
> > least it's "closer".
> >
> > Tristan
> >
> > On 25/01/2016 15:39, Radim Vansa wrote:
> > > Would the deployable cache stores benefit from 4) as well? It
> > seems to
> > > me as the only 'right' option.
> > >
> > > R.
> > >
> > > On 01/25/2016 02:29 PM, Tristan Tarrant wrote:
> > >> Hi all,
> > >>
> > >> Jakub has recently revived the Cassandra Cache Store (CCS
> from
> > now on)
> > >> which, as you all will remember, was pushed to an external
> > repository
> > >> where it lay in abandonment ever since.
> > >>
> > >> We now need to add support for this store to Infinispan
> Server, but
> > >> unfortunately, because of the "monolithic schema"
> approach that
> > WildFly
> > >> imposes on subsystems, this has to be done within the
> Infinispan
> > >> subsystem itself.
> > >> This creates a conundrum, since the CCS depends on
> Infinispan core,
> > >> server would depend on the CCS but server is part of the
> > Infinispan build.
> > >>
> > >> Possible solutions:
> > >> 1) move the CCS back into the main repo
> > >> - pros: no more conundrum, built by default, easier to
> > maintain
> > >> - cons: makes the repo even bigger, binds the
> lifecycle of
> > the CCS
> > >> to Infinispan's
> > >> 2) extend the server to be able to interpret the CCS
> schema but not
> > >> actually depend on its code and provide the code to
> instantiate
> > the CCS
> > >> as an overlay module which can be installed on server
> > >> - pros: keeps the lifecycle of the CCS independent
> > >> - cons: additional complexity to handle the split,
> forces
> > us to
> > >> still keep server aligned with schema changes in the CCS
> itself.
> > >> 3) make the CCS a deployable cache store
> > >> - pros: easiest
> > >> - cons: not really ootb experience, no nice schema
> > >> 4) create a dedicated subsystem for the CCS and "invent"
> a way to
> > >> reference it from the main Infinispan subsystem using a
> naming
> > >> convention, similar to how datasources are currently
> implemented.
> > >> - pros: keeps the two projects independent,
> reusable for other
> > >> Cachestores
> > >> - cons: writing a subsystem from scratch is complex
> > (although bits
> > >> of it could be made reusable for multiple cachestores).
> > >>
> > >> Your thoughts please.
> > >>
> > >> Tristan
> > >
> > >
> >
> > --
> > Tristan Tarrant
> > Infinispan Lead
> > JBoss, a division of Red Hat
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> <mailto:infinispan-dev at lists.jboss.org>
> <mailto:infinispan-dev at lists.jboss.org
> <mailto:infinispan-dev at lists.jboss.org>>
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> >
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> <mailto:infinispan-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org <mailto: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
>
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
More information about the infinispan-dev
mailing list