[infinispan-dev] (Not-so-)optional cachestores
Sebastian Laskawiec
slaskawi at redhat.com
Tue Jan 26 10:46:18 EST 2016
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>
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>> 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>
> > 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
> _______________________________________________
> 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/20160126/f6cc7585/attachment.html
More information about the infinispan-dev
mailing list