2:29 p.m.
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
3:39 p.m.
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
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
3:42 p.m.
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
4:01 p.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
9:17 a.m.
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(a)redhat.com
<mailto:ttarrant@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(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
4:46 p.m.
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(a)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(a)redhat.com
> <mailto:ttarrant@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(a)lists.jboss.org <mailto:
infinispan-dev(a)lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
4:50 p.m.
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(a)redhat.com
<mailto:ttarrant@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(a)redhat.com
<mailto:ttarrant@redhat.com>
> <mailto:ttarrant@redhat.com <mailto:ttarrant@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(a)lists.jboss.org
<mailto:infinispan-dev@lists.jboss.org>
<mailto:infinispan-dev@lists.jboss.org
<mailto:infinispan-dev@lists.jboss.org>>
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
<mailto:infinispan-dev@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(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
3063
days inactive
3064
days old
infinispan-dev@lists.jboss.org
6 comments
3 participants
participants (3)
-
Radim Vansa -
Sebastian Laskawiec -
Tristan Tarrant