Displaying #cassandra-dev/2016-10-25.log:

Tue Oct 25 00:20:33 2016  clohfink:Joined the channel
Tue Oct 25 00:21:50 2016  mebigfatguy:Joined the channel
Tue Oct 25 00:37:42 2016  adamholmberg:Joined the channel
Tue Oct 25 00:52:30 2016  minimarcel__:Joined the channel
Tue Oct 25 01:01:33 2016  RussSpitzer:Joined the channel
Tue Oct 25 01:40:45 2016  mstepura:Joined the channel
Tue Oct 25 02:09:08 2016  clohfink:Joined the channel
Tue Oct 25 02:13:28 2016  dikang:Joined the channel
Tue Oct 25 02:19:44 2016  exlt:thanks for the #12815 commit stef1927 - looks like the last one tagged for 3.10 :)
Tue Oct 25 02:19:45 2016  CassBotJr:https://issues.apache.org/jira/browse/CASSANDRA-12815 (Resolved; Fixed; 3.10): "cqlsh may throw AttributeError due to no table metadata"
Tue Oct 25 02:20:42 2016  stef1927:sure :)
Tue Oct 25 02:24:57 2016  dikang:Joined the channel
Tue Oct 25 02:54:09 2016  mstepura:Joined the channel
Tue Oct 25 03:33:25 2016  zznate:anybody have time to commit CASSANDRA-12689 today?
Tue Oct 25 03:33:26 2016  CassBotJr:https://issues.apache.org/jira/browse/CASSANDRA-12689 (Awaiting Feedback; Unresolved; 3.0.x, 3.x): "All MutationStage threads blocked, kills server"
Tue Oct 25 03:50:34 2016  mstepura:Joined the channel
Tue Oct 25 04:12:54 2016  mstepura:Joined the channel
Tue Oct 25 04:25:47 2016  mstepura:Joined the channel
Tue Oct 25 04:50:59 2016  clohfink:Joined the channel
Tue Oct 25 05:34:32 2016  mstepura:Joined the channel
Tue Oct 25 05:42:14 2016  tjake:Joined the channel
Tue Oct 25 07:32:05 2016  spodkowinski:Joined the channel
Tue Oct 25 08:16:53 2016  gila:Joined the channel
Tue Oct 25 08:20:15 2016  kvaster_:Joined the channel
Tue Oct 25 08:27:05 2016  minimarcel__:Joined the channel
Tue Oct 25 08:28:22 2016  gila:Joined the channel
Tue Oct 25 09:52:25 2016  RobertBirnie:Joined the channel
Tue Oct 25 11:17:05 2016  clohfink:Joined the channel
Tue Oct 25 11:38:16 2016  clohfink:Joined the channel
Tue Oct 25 12:00:25 2016  adamholmberg:Joined the channel
Tue Oct 25 12:55:07 2016  vans01_:Joined the channel
Tue Oct 25 13:12:53 2016  jmckenzie:Joined the channel
Tue Oct 25 13:14:28 2016  jmckenzie_:Joined the channel
Tue Oct 25 13:27:19 2016  adamholmberg:Joined the channel
Tue Oct 25 13:39:28 2016  clohfink:Joined the channel
Tue Oct 25 14:46:28 2016  jmckenzie_:Joined the channel
Tue Oct 25 15:25:14 2016  ArrgntBstrd:Joined the channel
Tue Oct 25 15:31:25 2016  thobbs:Joined the channel
Tue Oct 25 15:35:29 2016  exlt:https://issues.apache.org/jira/browse/INFRA-12823
Tue Oct 25 15:35:56 2016  jmckenzie_:Joined the channel
Tue Oct 25 16:24:38 2016  lukerb:Joined the channel
Tue Oct 25 16:28:45 2016  mstepura:Joined the channel
Tue Oct 25 16:39:51 2016  dikang:Joined the channel
Tue Oct 25 17:24:42 2016  lukerb:Joined the channel
Tue Oct 25 17:36:49 2016  lukerb:Hi, I have a question about the use of transformations within ReadCommand...
Tue Oct 25 17:37:17 2016  lukerb:It looks like the coordinator gets UnfilteredPartitionIterators with DataResolver, performing read repair and then filtering out deletions, all of which happens before any cql3.functions are applied?
Tue Oct 25 17:38:09 2016  lukerb:I gather the ReadCommand shouldn't make exotic transformations (localized "functions") to its data--because of the CL reconciliation and read repair... unless StorageProxy knows about it? I'm picturing a transformation (referentially transparent) in ReadCommand that's toggled: on for the initial queries (data & digest), and then toggled off for the DataResolver retry.
Tue Oct 25 17:39:16 2016  lukerb:Assuming the transformation is a pure function over UnfilteredPartitionIterator, the digests would reconcile if the underlying data reconciles. When it doesn't, the retry would leave out that transformation and work with the actual rows that were queried for it.
Tue Oct 25 17:40:36 2016  lukerb:Does this make sense? The replica-local function would have to contend with an unfiltered iterator, but otherwise I don't see a problem, and it looks like it might be a straightforward insertion into the code base for native functions, especially given the existing Transformation framework.
Tue Oct 25 17:42:31 2016  lukerb:Basically wondering what this kind of change might break. :) Obviously cql3/driver change to use it, but it could easily be done as a non-breaking change for existing callers.
Tue Oct 25 17:56:21 2016  jmckenzie:Joined the channel
Tue Oct 25 19:03:39 2016  dikang:Joined the channel
Tue Oct 25 19:04:11 2016  kvaster_:Joined the channel
Tue Oct 25 19:13:14 2016  mstepura:Joined the channel
Tue Oct 25 19:37:18 2016  kvaster_:Joined the channel
Tue Oct 25 19:37:38 2016  rustyrazorblade_:Joined the channel
Tue Oct 25 19:47:11 2016  lukerb:I walked through the data resolver path for reads and think I see that it kicks that off with the full data from one of the replicas, sent along as part of the message to other endpoints to resolve.
Tue Oct 25 19:47:45 2016  lukerb:I started to compare that with the code for 'nodetool repair' -- are these repairs different, i.e. separate implementations?
Tue Oct 25 19:48:24 2016  ptnapoleon:Read repairs vs. proper nodetool repairs?
Tue Oct 25 19:48:30 2016  ptnapoleon:Yes, I am fairly sure those are different implementations
Tue Oct 25 19:49:11 2016  lukerb:gotcha - thanks!
Tue Oct 25 20:04:10 2016  jeffj:lukerb: read path blocks for N responses (N set by consistency level), and then compares them. of those N, 1 will be a full response, the other (N-1) will be digests. On digetst mismatch, read repair will reconcile, which is where the full data comes from in that path.
Tue Oct 25 20:04:45 2016  jeffj:lukerb: the nodetool repair is a very different path
Tue Oct 25 20:15:26 2016  lukerb:jeffj: thank you. I was dreaming up an idea for preemptively transforming a full response on the replica nodes, but I expect the read repair path is built on the assumption that it has actual partition/row data (probably sounds like a strange comment), so I'd have to requery the actual underlying data for RR, which would defeat my purpose of running a function directly on the replicas..
Tue Oct 25 20:19:27 2016  lukerb:..so I'd forgo RR as a trade-off for that capability. Not sure that's a good idea either.. maybe that's why this capability isn't built in already? :) I see that sequence kicked off in StorageProxy.fetchRows() .. I'm about to check whether there's a simple way to dynamically disable RR
Tue Oct 25 20:19:48 2016  jeffj:ok, high level
Tue Oct 25 20:19:51 2016  jeffj:there are two types of RR
Tue Oct 25 20:20:01 2016  jeffj:one triggered by probability set at the table level - you can set that to 0
Tue Oct 25 20:20:26 2016  jeffj:probabilistic RR is background, non-blocking, after the client has the response
Tue Oct 25 20:20:59 2016  jeffj:the other - foreground/blockign RR is only done if there's a mismatch, and the easiest/only way to avoid it is to not mismatch, meaning don't query enough nodes to find out you mismatch
Tue Oct 25 20:21:46 2016  dikang:Joined the channel
Tue Oct 25 20:57:27 2016  dikang:Joined the channel
Tue Oct 25 21:00:44 2016  kvaster_:Joined the channel
Tue Oct 25 21:16:33 2016  lukerb:Left the channel
Tue Oct 25 21:26:37 2016  kvaster_:Joined the channel
Tue Oct 25 21:26:51 2016  mstepura:Joined the channel
Tue Oct 25 21:32:13 2016  dikang:Joined the channel
Tue Oct 25 21:37:03 2016  kvaster_:Joined the channel
Tue Oct 25 21:39:38 2016  dikang:Joined the channel
Tue Oct 25 21:44:08 2016  mstepura:Joined the channel
Tue Oct 25 21:48:45 2016  kvaster:Joined the channel
Tue Oct 25 21:49:23 2016  minimarcel__:Joined the channel
Tue Oct 25 22:03:22 2016  dikang:Joined the channel
Tue Oct 25 22:32:49 2016  minimarcel__:Joined the channel
Tue Oct 25 22:47:13 2016  dikang:Joined the channel
Tue Oct 25 23:33:27 2016  mstepura:Joined the channel

Comments