date:20110712

[jira] [Updated] (CASSANDRA-2691) If an upload to central repository fails for an artifact, retry a couple of times before killing the build

2011-07-12 Thread Stephen Connolly (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephen Connolly updated CASSANDRA-2691:


Attachment: CASSANDRA-2691.patch

Will now retry deployment up to 10 times before giving up.

 If an upload to central repository fails for an artifact, retry a couple of 
 times before killing the build
 --

 Key: CASSANDRA-2691
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2691
 Project: Cassandra
  Issue Type: Improvement
Affects Versions: 0.7.7, 0.8.0
Reporter: Stephen Connolly
 Attachments: CASSANDRA-2691.patch


 Depends on MGPG-35 http://jira.codehaus.org/browse/MGPG-35

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2868) Native Memory Leak

2011-07-12 Thread Daniel Doubleday (JIRA)

[
https://issues.apache.org/jira/browse/CASSANDRA-2868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13063770#comment-13063770
]

Daniel Doubleday commented on CASSANDRA-2868:
-

Next: [anon]: 3675224 (+47616KB in 1 day)

bq. Is your data size constant? If not you are probably seeing growth in the
index samples and bloom filters.

Well no - the data size is increasing. But I thought that index and bf is good
old plain java heap no? JVM heap stats are really relaxed. Yet I think that
doesn't really matter because what we are seeing is an ever increasing rss mem
consumption even though we have -Xmx3G and -Xms3G and mlockall (pmap shows
these 3G as one block). So something seems to be constantly allocating native
mem that has nothing to do with java heap.

Native Memory Leak
--

Key: CASSANDRA-2868
URL: https://issues.apache.org/jira/browse/CASSANDRA-2868
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.7.6
Reporter: Daniel Doubleday
Priority: Minor

We have memory issues with long running servers. These have been confirmed by
several users in the user list. That's why I report.
The memory consumption of the cassandra java process increases steadily until
it's killed by the os because of oom (with no swap)
Our server is started with -Xmx3000M and running for around 23 days.
pmap -x shows
Total SST: 1961616 (mem mapped data and index files)
Anon RSS: 6499640
Total RSS: 8478376
This shows that 3G are 'overallocated'.
We will use BRAF on one of our less important nodes to check wether it is
related to mmap and report back.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-2886) cli command update keyspace fails to change replication_factor

2011-07-12 Thread Radim Kolar (JIRA)

cli command update keyspace fails to change replication_factor
--

 Key: CASSANDRA-2886
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2886
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Affects Versions: 0.8.1
 Environment: Windows or FreeBSD
Reporter: Radim Kolar
Priority: Minor
 Fix For: 0.8.2


In wiki http://wiki.apache.org/cassandra/Operations#Replication its documented 
that increasing replication on live cluster can be done with following command:

[default@unknown] update keyspace test with replication_factor = 2 ;
No enum const class 
org.apache.cassandra.cli.CliClient$AddKeyspaceArgument.REPLICATION_FACTOR

this command do not works. Wiki should be updated or cassandra-cli fixed

More info:
[default@unknown] describe keyspace test;
Keyspace: test:
  Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
  Durable Writes: true
Options: [replication_factor:1]
  Column Families:
ColumnFamily: sipdb
phone calls routing information
  Key Validation Class: org.apache.cassandra.db.marshal.IntegerType
  Default column value validator: org.apache.cassandra.db.marshal.BytesType
  Columns sorted by: org.apache.cassandra.db.marshal.AsciiType
  Row cache size / save period in seconds: 0.0/0
  Key cache size / save period in seconds: 0.0/0
  Memtable thresholds: 0.0328125/7/1440 (millions of ops/MB/minutes)
  GC grace seconds: 0
  Compaction min/max thresholds: 4/32
  Read repair chance: 0.0
  Replicate on write: false
  Built indexes: []
  Column Metadata:
Column Name: kam
  Validation Class: org.apache.cassandra.db.marshal.AsciiType
  Index Name: kam_idx
[default@unknown]


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-47) SSTable compression

2011-07-12 Thread Terje Marthinussen (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13063788#comment-13063788
 ] 

Terje Marthinussen commented on CASSANDRA-47:
-

