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 <[email protected]> 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 <[email protected] > > <mailto:[email protected]>> 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 > > [email protected] <mailto: > [email protected]> > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > > > > > > > _______________________________________________ > > infinispan-dev mailing list > > [email protected] > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > -- > Tristan Tarrant > Infinispan Lead > JBoss, a division of Red Hat > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev >
_______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
