I have had the same issue. Not an expert on this… but I think it is more a
consequence of the CentOS repo than cassandra rpm. The Oracle JVM packages are
not available and it appears you need to download (after accepting license) the
rpm and use the rpm command to install the package. Wget is al
Greetings all,
I am experiencing a strange issue where we run a compaction job weekly and
as a result, the listeners stall. This is a single node cluster running on
an i2.2xl instance in AWS. We are getting the message:
*[StorageServiceShutdownHook]*
and then:
*MessagingService has term
It comes down to licencing issues. Sun and now Oracle has always been very
particular about what they see as bundling. While they have repos for
ubuntu, redhat,centos,suse, etc. they don't allow those repos to be
installed in standard distributions unless you are paying them a fee for
doing so. Yo
Hi,
I used to have system.log writing directly to syslog and configure a
rsyslog server to get all logs from my cassandra boxes. However, the java
stack traces are a headache on my server and I read on rsyslog forums to
change application to write to a file and let rsyslog to read from that
file (
I think this essentially boils down the issue:
https://issues.apache.org/bugzilla/show_bug.cgi?id=40407
Seems the best way would be to change the umask for user cassandra:
http://stackoverflow.com/questions/7893511/permissions-on-log-files-created-by-log4j-rollingfileappender
Ken
On Mon, Jul
I have a write-heavy table that is using size tiered compaction. I am
running C* 1.2.9. There is an SSTable that is not getting compacted. It is
disproportionately larger than the other SSTables. The data file sizes are,
1.70 GB
0.18 GB
0.16 GB
0.05 GB
8.61 GB
If I set the bucket_high compaction
The current RPM spec actually has a dependency on "java", which is not a
package--rather, it is a piece of metadata called "provides" that multiple
packages can share. For example, Oracle's JVM, OpenJDK, ICedTea, etc.--can
all be used to fulfill the requirement for "java".
There is a reverse-engi
I am having an issue on multiple machines where it's simply filling up the
disk space during what I can only assume is a compaction. For example, the
average node cluster-wide is around 900GB according to DSE
OpsCenter--however, after coming in after the three day weekend, I noticed
that there wer
What are the timestamps on those SST Tables? Do those tables use TTL?
To answer your last question, I've seen that scenario happen under load
testing with column families with TTL. Large loads within the TTL window
cause normal compaction to build up larger and larger SST tables. When the
load
On Mon, Jul 7, 2014 at 9:13 AM, John Sanda wrote:
> I have a write-heavy table that is using size tiered compaction. I am
> running C* 1.2.9. There is an SSTable that is not getting compacted. It is
> disproportionately larger than the other SSTables. The data file sizes are,
>
> 1.70 GB
> 0.18 G
On Mon, Jul 7, 2014 at 9:52 AM, Redmumba wrote:
> I am having an issue on multiple machines where it's simply filling up the
> disk space during what I can only assume is a compaction. For example, the
> average node cluster-wide is around 900GB according to DSE
> OpsCenter--however, after comin
On Mon, Jul 7, 2014 at 9:52 AM, Redmumba wrote:
> Would adjusting the maximum sstables before a compaction is performed help
> this situation? I am currently using the default values provided by
> SizeTieredCompactionStrategy in C* 2.0.6. Or is there a better option for
> a continuous-write ope
On Mon, Jul 7, 2014 at 5:20 AM, Bryon Spahn wrote:
> I am experiencing a strange issue where we run a compaction job weekly and
> as a result, the listeners stall. This is a single node cluster running on
> an i2.2xl instance in AWS. We are getting the message:
>
There are almost no cases where
On Fri, Jul 4, 2014 at 4:14 AM, PRANEESH KUMAR
wrote:
>
> We are running Cassandra 1.2.16 to store data using CQl with the following
> structure.
> ...
> Is this an known issue?
>
Not to me, at least!
If you are able to consistently reproduce the issue, you should :
1) search http://issues.apa
On Fri, Jul 4, 2014 at 2:31 AM, Simon Chemouil wrote:
> I just encountered a bug with 2.1-rc1 (didn't have the chance to update
> to rc2 yet), and wondering if it's known or if I should report the issue
> on JIRA.
>
For issues in pre-release versions of Cassandra, JIRA is almost certainly
the ri
Hi,
I am using Cassandra 2.0.7 (with default settings and 16GB heap on quad core
ubuntu server with 32gb ram) and trying to ingest 1MB values using
cassandra-stress. It works fine for a while(1600secs) but after ingesting
around 120GB data, I start getting the following error:
Operation [70668
16 matches
Mail list logo
