[GitHub] cassandra pull request #91: Fix broken SASI diagrams from PR #90

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/cassandra/pull/91


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cassandra issue #90: Update SASI.md

[joaquincasares]

Github user joaquincasares commented on the issue:

https://github.com/apache/cassandra/pull/90
  
Super sorry for the delay! I edited the file in Github and didn't realize 
that the text was correct and that Github does not use a monospaced font!

I've submitted #91 to fix the issues. Thanks for pointing it out @ifesdjeen 
!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cassandra pull request #91: Fix broken SASI diagrams from PR #90

[joaquincasares]

GitHub user joaquincasares opened a pull request:

https://github.com/apache/cassandra/pull/91

Fix broken SASI diagrams from PR #90

Addressing the regressions on #90.

I was modifying in Github's view and didn't realize the text was correct 
and Github's view does not use a monospaced font.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/joaquincasares/cassandra Fix-PR-90

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cassandra/pull/91.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #91


commit 34cb35f001d9b9cb32e1116ca09bc5d9bb42f45f
Author: Joaquin Casares 
Date:   2017-01-28T00:24:12Z

Fix broken SASI diagrams from PR #90




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: tracing improvements

[Nate McCall]

I do miss this from other RDBMSs. If you could come up with a
light-touch way to do this, I think a lot of people would be quite
happy about it.

On Wed, Jan 25, 2017 at 2:02 PM, Corentin Chary
 wrote:
