[ 
https://issues.apache.org/jira/browse/CASSANDRA-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13467924#comment-13467924
 ] 

Mauri Melato commented on CASSANDRA-4741:
-----------------------------------------

Changed {{cassandra.yaml}} to use
{code}
commitlog_sync: batch
commitlog_sync_batch_window_in_ms: 50
{code}
instead of periodic sync and the problem still persists
                
> Cassandra stops persisting data on 32 bit windows
> -------------------------------------------------
>
>                 Key: CASSANDRA-4741
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4741
>             Project: Cassandra
>          Issue Type: Bug
>         Environment: Windows XP 32 bit
> Cassandra 1.1.4 or 1.1.5
>            Reporter: Mauri Melato
>             Fix For: 1.1.4, 1.1.5
>
>         Attachments: cassandra-data.minimal.zip
>
>
> Hello,
>  
>  we have a Cassandra instance running on a single node with Windows XP 32bit.
> After some time of normal working and some restart, Cassandra seems to stop 
> to persist data into the keyspace without raising any error.
> It's possible to update/insert rows or columns and you can query and see the 
> updated keyspace but if you stop and start Cassandra, you get a keyspace 
> 'from the past', always from the same point in the past.
> We were not able to understand how to trigger this inconsistency in the first 
> place but once you get it, you can't get rid of it if not removing the data 
> directories.
> Here in attachment you can find a complete set of Cassandra data directories: 
> {code}
>    cassandra-data/
>    |-- commitlog
>    |-- data
>    `-- saved_caches
> {code}
> with which it's possible test the inconsistent scenario. 
> We tried this on another clean Win Xp 32 machine and we could get the same 
> issue from the first run.
> On a Win XP 64 and the same dir set, Cassandra didn't get into this issue, 
> but from the log we saw a difference in the disk access mode:
> * XP/64: {{DiskAccessMode 'auto' determined to be mmap, indexAccessMode is 
> mmap" instead of 'standard'}}
> * XP/32: {{DiskAccessMode 'auto' determined to be standard, indexAccessMode 
> is standard}}
> Not sure this is the key factor, nevertheless in another test bed we 
> experimented the same issue even on a WinXP 64 node but we couldn't collect 
> the dataset.
> Here a short cassandra-cli history to show the issue:
> {code}
> [default@NEUTRO_Keyspace] connect 192.168.1.33/9160;
> Connected to: "NEUTRO Cluster" on 192.168.1.33/9160
> [default@unknown] use neutro_keyspace;
> Authenticated to keyspace: NEUTRO_Keyspace
> [default@NEUTRO_Keyspace] describe;
> Keyspace: NEUTRO_Keyspace:
>   Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
>   Durable Writes: true
>     Options: [replication_factor:1]
>   Column Families:
>     ColumnFamily: TaskId
>       Key Validation Class: org.apache.cassandra.db.marshal.AsciiType
>       Default column value validator: org.apache.cassandra.db.marshal.UTF8Type
>       Columns sorted by: org.apache.cassandra.db.marshal.AsciiType
>       GC grace seconds: 864000
>       Compaction min/max thresholds: 4/32
>       Read repair chance: 1.0
>       DC Local Read repair chance: 0.0
>       Replicate on write: true
>       Caching: KEYS_ONLY
>       Bloom Filter FP chance: default
>       Built indexes: []
>       Column Metadata:
>         Column Name: taskId
>           Validation Class: org.apache.cassandra.db.marshal.LongType
>       Compaction Strategy: 
> org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy
>       Compression Options:
>         sstable_compression: org.apache.cassandra.io.compress.SnappyCompressor
> [default@NEUTRO_Keyspace] list TaskId;
> Using default limit of 100
> Using default column limit of 100
> -------------------
> RowKey: NE_MASTER_TASK_ID
> => (column=taskId, value=47, timestamp=1349090424494000)
> 1 Row Returned.
> Elapsed time: 93 msec(s).
> [default@NEUTRO_Keyspace] set  taskid['NE_MASTER_TASK_ID']['taskId']='55';
> Value inserted.
> Elapsed time: 31 msec(s).
> [default@NEUTRO_Keyspace] list TaskId;
> Using default limit of 100
> Using default column limit of 100
> -------------------
> RowKey: NE_MASTER_TASK_ID
> => (column=taskId, value=55, timestamp=1349108488164000)
> 1 Row Returned.
> Elapsed time: 31 msec(s).
> {code}
> ...Stop and Start Cassandra...
> {code}
> [default@NEUTRO_Keyspace] connect 192.168.1.33/9160;
> Connected to: "NEUTRO Cluster" on 192.168.1.33/9160
> [default@unknown] use neutro_keyspace;
> Authenticated to keyspace: NEUTRO_Keyspace
> [default@NEUTRO_Keyspace] list TaskId;
> Using default limit of 100
> Using default column limit of 100
> -------------------
> RowKey: NE_MASTER_TASK_ID
> => (column=taskId, value=47, timestamp=1349090424494000)
> 1 Row Returned.
> Elapsed time: 110 msec(s).
> {code}
> Thanks for your attention

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to