[infinispan-dev] (Not-so-)optional cachestores

[Tristan Tarrant]

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