Re: Out of memory issues
Hi, thanks for the answer. There were no large insertions and the saved_caches dir had a resonable size. I tried to delete the cashes and set key_cache_size_in_mb to zero, but it didn't help. Today our virtual hardware provided raised cpus to 4, memory to 32GB and doubled the disk size, and the nodes are stable again. So it was probably an issue of severe lack of resources. About HEAP_NEWSIZE, your suggestion is quite intriguing. I thought it was better to set it 100mb*#cores, so in my case I set it to 200 and now I should set it to 400. Do larger values help without being harmful? Regards, Paolo Il 27/05/2016 03:05, Mike Yeap ha scritto: Hi Paolo, a) was there any large insertion done? b) are the a lot of files in the saved_caches directory? c) would you consider to increase the HEAP_NEWSIZE to, say, 1200M? Regards, Mike Yeap On Fri, May 27, 2016 at 12:39 AM, Paolo Crosato <paolo.cros...@targaubiest.com <mailto:paolo.cros...@targaubiest.com>> wrote: Hi, we are running a cluster of 4 nodes, each one has the same sizing: 2 cores, 16G ram and 1TB of disk space. On every node we are running cassandra 2.0.17, oracle java version "1.7.0_45", centos 6 with this kernel version 2.6.32-431.17.1.el6.x86_64 Two nodes are running just fine, the other two have started to go OOM at every start. This is the error we get: INFO [ScheduledTasks:1] 2016-05-26 18:15:58,460 StatusLogger.java (line 70) ReadRepairStage 0 0 116 0 0 INFO [ScheduledTasks:1] 2016-05-26 18:15:58,462 StatusLogger.java (line 70) MutationStage31 1369 20526 0 0 INFO [ScheduledTasks:1] 2016-05-26 18:15:58,590 StatusLogger.java (line 70) ReplicateOnWriteStage 0 0 0 0 0 INFO [ScheduledTasks:1] 2016-05-26 18:15:58,591 StatusLogger.java (line 70) GossipStage 0 0 335 0 0 INFO [ScheduledTasks:1] 2016-05-26 18:16:04,195 StatusLogger.java (line 70) CacheCleanupExecutor 0 0 0 0 0 INFO [ScheduledTasks:1] 2016-05-26 18:16:06,526 StatusLogger.java (line 70) MigrationStage0 0 0 0 0 INFO [ScheduledTasks:1] 2016-05-26 18:16:06,527 StatusLogger.java (line 70) MemoryMeter 1 4 26 0 0 INFO [ScheduledTasks:1] 2016-05-26 18:16:06,527 StatusLogger.java (line 70) ValidationExecutor0 0 0 0 0 DEBUG [MessagingService-Outgoing-/10.255.235.19 <http://10.255.235.19>] 2016-05-26 18:16:06,518 OutboundTcpConnection.java (line 290) attempting to connect to /10.255.235.19 <http://10.255.235.19> INFO [GossipTasks:1] 2016-05-26 18:16:22,912 Gossiper.java (line 992) InetAddress /10.255.235.28 <http://10.255.235.28> is now DOWN INFO [ScheduledTasks:1] 2016-05-26 18:16:22,952 StatusLogger.java (line 70) FlushWriter 1 5 47 025 INFO [ScheduledTasks:1] 2016-05-26 18:16:22,953 StatusLogger.java (line 70) InternalResponseStage 0 0 0 0 0 ERROR [ReadStage:27] 2016-05-26 18:16:29,250 CassandraDaemon.java (line 258) Exception in thread Thread[ReadStage:27,5,main] java.lang.OutOfMemoryError: Java heap space at org.apache.cassandra.io.util.RandomAccessReader.readBytes(RandomAccessReader.java:347) at org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:392) at org.apache.cassandra.utils.ByteBufferUtil.readWithLength(ByteBufferUtil.java:355) at org.apache.cassandra.db.ColumnSerializer.deserializeColumnBody(ColumnSerializer.java:124) at org.apache.cassandra.db.OnDiskAtom$Serializer.deserializeFromSSTable(OnDiskAtom.java:85) at org.apache.cassandra.db.Column$1.computeNext(Column.java:75) at org.apache.cassandra.db.Column$1.computeNext(Column.java:64) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) at com.google.common.collect.AbstractIterator.next(AbstractIterator.java:153) at org.apache.cassandra.db.columniterator.IndexedSliceReader$IndexedBlockFetcher.getNextBlock(IndexedSliceReader.java:434) at org.apache.cassandra.db.columniterator.IndexedSliceReader$IndexedBlockFetcher.fetchMoreData(IndexedSliceReader.java:387) at org.apache.cassandra.db.columniterator.IndexedSliceReader.computeNext(IndexedSliceReader.java:145) at org.apache.cassandra.db.colum
Out of memory issues
.java:1619) at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1438) at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:340) at org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:89) at org.apache.cassandra.db.ReadVerbHandler.doVerb(ReadVerbHandler.java:47) ERROR [ReadStage:32] 2016-05-26 18:16:29,357 CassandraDaemon.java (line 258) Exception in thread Thread[ReadStage:32,5,main] java.lang.OutOfMemoryError: Java heap space at org.apache.cassandra.io.util.RandomAccessReader.readBytes(RandomAccessReader.java:347) at org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:392) at org.apache.cassandra.utils.ByteBufferUtil.readWithLength(ByteBufferUtil.java:355) at org.apache.cassandra.db.ColumnSerializer.deserializeColumnBody(ColumnSerializer.java:124) at org.apache.cassandra.db.OnDiskAtom$Serializer.deserializeFromSSTable(OnDiskAtom.java:85) at org.apache.cassandra.db.Column$1.computeNext(Column.java:75) at org.apache.cassandra.db.Column$1.computeNext(Column.java:64) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) at com.google.common.collect.AbstractIterator.next(AbstractIterator.java:153) at org.apache.cassandra.db.columniterator.IndexedSliceReader$IndexedBlockFetcher.getNextBlock(IndexedSliceReader.java:434) at org.apache.cassandra.db.columniterator.IndexedSliceReader$IndexedBlockFetcher.fetchMoreData(IndexedSliceReader.java:387) at org.apache.cassandra.db.columniterator.IndexedSliceReader.computeNext(IndexedSliceReader.java:145) at org.apache.cassandra.db.columniterator.IndexedSliceReader.computeNext(IndexedSliceReader.java:45) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) at org.apache.cassandra.db.columniterator.SSTableSliceIterator.hasNext(SSTableSliceIterator.java:82) at org.apache.cassandra.db.filter.QueryFilter$2.getNext(QueryFilter.java:157) at org.apache.cassandra.db.filter.QueryFilter$2.hasNext(QueryFilter.java:140) at org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:144) at org.apache.cassandra.utils.MergeIterator$ManyToOne.(MergeIterator.java:87) at org.apache.cassandra.utils.MergeIterator.get(MergeIterator.java:46) at org.apache.cassandra.db.filter.QueryFilter.collateColumns(QueryFilter.java:120) at org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:80) at org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:72) at org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:297) at org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:53) at org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1619) at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1438) at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:340) at org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:89) at org.apache.cassandra.db.ReadVerbHandler.doVerb(ReadVerbHandler.java:47) We are observing that the heap is never flushed, it keeps increasing until reaching the limit, then the OOM errors appear and after a short while the node crashes. These are the relevant settings in cassandra_env for one of the crashing nodes: MAX_HEAP_SIZE="6G" HEAP_NEWSIZE="200M" This is the complete error log http://pastebin.com/QGaACyhR This is cassandra_env http://pastebin.com/6SLeVmtv This is cassandra.yaml http://pastebin.com/wb1axHtV Can anyone help? Regards, Paolo Crosato -- Paolo Crosato Software engineer/Custom Solutions e-mail: paolo.cros...@targaubiest.com
CF performance suddenly degraded
Hi, I declared this CF: CREATE TABLE timesliceunitstate ( day timestamp, unitbuckets text, PRIMARY KEY (day) ); unitbuckets is a text column holding a fairly big amount of data, around 30 MB of json text per row. The table is holding 30 rows, I'm running cassandra 2.0.8 on a 3 nodes cluster with replication factor of 3, consistency of reads is quorum, so 2 out of 3 nodes. The table has a write hit about every 20 minutes, which updates only one row, the most recent. I had no problem with read queries (I query the table one row at time) until this morning, when read latency jumped from around 300ms to 20 seconds for each query. I tried repairing the table on all the 3 nodes using range repair without success, the *Data.db file on the disk is aorund 30 MB, so a bit less than 1MB for each row. I'm using latest version of datastax driver, 2.1. I changed nothing on the application level since days, so it's not something related to the applicacation or the driver. Is there anyway I can troubleshoot the issue and discover what's making the table so slow? Thanks for any advice, Paolo -- Paolo Crosato Software engineer/Custom Solutions e-mail: paolo.cros...@targaubiest.com
RE: hardware sizing for cassandra
Every node should have at least 4 cores, with a maximum of 8. Memory shouldn't be higher than 32g, 16gb is good for a start. Every node should be a phisical machine, not a virtual one, or at least a virtual machine with an ssd hd subsystem. The disk subsystem should be directly connected to the machine, no sans or fiber channel between. Cassandra is cpu and io bounded, so you should get the maximum io speed and a reasonable number of cores. Number of nodes should be 3 at least with replication factor of 2. You should prefer more less powerful nodes then fewer more powerful nodes. Disk size depends on your workload, although you should always keep 50% of the disk free in the case repair sessions requires space, or perform sub range repairs. In my experience a 1GB link between nodes is ok, but the less lag the better. Summing up if you need to save some money, get 4 cores and 16 gb or ram, 32 is rarely needed and 64 a waste. 8 cores would probably be too much with 1000 writes a second. Paolo Paolo Crosato Software engineer/Custom Solutions Da: Chris Lohfink clohf...@blackbirdit.com Inviato: martedì 9 settembre 2014 21.26 A: user@cassandra.apache.org Oggetto: Re: hardware sizing for cassandra It depends. Ultimately your load is low enough a single node can probably handle it so you kinda want a minimum cluster. Different people have different thoughts on what this means - I would recommend 5-6 nodes with a 3 replication factor. (say m1.xlarge, or c3.2xlarge striped ephemerals, I like i2's but kinda overkill here). Nodes with less then 16gb of ram wont last long so should really start around there. Chris On Sep 9, 2014, at 11:02 AM, Oleg Ruchovets oruchov...@gmail.com wrote: Hi , Where can I find the document with best practices about sizing for cassandra deployment? We have 1000 writes / reads per second. record size 1k. Questions: 1) how many machines do we need? 2) how many ram ,disc size / type? 3) What should be network? I understand that hardware is very depends on data distribution and access pattern and other criteria, but I still want to believe that there is a best practice :-) Thanks Oleg.
Re: Best practices for repair
Thank you very much, I recompiled it with 2.0 and it works well, now I will try to figure out which granularity works better. Your example was really a boost, thanks again! Regards, Paolo Il 19/06/2014 22:42, Paulo Ricardo Motta Gomes ha scritto: Hello Paolo, I just published an open source version of the dsetool list_subranges command, which will enable you to perform subrange repair as described in the post. You can find the code and usage instructions here: https://github.com/pauloricardomg/cassandra-list-subranges Currently available for 1.2.16, but I guess that just changing the version on the pom.xml and recompiling it will make it work on 2.0.x. Cheers, Paulo On Thu, Jun 19, 2014 at 4:40 PM, Jack Krupansky j...@basetechnology.com mailto:j...@basetechnology.com wrote: The DataStax doc should be current best practices: http://www.datastax.com/documentation/cassandra/2.0/cassandra/operations/ops_repair_nodes_c.html If you or anybody else finds it inadequate, speak up. -- Jack Krupansky -Original Message- From: Paolo Crosato Sent: Thursday, June 19, 2014 10:13 AM To: user@cassandra.apache.org mailto:user@cassandra.apache.org Subject: Best practices for repair Hi eveybody, we have some problems running repairs on a timely schedule. We have a three node deployment, and we start repair on one node every week, repairing one columnfamily by one. However, when we run into the big column families, usually repair sessions hangs undefinitely, and we have to restart them manually. The script runs commands like: nodetool repair keyspace columnfamily one by one. This has not been a major issue for some time, since we never delete data, however we would like to sort the issue once and for all. Reading resources on the net, I came to the conclusion that we could: 1) either run a repair sessione like the one above, but with the -pr switch, and run it on every node, not just on one 2) or run sub range repair as described here http://www.datastax.com/dev/blog/advanced-repair-techniques , which would be the best option. However the latter procedure would require us to write some java program that calls describe_splits to get the tokens to feed nodetool repair with. The second procedure is available out of the box only in the commercial version of the opscenter, is this true? I would like to know if these are the current best practices for repairs or if there is some other option that makes repair easier to perform, and more reliable that it is now. Regards, Paolo Crosato -- Paolo Crosato Software engineer/Custom Solutions e-mail: paolo.cros...@targaubiest.com mailto:paolo.cros...@targaubiest.com -- *Paulo Motta* Chaordic | /Platform/ _www.chaordic.com.br http://www.chaordic.com.br/_ +55 48 3232.3200 -- Paolo Crosato Software engineer/Custom Solutions e-mail: paolo.cros...@targaubiest.com Office phone: +3904221722825 UBIEST S.p.A. www.ubiest.com Via E. Reginato, 85/H - 31100 Treviso- ITALY Tel [+39] 0422 210 194 - Fax [+39] 0422 210 270 This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
Best practices for repair
Hi eveybody, we have some problems running repairs on a timely schedule. We have a three node deployment, and we start repair on one node every week, repairing one columnfamily by one. However, when we run into the big column families, usually repair sessions hangs undefinitely, and we have to restart them manually. The script runs commands like: nodetool repair keyspace columnfamily one by one. This has not been a major issue for some time, since we never delete data, however we would like to sort the issue once and for all. Reading resources on the net, I came to the conclusion that we could: 1) either run a repair sessione like the one above, but with the -pr switch, and run it on every node, not just on one 2) or run sub range repair as described here http://www.datastax.com/dev/blog/advanced-repair-techniques , which would be the best option. However the latter procedure would require us to write some java program that calls describe_splits to get the tokens to feed nodetool repair with. The second procedure is available out of the box only in the commercial version of the opscenter, is this true? I would like to know if these are the current best practices for repairs or if there is some other option that makes repair easier to perform, and more reliable that it is now. Regards, Paolo Crosato -- Paolo Crosato Software engineer/Custom Solutions e-mail: paolo.cros...@targaubiest.com
Re: nodetool repair stalled
I was able to complete the repair, repairing one keyspace and cf each time.
However the last session is still shown as an active process, even if
the session has been successfully completed, this is the log:
INFO [CompactionExecutor:252] 2014-01-14 03:10:13,105
CompactionTask.java (line 275) Compacted 12 sstables to
[/data/cassandra/data/system/compactions_in_progress/system-compactions_in_progress-jb-9492,].
1,371 bytes to 42 (~3% of original) in 56ms = 0.000715MB/s. 13 total
partitions merged to 1. Partition merge counts were {1:1, 2:6, }
INFO [STREAM-IN-/10.255.235.19] 2014-01-14 03:11:40,750
StreamResultFuture.java (line 181) [Stream
#6cf54d20-7cbf-11e3-a6c2-a1357a0d9222] Session with /10.255.235.19 is
complete
INFO [STREAM-IN-/10.255.235.19] 2014-01-14 03:11:40,750
StreamResultFuture.java (line 215) [Stream
#6cf54d20-7cbf-11e3-a6c2-a1357a0d9222] All sessions completed
INFO [STREAM-IN-/10.255.235.19] 2014-01-14 03:11:40,751
StreamingRepairTask.java (line 96) [repair
#02f3f620-7cbe-11e3-a6c2-a1357a0d9222] streaming task succeed, returning
response to /10.255.235.18
INFO [AntiEntropyStage:1] 2014-01-14 03:11:40,751 RepairSession.java
(line 214) [repair #02f3f620-7cbe-11e3-a6c2-a1357a0d9222] positions is
fully synced
INFO [AntiEntropySessions:161] 2014-01-14 03:11:40,751
RepairSession.java (line 274) [repair
#02f3f620-7cbe-11e3-a6c2-a1357a0d9222] session completed successfully
This is what ps -eaf |grep java shows:
500 25488 25459 0 Jan13 ?00:00:43 /usr/bin/java -cp
/etc/cassandra/conf:/usr/share/java/jna.jar:/usr/share/cassandra/lib/antlr-3.2.jar:/usr/share/cassandra/lib/apache-cassandra-2.0.3.jar:/usr/share/cassandra/lib/apache-cassandra-clientutil-2.0.3.jar:/usr/share/cassandra/lib/apache-cassandra-thrift-2.0.3.jar:/usr/share/cassandra/lib/commons-cli-1.1.jar:/usr/share/cassandra/lib/commons-codec-1.2.jar:/usr/share/cassandra/lib/commons-lang3-3.1.jar:/usr/share/cassandra/lib/compress-lzf-0.8.4.jar:/usr/share/cassandra/lib/concurrentlinkedhashmap-lru-1.3.jar:/usr/share/cassandra/lib/disruptor-3.0.1.jar:/usr/share/cassandra/lib/guava-15.0.jar:/usr/share/cassandra/lib/high-scale-lib-1.1.2.jar:/usr/share/cassandra/lib/jackson-core-asl-1.9.2.jar:/usr/share/cassandra/lib/jackson-mapper-asl-1.9.2.jar:/usr/share/cassandra/lib/jamm-0.2.5.jar:/usr/share/cassandra/lib/jbcrypt-0.3m.jar:/usr/share/cassandra/lib/jline-1.0.jar:/usr/share/cassandra/lib/json-simple-1.1.jar:/usr/share/cassandra/lib/libthrift-0.9.1.jar:/usr/share/cassandra/lib/log4j-1.2.16.jar:/usr/share/cassandra/lib/lz4-1.2.0.jar:/usr/share/cassandra/lib/metrics-core-2.2.0.jar:/usr/share/cassandra/lib/netty-3.6.6.Final.jar:/usr/share/cassandra/lib/reporter-config-2.1.0.jar:/usr/share/cassandra/lib/servlet-api-2.5-20081211.jar:/usr/share/cassandra/lib/slf4j-api-1.7.2.jar:/usr/share/cassandra/lib/slf4j-log4j12-1.7.2.jar:/usr/share/cassandra/lib/snakeyaml-1.11.jar:/usr/share/cassandra/lib/snappy-java-1.0.5.jar:/usr/share/cassandra/lib/snaptree-0.1.jar:/usr/share/cassandra/lib/stress.jar:/usr/share/cassandra/lib/thrift-server-0.3.2.jar
-Xmx32m -Dlog4j.configuration=log4j-tools.properties
-Dstorage-config=/etc/cassandra/conf org.apache.cassandra.tools.NodeCmd
-p 7199 repair tiergast positions
Is this a known bug?
Regards,
Paolo Crosato
Il 13/01/2014 10:25, Paolo Crosato ha scritto:
Hi,
I rebooted the nodes and started a fresh repair session. The repair
session was started on node 1.
This time actually I got this error on the node that started the repair:
ERROR [AntiEntropySessions:2] 2014-01-10 09:44:46,360
RepairSession.java (line 278) [repair
#728f4860-79d3-11e3-8c98-a1357a0d9222] session completed with the
following error
org.apache.cassandra.exceptions.RepairException: [repair
#728f4860-79d3-11e3-8c98-a1357a0d9222 on OpsCenter/rollups300,
(4515884230644880127,4556138740897423021]] Sync failed between
/10.255.235.18 and /10.255.235.19
at
org.apache.cassandra.repair.RepairSession.syncComplete(RepairSession.java:200)
at
org.apache.cassandra.service.ActiveRepairService.handleMessage(ActiveRepairService.java:193)
at
org.apache.cassandra.repair.RepairMessageVerbHandler.doVerb(RepairMessageVerbHandler.java:59)
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:60)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
ERROR [AntiEntropySessions:2] 2014-01-10 09:44:46,399
CassandraDaemon.java (line 187) Exception in thread
Thread[AntiEntropySessions:2,5,RMI Runtime]
java.lang.RuntimeException:
org.apache.cassandra.exceptions.RepairException: [repair
#728f4860-79d3-11e3-8c98-a1357a0d9222 on OpsCenter/rollups300,
(4515884230644880127,4556138740897423021]] Sync failed between
/10.255.235.18 and /10.255.235.19
at com.google.common.base.Throwables.propagate(Throwables.java:160
nodetool repair stalled
Hi, I have two nodes with Cassandra 2.0.3, where repair sessions hang for an undefinite time. I'm running nodetool repair once a week on every node, on different days. Currently I have like 4 repair sessions running on each node, one since 3 weeks and none has finished. Reading the logs I didn't find any exception, apparently one of the repair session got stuck at this command: INFO [AntiEntropySessions:10] 2014-01-05 01:00:02,804 RepairJob.java (line 116) [repair #5385ea40-759c-11e3-93dc-a1357a0d9222] requesting merkle trees for events (to [/10.255.235.19, /10.255.235.18]) Has anybody any suggestion on why a nodetool repair might be stuck and how to debug it? Regards, Paolo Crosato
Issue with source command and utf8 file
Hi,
I'm trying to load some data in Cassandra by the source command in cqlsh.
The file is utf8 encoded, however Cassandra seems unable to detect utf8
encoded characters.
Here is a sample:
insert into
positions8(iddevice,timestampevent,idunit,idevent,status,value)
values(40135,'2013-06-06T10:08:02',13524915,0,'G','{sp:0,A1:FRANCE,lat:45216954,iDD:40135,A2:RHÔNE-ALPES,tEv:2013-06-06T10:08:02,iE:0,iTE:0,lng:6462520,iD:13318089,mi:0,st:ÉCHANGEUR
DE
ST-MICHEL-DE-MAURIENNE,A4:SAINT-MARTIN-D'ARC,iU:13524915,A3:SAVOIE,tRx:2013-06-06T10:12:56}');
Here is the hex dump of the file:
6e69 6573 7472 6920 746e 206f 6f70 6973
6974 6e6f 3873 6928 6464 7665 6369 2c65
6974 656d 7473 6d61 6570 6576 746e 692c
7564 696e 2c74 6469 7665 6e65 2c74 7473
7461 7375 762c 6c61 6575 2029 6176 756c
7365 3428 3130 3030 3030 3533 272c 3032
3331 302d 2d36 3630 3154 3a30 3830 303a
2732 312c 3533 3432 3139 2c35 2c30 4727
2c27 7b27 7322 2270 223a 2230 222c 3141
3a22 4622 4152 434e 2245 222c 616c 2274
223a 3534 3132 3936 3435 2c22 6922
3a22 3422 3130 3030 3030 3533 2c22 4122
2232 223a 4852 94c3 454e 412d 504c 5345
2c22 7422 7645 3a22 3222 3130 2d33 3630
302d 5436 3031 303a 3a38 3230 2c22 6922
2245 223a 2230 222c 5469 2245 223a 2230
222c 6e6c 2267 223a 3436 3236 3235 2230
222c 4469 3a22 3122 3831 3830 2239
222c 696d 3a22 2c30 7322 2274 223a 89c3
4843 4e41 4547 5255 4420 2045 5453 4d2d
4349 4548 2d4c 4544 4d2d 5541 4952 4e45
454e 2c22 4122 2234 223a 4153 4e49 2d54
414d 5452 4e49 442d 4127 4352 2c22 6922
2255 223a 3331 3235 3934 3531 2c22 4122
2233 223a 4153 4f56 4549 2c22 7422 7852
3a22 3222 3130 2d33 3630 302d 5436 3031
313a 3a32 3635 7d22 2927 0a3b 000a
As an example, Ô is encoded as C394. When I try to load the file I get
this error:
cqlsh:demodb source 'rhone.cql';
rhone.cql:3:Incomplete statement at end of file
The error disappears only when I remove all the non ascii characters.
If I copy and paste the insert on cqlsh shell, it works.
Cassandra is installed on a centos 6.3 server, LANG is .UTF8, I tried
connecting from remote both with gnome terminal and putty on windows,
with utf-8 shell, no success on both.
Has anybody got any clue?
Regards,
Paolo
--
Paolo Crosato
Software engineer/Custom Solutions
Problem with sstableloader from text data
(;
cpBuilder.add(bytes(model.getIdEvent()));
positionsWriter.newRow(cpBuilder.build());
positionsWriter.addColumn(bytes(idunit),
bytes(model.getIdUnit()), timestamp);
String status=G;
if (model.getCity()==null||model.getCity().equals()) {
status=U;
}
positionsWriter.addColumn(bytes(status), bytes(status),
timestamp);
positionsWriter.addColumn(bytes(value), bytes(line),
timestamp);
System.out.println(line: +line);
}
reader.close();
positionsWriter.close();
System.exit(0);
.
The table declaration is included above. I'm using a composite primary
key, and I'm not really sure if it's the right way to build it,
I didn't manage to get any updated or complete example on doing this
with a composite type key.
Can anyone help me?
Regards,
Paolo
--
Paolo Crosato
Software engineer/Custom Solutions