Tried to import some data with json2sstable to compare sizes, but seems like 
json2sstable is not entirely working yet?

 SSTable compression
 ---

 Key: CASSANDRA-47
 URL: https://issues.apache.org/jira/browse/CASSANDRA-47
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Jonathan Ellis
Assignee: Pavel Yaskevich
  Labels: compression
 Fix For: 1.0

 Attachments: CASSANDRA-47.patch, snappy-java-1.0.3-rc4.jar


 We should be able to do SSTable compression which would trade CPU for I/O 
 (almost always a good trade).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-47) SSTable compression

2011-07-12 Thread Pavel Yaskevich (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13063790#comment-13063790
 ] 

Pavel Yaskevich commented on CASSANDRA-47:
--

Tests are passing. Does it crush on you? As I wrote before - currently to check 
real size of the file (tested only on linux because OS X FS saves empty blocks 
to the disk for some reason) you need to get a block count using 'ls -alhs', 
current patch reserves an empty space for each chunk because we need to do 
seeks while we write data using SSTableWriter.

I'm currently working to avoid that (CASSANDRA-2879 is a step in that 
direction).

 SSTable compression
 ---

 Key: CASSANDRA-47
 URL: https://issues.apache.org/jira/browse/CASSANDRA-47
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Jonathan Ellis
Assignee: Pavel Yaskevich
  Labels: compression
 Fix For: 1.0

 Attachments: CASSANDRA-47.patch, snappy-java-1.0.3-rc4.jar


 We should be able to do SSTable compression which would trade CPU for I/O 
 (almost always a good trade).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2771) Remove commitlog_rotation_threshold_in_mb

2011-07-12 Thread Radim Kolar (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13063797#comment-13063797
 ] 

Radim Kolar commented on CASSANDRA-2771:


I used that feature to change commit log to 32MB segments

  Remove commitlog_rotation_threshold_in_mb
 --

 Key: CASSANDRA-2771
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2771
 Project: Cassandra
  Issue Type: Improvement
Reporter: Patricio Echague
Assignee: Patricio Echague
Priority: Minor
  Labels: commitlog
 Fix For: 1.0

 Attachments: CASSANDRA-2771-2-trunk.txt, CASSANDRA-2771-3-trunk.txt


 Remove the commitlog segment size config setting, nobody has ever changed it.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2582) sstable2json: make TTL optional, possibility of incremental dumps

2011-07-12 Thread Timo Nentwig (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13063800#comment-13063800
 ] 

Timo Nentwig commented on CASSANDRA-2582:
-

I didn't say that there's no alternative to loaded the files into RAM :)

Anyway, actually modifying the JSON files was my first idea because patching 
distro code requires me to patch it in every new version again. I did it anyway 
because it's a really trivial patch and it save a lot of IO and time.

 sstable2json: make TTL optional, possibility of incremental dumps
 -

 Key: CASSANDRA-2582
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2582
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Timo Nentwig
Priority: Trivial
 Fix For: 0.8.2

 Attachments: nottl-and-lastmodified-0.7.5.patch, 
 nottl-and-lastmodified.patch


 Data on live cluster is supposed to expire automatically but exported to an 
 archive cluster beforehand. In order to prevent expiration on the archive 
 cluster add an option to sstable2json to ignore TTL data. Furthermore add an 
 lastModified option that ignores older columns for incremental archiving.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-2887) decommision fails if pathseparators are different

2011-07-12 Thread Radim Kolar (JIRA)

decommision fails if pathseparators are different
-

 Key: CASSANDRA-2887
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2887
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.8.1
 Environment: FreeBSD 8 vs Windows XP
Reporter: Radim Kolar


I have 2 nodes in cluster. One is running on Windows XP and second is running 
on FreeBSD 8.2. If i try to decommission freebsd note windows node throws and 
exception during receiving streamed data:

java.lang.AssertionError: Filename must include parent directory.
at org.apache.cassandra.io.sstable.Descriptor.fromFilename(Descriptor.ja
va:122)
at org.apache.cassandra.streaming.PendingFile$PendingFileSerializer.dese
rialize(PendingFile.java:130)
at org.apache.cassandra.streaming.StreamHeader$StreamHeaderSerializer.de
serialize(StreamHeader.java:90)
at org.apache.cassandra.streaming.StreamHeader$StreamHeaderSerializer.de
serialize(StreamHeader.java:72)
at org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnect
ion.java:95)

this problem was discussed here 
http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/0-7-problem-on-cygwin-td5679932.html
with patch for cassandra 0.7 included


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

70 matches

Mail list logo