[OP-84] Ensure that data inserted into cassandra expire Created: 16/Sep/14  Updated: 17/Oct/14  Resolved: 03/Oct/14

Status: Closed
Project: Opush
Component/s: None
Affects Version/s: 3.0.1
Fix Version/s: 3.0.2

Type: Improvement Priority: Normal
Reporter: Thomas HILAIRE Assignee: Thomas HILAIRE
Resolution: Fixed Votes: 0
Labels: 201409, GN
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relates to OP-103 DB Size and opush size Closed
Rank: 6410
Sprint: Sprint


Current behavior:
When opush insert data into the cassandra cluster, this data will never expire.

Expected behavior:
When opush insert data into the cassandra cluster, this data will expire automatically in 30 days.

Comment by Thomas HILAIRE [ 03/Oct/14 ]


  • CRASH: connection
  • CRASH: first schema installation
  • CRASH: schema updates
  • OPUSH: none if the server migrates and restart as expected

Data should expire themself about 30 days, as you won't wait 30 days you can verify with a Cassandra request that data have a TTL after the migration.


For exemple, run this query using cqlsh :

select ttl(analysed_sync_collection) from opush.synced_collection_v2 ;

- before the migration the "ttle" value of columns should be null or 0 for every tables.

- after the migration the "ttle" value of columns should be something like 30 days (in seconds) for every tables.


Every table must have a default TTL at 30 days:

DESCRIBE TABLE opush.snapshot;
CREATE TABLE snapshot (
  id uuid,
  snapshot text,
  PRIMARY KEY ((id))
  bloom_filter_fp_chance=0.010000 AND
  default_time_to_live=XXX AND
Comment by Stephane COLSON [ 10/Oct/14 ]

OK with version 3.0.2~beta3~git20141009.091827.60ca887-1

Comment by Jenkins Continuous Integration Server [ 17/Oct/14 ]

SUCCESS: Integrated in opush-master #156
OP-84 Migration always retry read and write (thilaire: 692cc753bb841b46deb91120534f2ccfe0057b7a)

  • push-dao-cassandra/src/main/java/org/obm/push/cassandra/migration/coded/V2ToV3_TTL.java
Generated at Tue Oct 27 13:17:24 CET 2020 using JIRA 6.1.1#6155-sha1:7188aeec9a6b57d61ea04c52f235f15f55c105e2.