I checked and the configuration file matched on all the nodes.
I checked `cqlsh --cqlversion "3.4.0" -u cassandra_superuser -p
my_password nodeXX 9042` with each node and finally one failed.
It had somehow not been restarted since the configuration change. It was
not responsive to `systemctl sto
Hi Leo
my guess would be that your configuration is not consistent across all nodes in
the cluster. The responses you’re seeing are totally indicative of being
connected to a node where PasswordAuthenticator is not enabled in
cassandra.yaml.
Thanks,
Sam
> On 14 Mar 2019, at 10:56, Léo FERLIN
Hello !
Recently I have noticed some clients are having errors almost every time
they try to contact my Cassandra cluster.
The error messages vary but there is one constant : *It's not constant* !
Let me show you :
>From the client host :
`cqlsh --cqlversion "3.4.0" -u cassandra_superuser -p m
A quick update on this issue.
Today, when playing with UDA, I had also the exception:
java.security.AccessControlException: access denied
("java.io.FilePermission" "/x/logback.xml" "read")"
What is definitely strange is that by re-executing again the query, same
query, it works. I cou
>
>
> 1. Is it possible to "tune" the page size or is it hard-coded internally ?
>
If a page size is set for the request at the driver level, that page size
will be used internally. Otherwise, it defaults to something reasonable
(probably ~5k rows).
> 2. Is read-repair performed on EACH page or
There is nothing in the system.log when the aggregation query fails.
Thanks for the Datastax clarification.
Thanks,
Dinesh.
On 12/24/2015 2:46 PM, DuyHai Doan wrote:
The exception stack trace at client side shows some issue with File
Permission. Try to look for the same error message in syste
The exception stack trace at client side shows some issue with File
Permission. Try to look for the same error message in system.log to chase
down the root issue.
"Would trying the Datastax distribution offer any better chances?" --> No,
DSC is just a packaging of C* OSS
On Thu, Dec 24, 2015 at 7
Even if aggregation that forces a full table scan across partitions is
not recommended, the message/exception does seems unrelated to partitioning:
cqlsh:flightdata> select late_flights(uniquecarrier, depdel15) from
flightsbydate in ('2015-09-15', '2015-09-16',
'2015-09-17', '2015-09-
Thanks for the pointer on internal paging Tyler, I missed this one. But
then it raises some questions:
1. Is it possible to "tune" the page size or is it hard-coded internally ?
2. Is read-repair performed on EACH page or is it done on the whole
requested rows once they are fetched ?
Question 2.
[mailto:sn...@snazy.de]
Sent: Wednesday, December 23, 2015 12:15 PM
To: user@cassandra.apache.org
Cc: dinesh.shanb...@isanasystems.com
Subject: Re: Cassandra 3.1 - Aggregation query failure
Well, the usual access goal for queries in C* is “one partition per query” -
maybe a handful partitions in some
ad.com>]
> Sent: Monday, December 21, 2015 2:50 PM
> To: user@cassandra.apache.org <mailto:user@cassandra.apache.org>;
> dinesh.shanb...@isanasystems.com <mailto:dinesh.shanb...@isanasystems.com>
> Subject: Re: Cassandra 3.1 - Aggregation query failure
>
> Even if
...@jonhaddad.com]
Sent: Monday, December 21, 2015 2:50 PM
To: user@cassandra.apache.org; dinesh.shanb...@isanasystems.com
Subject: Re: Cassandra 3.1 - Aggregation query failure
Even if you get this to work for now, I really recommend using a different
tool, like Spark. Personally I wouldn't use
Even if you get this to work for now, I really recommend using a different
tool, like Spark. Personally I wouldn't use UDAs outside of a single
partition.
On Mon, Dec 21, 2015 at 1:50 AM Dinesh Shanbhag <
dinesh.shanb...@isanasystems.com> wrote:
>
> Thanks for the pointers! I edited jvm.options
Thanks for the pointers! I edited jvm.options in
$CASSANDRA_HOME/conf/jvm.options to increase -Xms and -Xmx to 1536M.
The result is the same.
And in $CASSANDRA_HOME/logs/system.log, grep GC system.log produces this
(when jvm.options had not been changed):
INFO [Service Thread] 2015-12-1
On Fri, Dec 18, 2015 at 9:17 AM, DuyHai Doan wrote:
> Cassandra will perform a full table scan and fetch all the data in memory
> to apply the aggregate function.
Just to clarify for others on the list: when executing aggregation
functions, Cassandra *will* use paging internally, so at most one
Hello
There are 2 details that are important here:
1. The node has only 4Gb of RAM
2. However, the aggregation on all ~45 rows always fails, sometimes
immediately, sometimes after 30-60 seconds:
The consequence of point 1 is that the JVM Heap size is small: 1Gb
The formulae to compute max
I am trying out Aggregations in a single node Cassandra 3.1
installation. The node has 4GB RAM. The table being aggregated on
contains ~45 rows. It contains information on US domestic flights
for a single month (from
http://www.transtats.bts.gov/DL_SelectFields.asp?Table_ID=236&DB_Sho
17 matches
Mail list logo
