Consult cassandra.properties to get some examples and hints.
# Read com.datastax.driver.core.PoolingOptions for knowing defaults value # No value here will default to driver's default value # cassandra.pooling.local.max.connections=8 # cassandra.pooling.local.max.requests=128 ## In ms. Should be higher than socket read timeout # cassandra.pooling.timeout=5000 ## In seconds. # cassandra.pooling.heartbeat.timeout=30 # cassandra.pooling.max.queue.size=256
If you want more explanation about Cassandra configuration, you should visit the dedicated documentation.
Cassandra upgrades implies the creation of a new table. Thus restarting James is needed, as new tables are created on restart.
Once done, we ship code that tries to read from new tables, and if not possible backs up to old tables. You can thus safely run without running additional migrations.
On the fly migration can be enabled. However, one might want to force the migration in a controlled fashion, and update automatically current schema version used (assess in the database old versions is no more used, as the corresponding tables are empty). Note that this process is safe: we ensure the service is not running concurrently on this James instance, that it does not bump version upon partial failures, that race condition in version upgrades will be idempotent, etc...
These schema updates can be triggered by webadmin using the Cassandra backend.
Note that currently the progress can be tracked by logs.
Here are the implemented migrations:Last support on releases 3.5.0
Migration tag on git repository: cassandra_migration_v1_to_v2
Goal is to create a messageV2 table that aims at replacing message table. Message table is both storing message metadata and blobs. It have been proven inefficient. Instead version 2 is chunking message blobs and storing it in an other table. The migration process involves moving all messages from message table to messageV2 table (contains only metadata) and blobs / blobParts tables.
Read more about this migration here.
Summary of available options for this migration:
Last support on releases 3.5.0
Migration tag on git repository: cassandra_migration_v2_to_v3
Goal is to drop message table. After this migration, one can manually delete this table.
Last support on releases 3.5.0
Migration tag on git repository: cassandra_migration_v3_to_v4
Goal is to store attachments in the blob tables.
Summary of available options for this migration:
Last support on releases 3.5.0
Migration tag on git repository: cassandra_migration_v4_to_v5
Goal is to store attachment ids in the separated AttachmentMessageId table.
Summary of available options for this migration:
Last support on releases 3.6.x
Goal is to no longer rely on an UDT partition key for mailboxPath tables. Entries will be migrated to mailboxPathV2 table relying on a composite primary key
Last support on releases 3.6.x
Goal is to populate mapping_sources projection table. This table allows finding the source of a given redirection, which is handy for things like mail aliases (I want to list aliases rewritting things to bob). Without this projection table being available, (ie we rely on schema version 6 or less) such information is obtained through a full table scan, unoptimized. From schema version 7, the optimized projection can safely be used.
Last support on releases 3.6.x
Add UID_VALIDITY to mailboxPath table in order not to mandate mailbox table reads.
Adopt a more compact representation for message properties.
Handles Mailbox ACL transactionality with event-sourcing. We got read of SERIAL consistency upon reads thus unlocking a major performance enhancement.
Add threadId column to messageIdTable and imapUidTable in order to get a message's threadId.