[jira] [Commented] (CASSANDRA-4573) HSHA doesn't handle large messages gracefully
[
https://issues.apache.org/jira/browse/CASSANDRA-4573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13714355#comment-13714355
]
Peter Haggerty commented on CASSANDRA-4573:
---
We may be seeing this behavior in 1.2.6. I haven't enabled debug but we are
definitely seeing a correlation between groups of 'Read an invalid frame size
of 0' messages (dozens at a time) during the same second that we're seeing
large (10 seconds or more) 'GC for ConcurrentMarkSweep' events.
On a 9 node cluster we see this anywhere from 1 to 9 times a day.
HSHA doesn't handle large messages gracefully
-
Key: CASSANDRA-4573
URL: https://issues.apache.org/jira/browse/CASSANDRA-4573
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Tyler Hobbs
Assignee: Vijay
Attachments: repro.py
HSHA doesn't seem to enforce any kind of max message length, and when
messages are too large, it doesn't fail gracefully.
With debug logs enabled, you'll see this:
{{DEBUG 13:13:31,805 Unexpected state 16}}
Which seems to mean that there's a SelectionKey that's valid, but isn't ready
for reading, writing, or accepting.
Client-side, you'll get this thrift error (while trying to read a frame as
part of {{recv_batch_mutate}}):
{{TTransportException: TSocket read 0 bytes}}
--
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
[jira] [Created] (CASSANDRA-5783) nodetool and cassandra-cli report different information for Compaction min/max thresholds
Peter Haggerty created CASSANDRA-5783:
-
Summary: nodetool and cassandra-cli report different information
for Compaction min/max thresholds
Key: CASSANDRA-5783
URL: https://issues.apache.org/jira/browse/CASSANDRA-5783
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.2.6
Reporter: Peter Haggerty
Ask cassandra-cli and nodetool the same question and get different answers
back. This was executed after using nodetool to adjust the compactionthreshold
on this CF to have a minimum of 2. The change was observed to work as we saw
increased compactions which is exactly what one would expect
$ echo describe ${CF}; \
| cassandra-cli -h localhost -k ${KEYSPACE} \
| grep thresholds
Compaction min/max thresholds: 4/32
$ nodetool -h localhost getcompactionthreshold ${KEYSPACE} ${CF}
Current compaction thresholds for Metrics/dimensions_active_1:
min = 2, max = 32
--
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
[jira] [Updated] (CASSANDRA-5783) nodetool and cassandra-cli report different information for Compaction min/max thresholds
[
https://issues.apache.org/jira/browse/CASSANDRA-5783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Haggerty updated CASSANDRA-5783:
--
Priority: Minor (was: Major)
nodetool and cassandra-cli report different information for Compaction
min/max thresholds
---
Key: CASSANDRA-5783
URL: https://issues.apache.org/jira/browse/CASSANDRA-5783
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.2.6
Reporter: Peter Haggerty
Priority: Minor
Ask cassandra-cli and nodetool the same question and get different answers
back. This was executed after using nodetool to adjust the
compactionthreshold on this CF to have a minimum of 2. The change was
observed to work as we saw increased compactions which is exactly what one
would expect
$ echo describe ${CF}; \
| cassandra-cli -h localhost -k ${KEYSPACE} \
| grep thresholds
Compaction min/max thresholds: 4/32
$ nodetool -h localhost getcompactionthreshold ${KEYSPACE} ${CF}
Current compaction thresholds for Metrics/dimensions_active_1:
min = 2, max = 32
--
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
[jira] [Commented] (CASSANDRA-5661) Discard pooled readers for cold data
[ https://issues.apache.org/jira/browse/CASSANDRA-5661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13714389#comment-13714389 ] Ben Manes commented on CASSANDRA-5661: -- I replaced the external handle with directly providing the resource and maintaining the association in a threadlocal. This should better match your usage and resolve your concern above. The primary motivation was to reduce object churn, as a handle was created per borrow. This reduced the hot spot time from an average invocation time of 1001us to 704us, when summing up the worst offenders. This may remove the random spiked that you observed if they were caused by garbage collection. 98% of the overhead is now due to usage of other collections (Guava's Cache, LTQ, CLQ). Discard pooled readers for cold data Key: CASSANDRA-5661 URL: https://issues.apache.org/jira/browse/CASSANDRA-5661 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.1 Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Fix For: 2.0.1 Attachments: CASSANDRA-5661-multiway-per-sstable.patch, CASSANDRA-5661.patch, CASSANDRA-5661-v2-global-multiway-per-sstable.patch, DominatorTree.png, Histogram.png Reader pooling was introduced in CASSANDRA-4942 but pooled RandomAccessReaders are never cleaned up until the SSTableReader is closed. So memory use is the worst case simultaneous RAR we had open for this file, forever. We should introduce a global limit on how much memory to use for RAR, and evict old ones. -- 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
[jira] [Commented] (CASSANDRA-5661) Discard pooled readers for cold data
[ https://issues.apache.org/jira/browse/CASSANDRA-5661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13714403#comment-13714403 ] Ben Manes commented on CASSANDRA-5661: -- Switching from LTQ to a custom elimination backoff stack appears to have dropped the 98% to 179us. The single threaded benchmark improves by 30ns. A significant gain was also observed when using an EBS instead of an array of CLQs in the time-to-idle policy. I'm surprised by how much of a gain occurs, so I'll have to experiment further to understand if its factual. LTQ/CLQ are hindered by having to honor FIFO with j.u.c. interfaces, and LIFO elimination is the ideal strategy for an object pool. The more frequently successful exchanges may reduce down to eden-space GC, resulting in major net wins. That, or I'm prematurely believing that its working correctly. Discard pooled readers for cold data Key: CASSANDRA-5661 URL: https://issues.apache.org/jira/browse/CASSANDRA-5661 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.1 Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Fix For: 2.0.1 Attachments: CASSANDRA-5661-multiway-per-sstable.patch, CASSANDRA-5661.patch, CASSANDRA-5661-v2-global-multiway-per-sstable.patch, DominatorTree.png, Histogram.png Reader pooling was introduced in CASSANDRA-4942 but pooled RandomAccessReaders are never cleaned up until the SSTableReader is closed. So memory use is the worst case simultaneous RAR we had open for this file, forever. We should introduce a global limit on how much memory to use for RAR, and evict old ones. -- 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
[jira] [Commented] (CASSANDRA-5689) NPE shutting down Cassandra trunk (cassandra-1.2.5-989-g70dfb70)
[
https://issues.apache.org/jira/browse/CASSANDRA-5689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13714491#comment-13714491
]
Cathy Daw commented on CASSANDRA-5689:
--
I'll raise a bug in the DSE bug system to debug more.
NPE shutting down Cassandra trunk (cassandra-1.2.5-989-g70dfb70)
Key: CASSANDRA-5689
URL: https://issues.apache.org/jira/browse/CASSANDRA-5689
Project: Cassandra
Issue Type: Bug
Components: API
Affects Versions: 1.2.0
Environment: Ubuntu Precise with Oracle Java 7u25.
Reporter: Blair Zajac
Assignee: Cathy Daw
Priority: Trivial
Attachments: CASSANDRA-5689.txt, init1, init2, init3
I built Cassandra from git trunk at cassandra-1.2.5-989-g70dfb70 using the
debian/ package. I have a shell script to shut down Cassandra:
{code}
$nodetool disablegossip
sleep 5
$nodetool disablebinary
$nodetool disablethrift
$nodetool drain
/etc/init.d/cassandra stop
{code}
Shutting it down I get this exception on all three nodes:
{code}
Exception in thread main java.lang.NullPointerException
at org.apache.cassandra.transport.Server.close(Server.java:156)
at org.apache.cassandra.transport.Server.stop(Server.java:107)
at
org.apache.cassandra.service.StorageService.stopNativeTransport(StorageService.java:347)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75)
at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279)
at
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
at
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
at
com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
at
com.sun.jmx.remote.security.MBeanServerAccessController.invoke(MBeanServerAccessController.java:468)
at
javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487)
at
javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
at
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
at java.security.AccessController.doPrivileged(Native Method)
at
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1427)
at
javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
at sun.rmi.transport.Transport$1.run(Transport.java:177)
at sun.rmi.transport.Transport$1.run(Transport.java:174)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
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:724)
{code}
--
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
git commit: src/java/org/apache/cassandra/tools/SSTableExport.java patch by clohfink reviewed by dbrosius for cassandra-5781
Updated Branches: refs/heads/cassandra-1.2 27efded38 - 089f92b1a src/java/org/apache/cassandra/tools/SSTableExport.java patch by clohfink reviewed by dbrosius for cassandra-5781 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/089f92b1 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/089f92b1 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/089f92b1 Branch: refs/heads/cassandra-1.2 Commit: 089f92b1a04cbcc7d391ea7e61d90df56174ad73 Parents: 27efded Author: Dave Brosius dbros...@apache.org Authored: Sat Jul 20 15:12:54 2013 -0400 Committer: Dave Brosius dbros...@apache.org Committed: Sat Jul 20 15:12:54 2013 -0400 -- CHANGES.txt| 1 + src/java/org/apache/cassandra/tools/SSTableExport.java | 5 ++--- 2 files changed, 3 insertions(+), 3 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/089f92b1/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index f8a3f09..23f19d4 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -22,6 +22,7 @@ * Fix minor bug in Range.intersects(Bound) (CASSANDRA-5771) * cqlsh: handle disabled compression in DESCRIBE output (CASSANDRA-5766) * Ensure all UP events are notified on the native protocol (CASSANDRA-5769) + * Fix formatting of sstable2json with multiple -k arguments (CASSANDRA-5781) 1.2.6 http://git-wip-us.apache.org/repos/asf/cassandra/blob/089f92b1/src/java/org/apache/cassandra/tools/SSTableExport.java -- diff --git a/src/java/org/apache/cassandra/tools/SSTableExport.java b/src/java/org/apache/cassandra/tools/SSTableExport.java index d3fca4c..05fe9f6 100644 --- a/src/java/org/apache/cassandra/tools/SSTableExport.java +++ b/src/java/org/apache/cassandra/tools/SSTableExport.java @@ -355,12 +355,11 @@ public class SSTableExport if (!row.getKey().equals(decoratedKey)) continue; -serializeRow(row, decoratedKey, outs); - if (i != 0) outs.println(,); - i++; + +serializeRow(row, decoratedKey, outs); } outs.println(\n]);
[jira] [Updated] (CASSANDRA-5781) Providing multiple keys to sstable2json results in invalid json
[
https://issues.apache.org/jira/browse/CASSANDRA-5781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Brosius updated CASSANDRA-5781:
Affects Version/s: (was: 2.0 beta 1)
1.2.6
Providing multiple keys to sstable2json results in invalid json
---
Key: CASSANDRA-5781
URL: https://issues.apache.org/jira/browse/CASSANDRA-5781
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.2.6
Reporter: Chris Lohfink
Priority: Minor
Fix For: 1.2.7
Attachments: patch
if you pass multiple keys via the -k parameter to sstable for json the 2nd
row will be appended to the end of the first without a comma. It would look
like so:
{code}
sstable2json foo-Data.db -k key1 -k key2 -k key3 -k key4
{
key1 : [[]...]key2: [[]...],
key3 : [[]...],
key4 : [[]...]
}
{code}
--
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
[jira] [Resolved] (CASSANDRA-5781) Providing multiple keys to sstable2json results in invalid json
[
https://issues.apache.org/jira/browse/CASSANDRA-5781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Brosius resolved CASSANDRA-5781.
-
Resolution: Fixed
Fix Version/s: 1.2.7
Reviewer: dbrosius
committed to cassandra-1.2 as 089f92b1a04cbcc7d391ea7e61d90df56174ad73
Providing multiple keys to sstable2json results in invalid json
---
Key: CASSANDRA-5781
URL: https://issues.apache.org/jira/browse/CASSANDRA-5781
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 2.0 beta 1
Reporter: Chris Lohfink
Priority: Minor
Fix For: 1.2.7
Attachments: patch
if you pass multiple keys via the -k parameter to sstable for json the 2nd
row will be appended to the end of the first without a comma. It would look
like so:
{code}
sstable2json foo-Data.db -k key1 -k key2 -k key3 -k key4
{
key1 : [[]...]key2: [[]...],
key3 : [[]...],
key4 : [[]...]
}
{code}
--
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
[1/2] git commit: src/java/org/apache/cassandra/tools/SSTableExport.java patch by clohfink reviewed by dbrosius for cassandra-5781
Updated Branches: refs/heads/trunk 0cc0d8ded - e70490564 src/java/org/apache/cassandra/tools/SSTableExport.java patch by clohfink reviewed by dbrosius for cassandra-5781 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/089f92b1 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/089f92b1 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/089f92b1 Branch: refs/heads/trunk Commit: 089f92b1a04cbcc7d391ea7e61d90df56174ad73 Parents: 27efded Author: Dave Brosius dbros...@apache.org Authored: Sat Jul 20 15:12:54 2013 -0400 Committer: Dave Brosius dbros...@apache.org Committed: Sat Jul 20 15:12:54 2013 -0400 -- CHANGES.txt| 1 + src/java/org/apache/cassandra/tools/SSTableExport.java | 5 ++--- 2 files changed, 3 insertions(+), 3 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/089f92b1/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index f8a3f09..23f19d4 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -22,6 +22,7 @@ * Fix minor bug in Range.intersects(Bound) (CASSANDRA-5771) * cqlsh: handle disabled compression in DESCRIBE output (CASSANDRA-5766) * Ensure all UP events are notified on the native protocol (CASSANDRA-5769) + * Fix formatting of sstable2json with multiple -k arguments (CASSANDRA-5781) 1.2.6 http://git-wip-us.apache.org/repos/asf/cassandra/blob/089f92b1/src/java/org/apache/cassandra/tools/SSTableExport.java -- diff --git a/src/java/org/apache/cassandra/tools/SSTableExport.java b/src/java/org/apache/cassandra/tools/SSTableExport.java index d3fca4c..05fe9f6 100644 --- a/src/java/org/apache/cassandra/tools/SSTableExport.java +++ b/src/java/org/apache/cassandra/tools/SSTableExport.java @@ -355,12 +355,11 @@ public class SSTableExport if (!row.getKey().equals(decoratedKey)) continue; -serializeRow(row, decoratedKey, outs); - if (i != 0) outs.println(,); - i++; + +serializeRow(row, decoratedKey, outs); } outs.println(\n]);
[2/2] git commit: Merge branch 'cassandra-1.2' into trunk
Merge branch 'cassandra-1.2' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e7049056 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e7049056 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e7049056 Branch: refs/heads/trunk Commit: e704905641261e9e44ff138c588896002240acc5 Parents: 0cc0d8d 089f92b Author: Dave Brosius dbros...@apache.org Authored: Sat Jul 20 15:34:58 2013 -0400 Committer: Dave Brosius dbros...@apache.org Committed: Sat Jul 20 15:34:58 2013 -0400 -- CHANGES.txt| 1 + src/java/org/apache/cassandra/tools/SSTableExport.java | 5 ++--- 2 files changed, 3 insertions(+), 3 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/e7049056/CHANGES.txt -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/e7049056/src/java/org/apache/cassandra/tools/SSTableExport.java -- diff --cc src/java/org/apache/cassandra/tools/SSTableExport.java index 3e51d17,05fe9f6..1568b00 --- a/src/java/org/apache/cassandra/tools/SSTableExport.java +++ b/src/java/org/apache/cassandra/tools/SSTableExport.java @@@ -303,26 -346,20 +303,25 @@@ public class SSTableExpor lastKey = decoratedKey; -scanner.seekTo(decoratedKey); - -if (!scanner.hasNext()) +RowIndexEntry entry = sstable.getPosition(decoratedKey, SSTableReader.Operator.EQ); +if (entry == null) continue; -SSTableIdentityIterator row = (SSTableIdentityIterator) scanner.next(); -if (!row.getKey().equals(decoratedKey)) -continue; +dfile.seek(entry.position); +ByteBufferUtil.readWithShortLength(dfile); // row key +if (sstable.descriptor.version.hasRowSizeAndColumnCount) +dfile.readLong(); // row size +DeletionInfo deletionInfo = new DeletionInfo(DeletionTime.serializer.deserialize(dfile)); +int columnCount = sstable.descriptor.version.hasRowSizeAndColumnCount ? dfile.readInt() : Integer.MAX_VALUE; + +IteratorOnDiskAtom atomIterator = sstable.metadata.getOnDiskIterator(dfile, columnCount, sstable.descriptor.version); + - serializeRow(deletionInfo, atomIterator, sstable.metadata, decoratedKey, outs); ++checkStream(outs); if (i != 0) outs.println(,); - - checkStream(outs); i++; - -serializeRow(row, decoratedKey, outs); ++serializeRow(deletionInfo, atomIterator, sstable.metadata, decoratedKey, outs); } outs.println(\n]);
[jira] [Updated] (CASSANDRA-5661) Discard pooled readers for cold data
[ https://issues.apache.org/jira/browse/CASSANDRA-5661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-5661: --- Attachment: (was: CASSANDRA-5661-multiway-per-sstable.patch) Discard pooled readers for cold data Key: CASSANDRA-5661 URL: https://issues.apache.org/jira/browse/CASSANDRA-5661 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.1 Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Fix For: 2.0.1 Attachments: CASSANDRA-5661.patch, DominatorTree.png, Histogram.png Reader pooling was introduced in CASSANDRA-4942 but pooled RandomAccessReaders are never cleaned up until the SSTableReader is closed. So memory use is the worst case simultaneous RAR we had open for this file, forever. We should introduce a global limit on how much memory to use for RAR, and evict old ones. -- 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
[jira] [Updated] (CASSANDRA-5661) Discard pooled readers for cold data
[ https://issues.apache.org/jira/browse/CASSANDRA-5661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-5661: --- Attachment: (was: CASSANDRA-5661-v2-global-multiway-per-sstable.patch) Discard pooled readers for cold data Key: CASSANDRA-5661 URL: https://issues.apache.org/jira/browse/CASSANDRA-5661 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.1 Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Fix For: 2.0.1 Attachments: CASSANDRA-5661.patch, DominatorTree.png, Histogram.png Reader pooling was introduced in CASSANDRA-4942 but pooled RandomAccessReaders are never cleaned up until the SSTableReader is closed. So memory use is the worst case simultaneous RAR we had open for this file, forever. We should introduce a global limit on how much memory to use for RAR, and evict old ones. -- 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
[jira] [Updated] (CASSANDRA-5661) Discard pooled readers for cold data
[ https://issues.apache.org/jira/browse/CASSANDRA-5661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-5661: --- Attachment: CASSANDRA-5661-global-multiway-cache.patch attaching patch with supports the latest version of multiway pool (and latest trunk) and adds (C)RAR deallocation on object removal. Sorry I didn't run the test sooner, I was quiet busy with other things... So I see that with this version 95-99.9 have degraded comparing to previous by ~3 ms but they don't shake as they used too - it's around ~5 ms now (I'm testing with expireAfterAccess). Discard pooled readers for cold data Key: CASSANDRA-5661 URL: https://issues.apache.org/jira/browse/CASSANDRA-5661 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.1 Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Fix For: 2.0.1 Attachments: CASSANDRA-5661-global-multiway-cache.patch, CASSANDRA-5661.patch, DominatorTree.png, Histogram.png Reader pooling was introduced in CASSANDRA-4942 but pooled RandomAccessReaders are never cleaned up until the SSTableReader is closed. So memory use is the worst case simultaneous RAR we had open for this file, forever. We should introduce a global limit on how much memory to use for RAR, and evict old ones. -- 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
[jira] [Commented] (CASSANDRA-5661) Discard pooled readers for cold data
[ https://issues.apache.org/jira/browse/CASSANDRA-5661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13714543#comment-13714543 ] Ben Manes commented on CASSANDRA-5661: -- Thanks Pavel. I'm not sure why it got worse recently, except that you did turn on recordStats() in the last few runs. That can incur significant overhead by maintaining multiple LongAdders. Since you did not turn it on in the FileCache patch, which would provide similar stats, it may be an unfair comparison. I'll try to wrap up my EBS prototype and push those changes soon. Those aren't on github yet. Discard pooled readers for cold data Key: CASSANDRA-5661 URL: https://issues.apache.org/jira/browse/CASSANDRA-5661 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.1 Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Fix For: 2.0.1 Attachments: CASSANDRA-5661-global-multiway-cache.patch, CASSANDRA-5661.patch, DominatorTree.png, Histogram.png Reader pooling was introduced in CASSANDRA-4942 but pooled RandomAccessReaders are never cleaned up until the SSTableReader is closed. So memory use is the worst case simultaneous RAR we had open for this file, forever. We should introduce a global limit on how much memory to use for RAR, and evict old ones. -- 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
[jira] [Created] (CASSANDRA-5785) Unable to bulkload data from old cluster using SSTableLoader
deepti naidu created CASSANDRA-5785: --- Summary: Unable to bulkload data from old cluster using SSTableLoader Key: CASSANDRA-5785 URL: https://issues.apache.org/jira/browse/CASSANDRA-5785 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.6 Environment: CentOs Reporter: deepti naidu Hi, I created snapshots of data from an old cluster with RandomPartitioner so that I could then transfer this data to a new cluster with Murmur3Partitioner using SSTableLoader. Instead of live streaming, I saved the SSTables created on a node in the new cluster. I get the following error when I attempt to run SSTableLoader: java.lang.IllegalStateException: SSTable first key DecoratedKey(4773451653614838302, 001519ba) last key DecoratedKey(-8904542581826997474, 0018c62f) at org.apache.cassandra.io.sstable.SSTableReader.validate(SSTableReader.java:482) at org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:206) at org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:154) at org.apache.cassandra.io.sstable.SSTableLoader$1.accept(SSTableLoader.java:100) at java.io.File.list(File.java:1010) at org.apache.cassandra.io.sstable.SSTableLoader.openSSTables(SSTableLoader.java:67) at org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:121) at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:67) -- 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
[jira] [Commented] (CASSANDRA-4573) HSHA doesn't handle large messages gracefully
[
https://issues.apache.org/jira/browse/CASSANDRA-4573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13714546#comment-13714546
]
Vijay commented on CASSANDRA-4573:
--
Peter, Looks like your issue is because of the client timeout when you didn't
receive a response for 10 sec. Time to tune the heap or add more nodes.
Tyler, is this ticket still valid?
HSHA doesn't handle large messages gracefully
-
Key: CASSANDRA-4573
URL: https://issues.apache.org/jira/browse/CASSANDRA-4573
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Tyler Hobbs
Assignee: Vijay
Attachments: repro.py
HSHA doesn't seem to enforce any kind of max message length, and when
messages are too large, it doesn't fail gracefully.
With debug logs enabled, you'll see this:
{{DEBUG 13:13:31,805 Unexpected state 16}}
Which seems to mean that there's a SelectionKey that's valid, but isn't ready
for reading, writing, or accepting.
Client-side, you'll get this thrift error (while trying to read a frame as
part of {{recv_batch_mutate}}):
{{TTransportException: TSocket read 0 bytes}}
--
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
[jira] [Commented] (CASSANDRA-5661) Discard pooled readers for cold data
[ https://issues.apache.org/jira/browse/CASSANDRA-5661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13714550#comment-13714550 ] Pavel Yaskevich commented on CASSANDRA-5661: Maybe that's side effect of theadlocals, i am not sure. We need recordStats() to expose some via JMX, FileCache uses separate metrics service as we track explicitly every get/release which are exposed via JMX the same way as the rest of Cassandra, i didn't do that for multiway yet but that would be a final step. Discard pooled readers for cold data Key: CASSANDRA-5661 URL: https://issues.apache.org/jira/browse/CASSANDRA-5661 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.1 Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Fix For: 2.0.1 Attachments: CASSANDRA-5661-global-multiway-cache.patch, CASSANDRA-5661.patch, DominatorTree.png, Histogram.png Reader pooling was introduced in CASSANDRA-4942 but pooled RandomAccessReaders are never cleaned up until the SSTableReader is closed. So memory use is the worst case simultaneous RAR we had open for this file, forever. We should introduce a global limit on how much memory to use for RAR, and evict old ones. -- 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
git commit: CompositeType.build is a static method
Updated Branches:
refs/heads/trunk e70490564 - 41ef86b61
CompositeType.build is a static method
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/41ef86b6
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/41ef86b6
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/41ef86b6
Branch: refs/heads/trunk
Commit: 41ef86b611fc1ebea814e4709f6dbb1688a4fae7
Parents: e704905
Author: Dave Brosius dbros...@apache.org
Authored: Sat Jul 20 18:33:00 2013 -0400
Committer: Dave Brosius dbros...@apache.org
Committed: Sat Jul 20 18:33:00 2013 -0400
--
.../org/apache/cassandra/hadoop/cql3/CqlPagingRecordReader.java| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/41ef86b6/src/java/org/apache/cassandra/hadoop/cql3/CqlPagingRecordReader.java
--
diff --git
a/src/java/org/apache/cassandra/hadoop/cql3/CqlPagingRecordReader.java
b/src/java/org/apache/cassandra/hadoop/cql3/CqlPagingRecordReader.java
index c0a6832..406d4b3 100644
--- a/src/java/org/apache/cassandra/hadoop/cql3/CqlPagingRecordReader.java
+++ b/src/java/org/apache/cassandra/hadoop/cql3/CqlPagingRecordReader.java
@@ -706,7 +706,7 @@ public class CqlPagingRecordReader extends
RecordReaderMapString, ByteBuffer,
for (int i = 0; i partitionBoundColumns.size(); i++)
keys[i] = partitionBoundColumns.get(i).value.duplicate();
-rowKey = ((CompositeType) keyValidator).build(keys);
+rowKey = CompositeType.build(keys);
}
else
{
[jira] [Updated] (CASSANDRA-5664) Improve serialization in the native protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-5664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-5664: -- Can you review [~danielnorberg]? Improve serialization in the native protocol Key: CASSANDRA-5664 URL: https://issues.apache.org/jira/browse/CASSANDRA-5664 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 2.0 Attachments: 0001-Rewrite-encoding-methods.txt, 0002-Avoid-copy-when-compressing-native-protocol-frames.txt Message serialization in the native protocol currently make a Netty's ChannelBuffers.wrappedBuffer(). The rational was to avoid copying of the values bytes when such value are biggish. This has a cost however, especially with lots of small values, and as suggested in CASSANDRA-5422, this might well be a more common scenario for Cassandra, so let's consider directly serializing in a newly allocated buffer. -- 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
[jira] [Updated] (CASSANDRA-5664) Improve serialization in the native protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-5664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-5664: -- Reviewer: danielnorberg Can you review [~danielnorberg]? Improve serialization in the native protocol Key: CASSANDRA-5664 URL: https://issues.apache.org/jira/browse/CASSANDRA-5664 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 2.0 Attachments: 0001-Rewrite-encoding-methods.txt, 0002-Avoid-copy-when-compressing-native-protocol-frames.txt Message serialization in the native protocol currently make a Netty's ChannelBuffers.wrappedBuffer(). The rational was to avoid copying of the values bytes when such value are biggish. This has a cost however, especially with lots of small values, and as suggested in CASSANDRA-5422, this might well be a more common scenario for Cassandra, so let's consider directly serializing in a newly allocated buffer. -- 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
[jira] [Resolved] (CASSANDRA-5785) Unable to bulkload data from old cluster using SSTableLoader
[ https://issues.apache.org/jira/browse/CASSANDRA-5785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-5785. - Resolution: Invalid You can't change the partitioner like that, you'll have to rewrite all the sstables with the partitioner of the cluster you intend to load them on. Unable to bulkload data from old cluster using SSTableLoader Key: CASSANDRA-5785 URL: https://issues.apache.org/jira/browse/CASSANDRA-5785 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.6 Environment: CentOs Reporter: deepti naidu Labels: SSTableLoader, SSTables Hi, I created snapshots of data from an old cluster with RandomPartitioner so that I could then transfer this data to a new cluster with Murmur3Partitioner using SSTableLoader. Instead of live streaming, I saved the SSTables created on a node in the new cluster. I get the following error when I attempt to run SSTableLoader: java.lang.IllegalStateException: SSTable first key DecoratedKey(4773451653614838302, 001519ba) last key DecoratedKey(-8904542581826997474, 0018c62f) at org.apache.cassandra.io.sstable.SSTableReader.validate(SSTableReader.java:482) at org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:206) at org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:154) at org.apache.cassandra.io.sstable.SSTableLoader$1.accept(SSTableLoader.java:100) at java.io.File.list(File.java:1010) at org.apache.cassandra.io.sstable.SSTableLoader.openSSTables(SSTableLoader.java:67) at org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:121) at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:67) -- 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
[jira] [Commented] (CASSANDRA-5515) Track sstable coldness
[
https://issues.apache.org/jira/browse/CASSANDRA-5515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13714563#comment-13714563
]
Jonathan Ellis commented on CASSANDRA-5515:
---
Either time-based throttle or sync-on-compaction seems reasonable to me.
Leaning towards the former since write:read ratio may be low.
If we're not going to take the simple approach with a map, should we keep more
data like this?
{code}
CREATE TABLE sstable_activity (
keyspace text,
columnfamily text,
generation int,
hour_ending_at timestamp,
reads int,
PRIMARY KEY ((keyspace, columnfamily, generation), hour_ending_at)
)
{code}
Delete-on-removal + TTL sounds right.
Track sstable coldness
--
Key: CASSANDRA-5515
URL: https://issues.apache.org/jira/browse/CASSANDRA-5515
Project: Cassandra
Issue Type: New Feature
Components: Core
Reporter: Jonathan Ellis
Assignee: Tyler Hobbs
Fix For: 2.0.1
Attachments: 0001-Track-row-read-counts-in-SSTR.patch
Keeping a count of reads per-sstable would allow STCS to automatically ignore
cold data rather than recompacting it constantly with hot data, dramatically
reducing compaction load for typical time series applications and others with
time-correlated access patterns. We would not need a separate age-tiered
compaction strategy.
(This will really be useful in conjunction with CASSANDRA-5514.)
--
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
[jira] [Resolved] (CASSANDRA-5783) nodetool and cassandra-cli report different information for Compaction min/max thresholds
[
https://issues.apache.org/jira/browse/CASSANDRA-5783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-5783.
---
Resolution: Not A Problem
cli is reporting the schema, which has not been modified, only temporarily
overridden.
nodetool and cassandra-cli report different information for Compaction
min/max thresholds
---
Key: CASSANDRA-5783
URL: https://issues.apache.org/jira/browse/CASSANDRA-5783
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.2.6
Reporter: Peter Haggerty
Priority: Minor
Ask cassandra-cli and nodetool the same question and get different answers
back. This was executed after using nodetool to adjust the
compactionthreshold on this CF to have a minimum of 2. The change was
observed to work as we saw increased compactions which is exactly what one
would expect
$ echo describe ${CF}; \
| cassandra-cli -h localhost -k ${KEYSPACE} \
| grep thresholds
Compaction min/max thresholds: 4/32
$ nodetool -h localhost getcompactionthreshold ${KEYSPACE} ${CF}
Current compaction thresholds for Metrics/dimensions_active_1:
min = 2, max = 32
--
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
[jira] [Comment Edited] (CASSANDRA-5661) Discard pooled readers for cold data
[ https://issues.apache.org/jira/browse/CASSANDRA-5661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13714550#comment-13714550 ] Pavel Yaskevich edited comment on CASSANDRA-5661 at 7/20/13 11:05 PM: -- Maybe that's side effect of theadlocals, i am not sure. We need recordStats() to expose some via JMX, FileCache uses separate metrics service as we track explicitly every get/release which are exposed via JMX the same way as the rest of Cassandra, i didn't do that for multiway yet but that would be a final step. Edit: I have also added onRemoval listener with the latest patch which does syscall to close the file among other things, which could have affected borrow/release latencies somehow. was (Author: xedin): Maybe that's side effect of theadlocals, i am not sure. We need recordStats() to expose some via JMX, FileCache uses separate metrics service as we track explicitly every get/release which are exposed via JMX the same way as the rest of Cassandra, i didn't do that for multiway yet but that would be a final step. Discard pooled readers for cold data Key: CASSANDRA-5661 URL: https://issues.apache.org/jira/browse/CASSANDRA-5661 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.1 Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Fix For: 2.0.1 Attachments: CASSANDRA-5661-global-multiway-cache.patch, CASSANDRA-5661.patch, DominatorTree.png, Histogram.png Reader pooling was introduced in CASSANDRA-4942 but pooled RandomAccessReaders are never cleaned up until the SSTableReader is closed. So memory use is the worst case simultaneous RAR we had open for this file, forever. We should introduce a global limit on how much memory to use for RAR, and evict old ones. -- 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
[jira] [Resolved] (CASSANDRA-5784) QueryBuilder helper method facility for function call
[
https://issues.apache.org/jira/browse/CASSANDRA-5784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-5784.
---
Resolution: Invalid
No drivers are maintained here.
QueryBuilder helper method facility for function call
-
Key: CASSANDRA-5784
URL: https://issues.apache.org/jira/browse/CASSANDRA-5784
Project: Cassandra
Issue Type: Improvement
Components: Drivers
Affects Versions: 1.0.2
Reporter: Ayhan Alkan
Labels: QueryBuilder
Adding assignment such as modifiedAt = now() or similar clause criteria which
inclues function calls (e.g t minTimeuuid('2013-02-02 10:00+') ) is not
allowed in QueryBuilder
--
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
[jira] [Commented] (CASSANDRA-5661) Discard pooled readers for cold data
[ https://issues.apache.org/jira/browse/CASSANDRA-5661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13714610#comment-13714610 ] Ben Manes commented on CASSANDRA-5661: -- I was able to reduce the EBS version down to 120us. I probably won't have it on github until tomorrow, though. Discard pooled readers for cold data Key: CASSANDRA-5661 URL: https://issues.apache.org/jira/browse/CASSANDRA-5661 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.1 Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Fix For: 2.0.1 Attachments: CASSANDRA-5661-global-multiway-cache.patch, CASSANDRA-5661.patch, DominatorTree.png, Histogram.png Reader pooling was introduced in CASSANDRA-4942 but pooled RandomAccessReaders are never cleaned up until the SSTableReader is closed. So memory use is the worst case simultaneous RAR we had open for this file, forever. We should introduce a global limit on how much memory to use for RAR, and evict old ones. -- 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
[jira] [Commented] (CASSANDRA-5661) Discard pooled readers for cold data
[ https://issues.apache.org/jira/browse/CASSANDRA-5661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13714636#comment-13714636 ] Pavel Yaskevich commented on CASSANDRA-5661: Ok, let me know and I will try to test it tomorrow. Discard pooled readers for cold data Key: CASSANDRA-5661 URL: https://issues.apache.org/jira/browse/CASSANDRA-5661 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.1 Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Fix For: 2.0.1 Attachments: CASSANDRA-5661-global-multiway-cache.patch, CASSANDRA-5661.patch, DominatorTree.png, Histogram.png Reader pooling was introduced in CASSANDRA-4942 but pooled RandomAccessReaders are never cleaned up until the SSTableReader is closed. So memory use is the worst case simultaneous RAR we had open for this file, forever. We should introduce a global limit on how much memory to use for RAR, and evict old ones. -- 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
[jira] [Updated] (CASSANDRA-5661) Discard pooled readers for cold data
[ https://issues.apache.org/jira/browse/CASSANDRA-5661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-5661: --- Attachment: CASSANDRA-5661-global-multiway-cache.patch this is updated patch which actually includes onRemoval callback. Discard pooled readers for cold data Key: CASSANDRA-5661 URL: https://issues.apache.org/jira/browse/CASSANDRA-5661 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.1 Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Fix For: 2.0.1 Attachments: CASSANDRA-5661-global-multiway-cache.patch, CASSANDRA-5661.patch, DominatorTree.png, Histogram.png Reader pooling was introduced in CASSANDRA-4942 but pooled RandomAccessReaders are never cleaned up until the SSTableReader is closed. So memory use is the worst case simultaneous RAR we had open for this file, forever. We should introduce a global limit on how much memory to use for RAR, and evict old ones. -- 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
[jira] [Updated] (CASSANDRA-5661) Discard pooled readers for cold data
[ https://issues.apache.org/jira/browse/CASSANDRA-5661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-5661: --- Attachment: (was: CASSANDRA-5661-global-multiway-cache.patch) Discard pooled readers for cold data Key: CASSANDRA-5661 URL: https://issues.apache.org/jira/browse/CASSANDRA-5661 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.1 Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Fix For: 2.0.1 Attachments: CASSANDRA-5661-global-multiway-cache.patch, CASSANDRA-5661.patch, DominatorTree.png, Histogram.png Reader pooling was introduced in CASSANDRA-4942 but pooled RandomAccessReaders are never cleaned up until the SSTableReader is closed. So memory use is the worst case simultaneous RAR we had open for this file, forever. We should introduce a global limit on how much memory to use for RAR, and evict old ones. -- 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
