Re: timeoutexceptions with UDF causing cassandra forceful exits

Beside the config of user_function_timeout_policy, I would say having an UDF that times out badly is generally an indication that you should review your UDF code On Mon, Jul 3, 2017 at 7:58 PM, Jeff Jirsa wrote: > > > On 2017-06-29 17:00 (-0700), Akhil Mehra

Re: UDF for sorting

While you can't do this with Cassandra, you can get the functionality you want with the cassandra-lucene-plugin ( https://github.com/Stratio/cassandra-lucene-index/blob/branch-3.0.10/doc/documentation.rst#searching ). Keep in mind that as with any secondary index there are performance-related

Re: UDF for sorting

Plain answer is no you can't The reason is that UDF only transform column values on each row but does not have the ability to modify rows ordering On Mon, Jul 3, 2017 at 10:14 PM, techpyaasa . wrote: > Hi all, > > I have a table like > > CREATE TABLE ks.cf ( pk1 bigint,

UDF for sorting

Hi all, I have a table like CREATE TABLE ks.cf ( pk1 bigint, cc1 bigint, disp_name text , stat_obj text, status int, PRIMARY KEY (pk1, cc1)) WITH CLUSTERING ORDER BY (cc1 ASC) CREATE INDEX idx1 on ks.cf(status); I want to have a queries like *select * from ks.cf where pk1=123

Re: Node failure Due To Very high GC pause time

This is a very antagonistic use case for Cassandra :P I assume you're familiar with Cassandra and deletes? (eg. http://thelastpickle.com/blog/2016/07/27/about-deletes-and-tombstones.html, http://docs.datastax.com/en/cassandra/2.1/cassandra/dml/dml_about_deletes_c.html ) That being said, are you

Node failure Due To Very high GC pause time

Hi, Recently In my test Cluster I faced a outrageous GC activity which made the Node unreachable inside the cluster itself. Scenario : In a Partition of 5Million rows we read first 500 (by giving the starting range) and delete the same 500 again.The same has been done

False positive increasing

Hello Lately I am observing that the false positives of one of my nodes are increasing in a continous way (1 per 5min) Bloom filter false positives: 532 Bloom filter false ratio: 0.01449 Bloom filter space used: 1.34 MB Bloom filter off heap memory used: 1.33 MB At the

RE: Node failure Due To Very high GC pause time

>> here my is doubt is that does all the deleted 3.3Million row will be >> loaded in my on-heap memory? if not what will be object that occupying those >> memory ? It depends on your queries what data they’re fetching from your database. Assuming you’re using CMS garbage

Re: False positive increasing

Jeff is probably correct. I skimmed over the fact that it's just increasing by one every few minutes so I went on about a different scenario. On Mon, Jul 3, 2017, at 01:46 PM, Jeff Jirsa wrote: > > > On 2017-07-03 06:55 (-0700), Jean Carlo > wrote: > > Hello > > >

Re: Node failure Due To Very high GC pause time

Hi Bryan, Thanks for your quick response. We have already tuned our memory and GC based on our hardware specification and it was working fine until yesterday, i.e before facing the below specified delete request. As you specified we will once again look into our GC memory

Re: False positive increasing

Hi, The number of false positives may be increasing because more filters are being consulted on each query. The number of filters consulted on each query is a function of number of sstables consulted. You may be seeing an increase in number of tables consulted if compaction is falling behind. I'm

Re: False positive increasing

On 2017-07-03 06:55 (-0700), Jean Carlo wrote: > Hello > > Lately I am observing that the false positives of one of my nodes are > increasing in a continous way (1 per 5min) > There's probably one partition that has a false positive entry, and you read it once

Re: timeoutexceptions with UDF causing cassandra forceful exits

On 2017-06-29 17:00 (-0700), Akhil Mehra wrote: > By default user_function_timeout_policy is set to die i.e. warn and kill the > JVM. Please find below a source code snippet that outlines possible setting. (Which also means you can set user_function_timeout_policy to

Re: jbod disk usage unequal

On 2017-06-29 06:55 (-0700), Micha wrote: > Hi, > > I use a jbod setup (2 * 1TB) and the distribution is a little bit > unequal on my three nodes: > 270MB and 540MB > 150 and 580 > 290 and 500 > > SStable size varies between 2GB and 130GB. > You're switching between