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