> On Wed, Jan 25, 2017 at 9:55 PM, Sam Overton  wrote:
>> Hello cassandra-dev,
>>
>> I would like to continue the momentum on improving Cassandra's tracing,
>> following Mick's excellent work on pluggable tracing and Zipkin support.
>>
>> There are a couple of areas we can improve that would make tracing an even
>> more
>> useful tool for cluster operators to diagnose ongoing issues.
>>
>> The control we currently have over tracing is coarse and somewhat
>> cumbersome.
>> Enabling tracing from the client for a specific query is fine for
>> application
>> developers, particularly in an environment where Zipkin is being used to
>> trace
>> all parts of the system and show an aggregated view. For an operator
>> investigating an issue however, this does not always give us the control
>> that we
>> need in order to obtain relevant data. We often need to diagnose an issue
>> without the possibility of making any changes in the client, and often
>> without
>> the prior knowledge of which queries at the application level are
>> experiencing
>> poor performance.
>>
>> Our only other instigator of tracing is nodetool settraceprobability which
>> only
>> affects a single node and gives us no control over precisely which queries
>> get
>> traced. In practise, it is very difficult to find the relevant queries that
>> we
>> want to investigate, so we have often resorted to bulk loading the traces
>> into
>> an external tool for analysis, and this seems sub-optimal when cassandra
>> could
>> reduce much of the friction.
>>
>> I have a few proposals to improve tracing that I'd like to throw out to
>> the mailing list to get feedback before I start implementing.
>>
>> 1. Include trace_probability as a CF level property, so sampled tracing can
>> be
>> enabled on a per-CF basis, cluster-wide, by changing the CF property.
>> https://issues.apache.org/jira/browse/CASSANDRA-13154
>>
>> 2. Allow tracing at the CFS level. If we have a misbehaving host, then it
>> would
>> be useful to enable sampled tracing at the CFS layer on just that host so
>> that
>> we can investigate queries landing on that replica, rather than just queries
>> passing through as a coordinator as is currently possible.
>> https://issues.apache.org/jira/browse/CASSANDRA-13155
>>
>> 3. Add an interface allowing for custom filters which can decide whether
>> tracing
>> should be enabled for a given query. This is a similar idea to
>> CASSANDRA-9193
>> [1] but following the same pattern that we have for IAuthenticator,
>> IEndpointSnitch, ConfigurationLoader et al. where the intention is that
>> useful
>> default implementations are provided, but abstracted in such a way that
>> custom
>> implementations can be written for deployments where a specific type of
>> functionality is required. This would then allow solutions such as
>> CASSANDRA-11012 [2] without any specific support needing to be written in
>> Cassandra.
>> https://issues.apache.org/jira/browse/CASSANDRA-13156
>>
>> Thanks for reading!
>> Regards,
>>
>> Sam
>>
>>
>> [1] https://issues.apache.org/jira/browse/CASSANDRA-9193 Facility to write
>> dynamic
>> code to selectively trigger trace or log for queries
>>
>> [2] https://issues.apache.org/jira/browse/CASSANDRA-11012 Allow tracing CQL
>> of a
>> specific client only, based on IP (range)
>
> Not directly related, but to make (3) more useful it would also be
> great to be able to list currently executing queries. I've had
> multiple cases where read queries would just use all my slots and
> never finish and it was quite painful to discover what the query was
> exactly (slow query don't help if the query never finishes).
>
>
> --
> Corentin Chary
> http://xf.iksaif.net

Re: tracing improvements

[Nate McCall]

I think all three of these have merit. Per-CF tracing would be the
most immediately useful (and likely least impactful).

For #3, I like the interface approach over exposing internal APIs. You
can sort of kind of do this with custom QueryProcessor, but having
something specific to tracing would be nice.

Thanks for opening these!

On Wed, Jan 25, 2017 at 12:55 PM, Sam Overton  wrote:
> Hello cassandra-dev,
>
> I would like to continue the momentum on improving Cassandra's tracing,
> following Mick's excellent work on pluggable tracing and Zipkin support.
>
> There are a couple of areas we can improve that would make tracing an even
> more
> useful tool for cluster operators to diagnose ongoing issues.
>
> The control we currently have over tracing is coarse and somewhat
> cumbersome.
> Enabling tracing from the client for a specific query is fine for
> application
> developers, particularly in an environment where Zipkin is being used to
> trace
> all parts of the system and show an aggregated view. For an operator
> investigating an issue however, this does not always give us the control
> that we
> need in order to obtain relevant data. We often need to diagnose an issue
> without the possibility of making any changes in the client, and often
> without
> the prior knowledge of which queries at the application level are
> experiencing
> poor performance.
>
> Our only other instigator of tracing is nodetool settraceprobability which
> only
> affects a single node and gives us no control over precisely which queries
> get
> traced. In practise, it is very difficult to find the relevant queries that
> we
> want to investigate, so we have often resorted to bulk loading the traces
> into
> an external tool for analysis, and this seems sub-optimal when cassandra
> could
> reduce much of the friction.
>
> I have a few proposals to improve tracing that I'd like to throw out to
> the mailing list to get feedback before I start implementing.
>
> 1. Include trace_probability as a CF level property, so sampled tracing can
> be
> enabled on a per-CF basis, cluster-wide, by changing the CF property.
> https://issues.apache.org/jira/browse/CASSANDRA-13154
>
> 2. Allow tracing at the CFS level. If we have a misbehaving host, then it
> would
> be useful to enable sampled tracing at the CFS layer on just that host so
> that
> we can investigate queries landing on that replica, rather than just queries
> passing through as a coordinator as is currently possible.
> https://issues.apache.org/jira/browse/CASSANDRA-13155
>
> 3. Add an interface allowing for custom filters which can decide whether
> tracing
> should be enabled for a given query. This is a similar idea to
> CASSANDRA-9193
> [1] but following the same pattern that we have for IAuthenticator,
> IEndpointSnitch, ConfigurationLoader et al. where the intention is that
> useful
> default implementations are provided, but abstracted in such a way that
> custom
> implementations can be written for deployments where a specific type of
> functionality is required. This would then allow solutions such as
> CASSANDRA-11012 [2] without any specific support needing to be written in
> Cassandra.
> https://issues.apache.org/jira/browse/CASSANDRA-13156
>
> Thanks for reading!
> Regards,
>
> Sam
>
>
> [1] https://issues.apache.org/jira/browse/CASSANDRA-9193 Facility to write
> dynamic
> code to selectively trigger trace or log for queries
>
> [2] https://issues.apache.org/jira/browse/CASSANDRA-11012 Allow tracing CQL
> of a
> specific client only, based on IP (range)

Re: [VOTE] Release Apache Cassandra 3.10 (Take 4)

[Michael Shuler]

Thanks, Sylvain!

-- 
Michael

On 01/27/2017 02:33 AM, Sylvain Lebresne wrote:
> Fyi, I just committed CASSANDRA-13025 so it's ready for a re-roll as far as
> I can tell.
> 
> On Tue, Jan 24, 2017 at 12:31 AM, Michael Shuler 
> wrote:
> 
>> This vote is being failed for CASSANDRA-13058 (committed after tentative
>> tag) and CASSANDRA-13025 (patch available).
>>
>> Vote count was 5 binding +1, 1 binding -1, and one non-binding -1.
>>
>> I'll re-roll a "Take 5" when CASSANDRA-13025 gets committed, tests
>> appear stable, and we'll try again.
>>
>> --
>> Kind regards,
>> Michael
>>
>> On 01/13/2017 06:46 PM, Michael Shuler wrote:
>>> I propose the following artifacts for release as 3.10.
>>>
>>> sha1: 9c2ab25556fad06a6a4d58f4bb652719a8a1bc27
>>> Git:
>>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
>> shortlog;h=refs/tags/3.10-tentative
>>> Artifacts:
>>> https://repository.apache.org/content/repositories/
>> orgapachecassandra-1136/org/apache/cassandra/apache-cassandra/3.10/
>>> Staging repository:
>>> https://repository.apache.org/content/repositories/
>> orgapachecassandra-1136/
>>>
>>> The Debian packages are available here: http://people.apache.org/~
>> mshuler
>>>
>>> The vote will be open for 72 hours (longer if needed).
>>>
>>> [1]: (CHANGES.txt) https://goo.gl/WaAEVn
>>> [2]: (NEWS.txt) https://goo.gl/7deAsG
>>>
>>> All of the unit tests passed and the main dtest job passed.
>>>
>>> https://cassci.datastax.com/job/cassandra-3.11_testall/47/
>>> https://cassci.datastax.com/job/cassandra-3.11_utest/55/
>>> https://cassci.datastax.com/job/cassandra-3.11_utest_cdc/25/
>>> https://cassci.datastax.com/job/cassandra-3.11_utest_compression/23/
>>> https://cassci.datastax.com/job/cassandra-3.11_dtest/31/
>>>
>>
>>
>>
> 

Re: [VOTE] Release Apache Cassandra 3.10 (Take 4)

[Sylvain Lebresne]

Fyi, I just committed CASSANDRA-13025 so it's ready for a re-roll as far as
I can tell.

On Tue, Jan 24, 2017 at 12:31 AM, Michael Shuler 
wrote:

> This vote is being failed for CASSANDRA-13058 (committed after tentative
> tag) and CASSANDRA-13025 (patch available).
>
> Vote count was 5 binding +1, 1 binding -1, and one non-binding -1.
>
> I'll re-roll a "Take 5" when CASSANDRA-13025 gets committed, tests
> appear stable, and we'll try again.
>
> --
> Kind regards,
> Michael
>
> On 01/13/2017 06:46 PM, Michael Shuler wrote:
> > I propose the following artifacts for release as 3.10.
> >
> > sha1: 9c2ab25556fad06a6a4d58f4bb652719a8a1bc27
> > Git:
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> shortlog;h=refs/tags/3.10-tentative
> > Artifacts:
> > https://repository.apache.org/content/repositories/
> orgapachecassandra-1136/org/apache/cassandra/apache-cassandra/3.10/
> > Staging repository:
> > https://repository.apache.org/content/repositories/
> orgapachecassandra-1136/
> >
> > The Debian packages are available here: http://people.apache.org/~
> mshuler
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: (CHANGES.txt) https://goo.gl/WaAEVn
> > [2]: (NEWS.txt) https://goo.gl/7deAsG
> >
> > All of the unit tests passed and the main dtest job passed.
> >
> > https://cassci.datastax.com/job/cassandra-3.11_testall/47/
> > https://cassci.datastax.com/job/cassandra-3.11_utest/55/
> > https://cassci.datastax.com/job/cassandra-3.11_utest_cdc/25/
> > https://cassci.datastax.com/job/cassandra-3.11_utest_compression/23/
> > https://cassci.datastax.com/job/cassandra-3.11_dtest/31/
> >
>
>
>