Re: Thrift client creates massive amounts of network packets

ttern that's entirely driven by Titan's read pattern which appears to be > lots of tiny reads (probably not too surprising for a graph database). In > that case you probably want to go to the Titan community to see what their > recommendations are WRT performance. &g

Re: Thrift client creates massive amounts of network packets

equirements. > > On Mon, May 23, 2016 at 7:22 AM Ralf Steppacher <mailto:ralf.viva...@gmail.com>> wrote: > I remembered that Titan treats edges (and vertices?) as immutable and deletes > the entity and re-creates it on every change. > So I set the gc_grace_seconds

Re: sstableloader: Stream failed

Thanks for the hint! Indeed I could not telnet to the host. It was the listen_address that was not properly configured. Thanks again! Ralf > On 23.05.2016, at 21:01, Paulo Motta wrote: > > Can you telnet 10.211.55.8 7000? This is the port used for streaming > communication with the destinati

sstableloader: Stream failed

Hello, I am trying to load the SSTables (from a Titan graph keyspace) of a one-node-cluster (C* v2.2.6) into another node, but I cannot figure out how to properly use the sstableloader. The target keyspace and table exist in the target node. If they do not exist I get a proper error message tel

Re: Thrift client creates massive amounts of network packets

packets per user request before the compaction, the same request now results in 5’400 packets. Which is suspiciously close to a factor or 2. But I have no idea wha to make of it. Ralf > On 20.05.2016, at 15:11, Ralf Steppacher wrote: > > Hi all, > > tl:dr > The Titan 0.5

Thrift client creates massive amounts of network packets

Hi all, tl:dr The Titan 0.5.4 cassandrathrift client + C* 2.0.8/2.2.6 create massive amounts of network packets for multiget_slice queries. Is there a way to avoid the “packet storm”? Details... We are using Titan 0.5.4 with its cassandrathrift storage engine to connect to a single node clu

Re: Large number of tombstones without delete or update

or “unset” support with JSON values and > omitted columns so you can control is omitted columns have a “null” value or > an “unset” value. > > > > > From: Ralf Steppacher [mailto:ralf.viva...@gmail.com] > Sent: Thursday, March 24, 2016 11:36 AM > To: user@cassandra.a

Re: Large number of tombstones without delete or update

Jean, yes, I am using the native protocol v4 (auto-negotiated between java driver 3.0.0 and C* 2.2.4, verified by logging cluster.getConfiguration().getProtocolOptions().getProtocolVersion() ). My first approach for testing for tombstones was “brute force”. Add records and soon enough (after a

Re: Large number of tombstones without delete or update

bles in a statement must be bound. With > Protocol V4, variables can be left “unset”, in which case they will be > ignored server-side (no tombstones will be generated).” > > > From: Ralf Steppacher [mailto:ralf.viva...@gmail.com] > Sent: Thursday, March 24, 2016 11:19 AM

Re: Large number of tombstones without delete or update

I did some more tests with my particular schema/message structure: A null text field inside a UDT instance does NOT yield tombstones. A null map does NOT yield tombstones. A null text field does yield tombstones. Ralf > On 24.03.2016, at 09:42, Ralf Steppacher wrote: > > I can con

Re: Large number of tombstones without delete or update

. Why would C* not warn about the excessive number of tombstones if queried from cqlsh? Thanks! Ralf > On 23.03.2016, at 19:09, Robert Coli wrote: > > On Wed, Mar 23, 2016 at 9:50 AM, Ralf Steppacher <mailto:ralf.viva...@gmail.com>> wrote: > How come I end up with t

Re: Large number of tombstones without delete or update

s, also INSERTing a > collection (or UPDATE where you set the collection rather than append to it) > are also operations which will create tombstones. > > On Wed, Mar 23, 2016 at 12:09 PM Robert Coli <mailto:rc...@eventbrite.com>> wrote: > On Wed, Mar 23, 2016 at 9:50 AM, Ralf

Re: Large number of tombstones without delete or update

optional. Thanks! Ralf > On 23.03.2016, at 19:09, Robert Coli wrote: > > On Wed, Mar 23, 2016 at 9:50 AM, Ralf Steppacher <mailto:ralf.viva...@gmail.com>> wrote: > How come I end up with that large a number of tombstones? > > Are you inserting NULLs? > > =Rob >

Large number of tombstones without delete or update

Hi all, I started running “stress tests” against my application which writes event data to a local single-node Cassandra cluster (C* v2.2.4). After inserting a couple thousand rows (all for the same partition key) I am starting to get warnings in the C* log informing me about large numbers of t

Re: SELECT JSON timestamp lacks timezone information

a date format that would include the timezone would be > preferable here, but that is a question you should ask in the Cassandra Users > mailing list instead. > > Hope that helps, > > Alexandre > > > > > On Mon, Feb 8, 2016 at 11:09 AM Ralf Steppacher <m

SELECT JSON timestamp lacks timezone information

Hello all, When I select a timestamp as JSON from Cassandra, the string representation lacks the timezone information, both via CQLSH and the Java Driver: cqlsh:events> select toJson(created_at) AS created_at from event_by_patient_timestamp ; created_at --- "2016-01-0

Clustering key values not distributed

I am trying to get the stress tool to generate random values for three clustering keys. I am trying to simulate collecting events per user id (text, partition key). Events have a session type (text), event type (text), and creation time (timestamp) (clustering keys, in that order). For testing

Re: cassandra-stress tool - InvalidQueryException: Batch too large

hanks! > > > On Mon, Feb 1, 2016 at 5:09 AM, Ralf Steppacher <mailto:ralf.viva...@gmail.com>> wrote: > I am using Cassandra 2.2.4 and I am struggling to get the cassandra-stress > tool to work for my test scenario. I have followed the example on > http://www.datastax

cassandra-stress tool - InvalidQueryException: Batch too large

I am using Cassandra 2.2.4 and I am struggling to get the cassandra-stress tool to work for my test scenario. I have followed the example on http://www.datastax.com/dev/blog/improved-cassandra-2-1-stress-tool-benchmark-any-schema