[
https://issues.apache.org/jira/browse/JAMES-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier updated JAMES-4177:
----------------------------------
Description:
h3. Why ?
As a Cassandra operator I want more control on the consistency levels
EG:
- I want globally to write at QUORUM but for my reads I do want to operate at
LOCAL_ONE
The idea: we offer a way for the operator to trade small window of
inconsistency for more performance without compromising correctness (Not
loosing non replicated writes).
Also I want to be able to do this on a per collection matter - eg reading
domains at LOCAL_ONE is trivially ok, so I'd want to be able to squeeze the
extra perf out of it.
h3. How?
In cassandra-diver.conf define the read + write profiles defaulting to QUORUM
Each DAO would propose 2 extra profiles, read-name-of-the-dao and
write-name-of-the-dao, and if undefined in the conf fallback to read / write
profile. Done in the DAO constructor:
{code:java}
public String resolveProfile(CqlSession session, String profileName, String
fallback) {
Map<String, DriverExecutionProfile> profiles =
session.getContext()
.getConfig()
.getProfiles();
return profiles.containsKey(profileName) ? profileName : fallback;
}
{code}
We would supply in the conf a full list of supported profiles.
was:
h3. Why ?
As a Cassandra operator I want more control on the consistency levels
EG:
- I want globally to write at QUORUM but for my reads I do want to operate at
LOCAL_ONE
The idea: we offer a way for the operator to trade small window of
inconsistency for more performance without compromising correctness (Not
loosing non replicated writes).
Also I want to be able to do this on a per collection matter - eg reading
domains at LOCAL_ONE is trivially ok, so I'd want to be able to squeeze the
extra perf out of it.
h3. How?
In cassandra-diver.conf define the read + write profiles defaulting to QUORUM
Each DAO would propose 2 extra profiles, read-name-of-the-dto and
write-name-of-the-dto, and if undefined in the conf fallback to read / write
profile. Done in the DAO constructor:
{code:java}
public String resolveProfile(CqlSession session, String profileName, String
fallback) {
Map<String, DriverExecutionProfile> profiles =
session.getContext()
.getConfig()
.getProfiles();
return profiles.containsKey(profileName) ? profileName : fallback;
}
{code}
We would supply in the conf a full list of supported profiles.
> Finner grain Cassandra profiles
> -------------------------------
>
> Key: JAMES-4177
> URL: https://issues.apache.org/jira/browse/JAMES-4177
> Project: James Server
> Issue Type: Improvement
> Reporter: Benoit Tellier
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Why ?
> As a Cassandra operator I want more control on the consistency levels
> EG:
> - I want globally to write at QUORUM but for my reads I do want to operate
> at LOCAL_ONE
> The idea: we offer a way for the operator to trade small window of
> inconsistency for more performance without compromising correctness (Not
> loosing non replicated writes).
> Also I want to be able to do this on a per collection matter - eg reading
> domains at LOCAL_ONE is trivially ok, so I'd want to be able to squeeze the
> extra perf out of it.
> h3. How?
> In cassandra-diver.conf define the read + write profiles defaulting to QUORUM
> Each DAO would propose 2 extra profiles, read-name-of-the-dao and
> write-name-of-the-dao, and if undefined in the conf fallback to read / write
> profile. Done in the DAO constructor:
> {code:java}
> public String resolveProfile(CqlSession session, String profileName, String
> fallback) {
> Map<String, DriverExecutionProfile> profiles =
> session.getContext()
> .getConfig()
> .getProfiles();
> return profiles.containsKey(profileName) ? profileName : fallback;
> }
> {code}
> We would supply in the conf a full list of supported profiles.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
