Re: Debug logging enabled by default since 2.2

[Mick Semb Wever]

> For this reason I'm more in favor of converting the debug.log into
async/verbose_system.log as suggested by Jeremiah and use a marker to
direct these logs (former DEBUG level logs) to that log instead.


+1

Thanks for the inclusive and considerate summary Paulo, and for the
suggestion that moves us forward Jeremiah.


> From the discussion here it seems that many would like to change how this
works.  Rather
than just turning off the debug.log I would propose that we switch to using
the SLF4J
MARKER[1] ability to move the messages back to INFO but tag them as
belonging to
the asynchronous_system.log rather than the normal system.log.


>  In a way the real issue might be that we don’t have nightly performance
runs that would make an accidentally introduced debug statement obvious.
> A log statement that runs once or more per read or write should be easy
to spot.


+1
Could we not put in an assertion into the dtests that fails if any
query-path DEBUG statements appear?
This would enforce the Logging Guidelines.

And those Logging Guidelines should be moved to the in-tree docs.

Mick


On 20 March 2018 at 05:51, Paulo Motta  wrote:

> Thanks for the constructive input and feedback! From this discussion
> it seems like overloading the DEBUG level to signify
> async-verbose-INFO on CASSANDRA-10241 is leading to some confusion and
> we should fix this.
>
> However, we cannot simply turn debug.log off as during CASSANDRA-10241
> some verbose-but-useful-info-logs, such as flush information were
> changed from INFO to DEBUG, and since the patch has been in for nearly
> 3 years it's probably non-revertable. Furthermore, the practice of
> using the DEBUG level for logging non-debug stuff has been in our
> Logging Guidelines
> (https://wiki.apache.org/cassandra/LoggingGuidelines) since then, so
> there is probably useful DEBUG stuff that would need to be turned into
> INFO if we get rid of debug.log.
>
> For this reason I'm more in favor of converting the debug.log into
> async/verbose_system.log as suggested by Jeremiah and use a marker to
> direct these logs (former DEBUG level logs) to that log instead.
> Nevertheless, if the majority prefers to get back to a single
> system.log file and get rid of debug.log/verbose_system.log altogether
> then we would need to go through all log usages and readjust them to
> use the proper logging levels and update our logging guidelines to
> reflect whatever new policy is decided, not only disabling debug.log
> and call it a day.
>
> 2018-03-19 12:02 GMT-03:00 Jeremiah D Jordan :
> > People seem hung up on DEBUG here.  The goal of CASSANDRA-10241 was
> > to clean up the system.log so that it a very high “signal” in terms of
> what was logged
> > to it synchronously, but without reducing the ability of the logs to
> allow people to
> > solve problems and perform post mortem analysis of issues.  We have
> informational
> > log messages that are very useful to understanding the state of things,
> like compaction
> > status, repair status, flushing, or the state of gossip in the system
> that are very useful to
> > operators, but if they are all in the system.log make said log file
> harder to look over for
> > issues.  In 10241 the method chosen for how to keep these log messages
> around by
> > default, but get them out of the system.log was that these messages were
> changed from
> > INFO to DEBUG and the new debug.log was created.
> >
> > From the discussion here it seems that many would like to change how
> this works.  Rather
> > than just turning off the debug.log I would propose that we switch to
> using the SLF4J
> > MARKER[1] ability to move the messages back to INFO but tag them as
> belonging to
> > the asynchronous_system.log rather than the normal system.log.
> >
> > [1] https://logback.qos.ch/manual/layouts.html#marker <
> https://logback.qos.ch/manual/layouts.html#marker>
> > https://www.slf4j.org/faq.html#fatal  html#fatal>
> >
> >
> >> On Mar 19, 2018, at 9:01 AM, Stefan Podkowinski 
> wrote:
> >>
> >> I'd agree that INFO should be the default. Turning on the DEBUG logging
> >> can cause notable performance issues and I would not enable it on
> >> production systems unless I really have to. That's why I created
> >> CASSANDRA-12696 for 4.0, so you'll be able to at least only partially
> >> enable DEBUG based on what's relevant to look at, e.g. `nodetool
> >> setlogginglevel bootstrap DEBUG`.
> >>
> >> But small improvements like that won't change the fact that log files
> >> suck in general for more complex analysis, except for trivial tailing
> >> and grepping. You have to make sure that logging is enabled and old
> >> records you're interested in will not be rotated out. Then you have to
> >> gather log files from individual nodes somehow. Eventually I end up with
> >> a local tarball with logs in that situation and the fun starts creating
> >> hacky, regex loaded 

Re: RE: how to fix constantly getting out of memory (3.11)

[Jay Zhuang]

 Hi,
For CASSANDRA-13929, The patch is available for review. Anyone interested in 
reviewing it?
Thanks,Jay
On Tuesday, December 12, 2017, 5:02:14 AM PST, Steinmaurer, Thomas 
 wrote:  
 
 Hi,

if you are talking about on-heap troubles, then the following might be related 
in 3.11.x:
https://issues.apache.org/jira/browse/CASSANDRA-13929

Thomas

-Original Message-
From: Micha [mailto:mich...@fantasymail.de]
Sent: Dienstag, 12. Dezember 2017 09:24
To: dev@cassandra.apache.org
Subject: how to fix constantly getting out of memory (3.11)

Hi,

I have seven nodes, debian stretch with c*3.11, each with 2TB disk (500G free), 
32G Ram.
I have a keyspace with seven tables. At the moment the cluster doesn't work at 
all reliably. Every morning at least 2 nodes are shut down due to out of 
memory. Repair afterwards fails with "some repair failed".
I use G1 with 16G heap on 6 six nodes and cms with 8G heap on one node to see a 
difference. In munin it's easy to see a constantly rising memory consumption. 
There are no other services running. I cannot understand who is not releasing 
the memory.
Some tables have some big rows (as mentioned in my last mail to the list). Can 
this be a source of the memory consumption?

How do you track down this?  Is there memory which doesn't get released and 
accumulates over time? I have not yet debugged such gc/memory issues.

cheers
 Michael


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a 
company registered in Linz whose registered office is at 4040 Linz, Austria, 
Freistädterstraße 313

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

  

RE: A JIRA proposing a seperate repository for the online documentation

[Kenneth Brotman]

I've been trying to withdraw from the conversation since Friday.

-Original Message-
From: Josh McKenzie [mailto:jmcken...@apache.org] 
Sent: Monday, March 19, 2018 9:56 AM
To: dev@cassandra.apache.org
Subject: Re: A JIRA proposing a seperate repository for the online documentation

And to be explicit about this: I'm going to withdraw from this conversation 
now. I don't think we're generating sufficient signal in this dialog compared 
to the noise.

Thanks for the enthusiasm and input Kenneth.

On Mon, Mar 19, 2018 at 11:48 AM, Josh McKenzie 
wrote:

> You missed the point ...  let them do it their way when it makes no
>> difference
>
> If you're suggesting we use a static markdown based generator as the 
> "go to" method for content generation and accept PR's for "New 
> Hotness" (do it their way), then sure, that seems a totally fair 
> compromise. Pretty sure that's not what you're suggesting, and people 
> Wild Westing a contribution to a project, that the project then owns 
> when you get bored of it and move on, doesn't qualify for "makes no 
> difference".
>
> On Mon, Mar 19, 2018 at 11:10 AM, Kenneth Brotman < 
> kenbrot...@yahoo.com.invalid> wrote:
>
>> You missed the point.  If someone can do a good job on something, 
>> just let them do it their way when it makes no difference.  
>> Specifically regarding the website, I should be able to submit HTML, 
>> CSS and JS if I want, others should be able to do it with the static 
>> generator thing if they want.  I could have fixed the website with 
>> complete version specific pages, with some really good text to fill 
>> in where there is none now and so on; and done that several different 
>> ways by now.  I'm donating my time too.  Please keep that in mind.
>>
>> Let me ask again, where are the standards?  How can you leave the 
>> website for the project you will be associated with looking that substandard?
>> Rahul Singh has been making a very important point that different 
>> types of uses with different uses cases use the website. This is a 
>> public website; not an internal site for coders.
>>
>> Kenneth Brotman
>>
>> -Original Message-
>> From: Josh McKenzie [mailto:jmcken...@apache.org]
>> Sent: Monday, March 19, 2018 7:42 AM
>> To: dev@cassandra.apache.org
>> Subject: Re: A JIRA proposing a seperate repository for the online 
>> documentation
>>
>> Wow. Ok, let's try this again.
>>
>> Josh, you made my point for me.   Lower the barriers to entry
>>
>> Kenneth, I disagree. The C* community is not expressing universal 
>> interest in having a hand-crafted bespoke website, but many have 
>> expressed being open to using markdown to create content. Former: 
>> high barrier to entry *for the community as a whole, not just you.* 
>> Important distinction.
>>
>> If someone like me offers to knock out something that's been a 
>> problem for
>> > the group and can do a very professional job, next time get out of 
>> > the
>> way.
>>
>> It's been a problem because people haven't devoted time to it, not 
>> because they couldn't figure out markdown. The Apache Way is about 
>> consensus, not telling people to get out of the way when they don't 
>> agree with you.
>>
>> I don't make junk Josh.
>>
>> Actions speak louder than words and thus far your tone, 
>> combativeness, and repeated unwillingness to acknowledge what looks 
>> to be a strong general consensus from your peers is the evidence we have to 
>> go on.
>>
>> On Mon, Mar 19, 2018 at 10:21 AM, Kenneth Brotman < 
>> kenbrot...@yahoo.com.invalid> wrote:
>>
>> > Josh, you made my point for me.   Lower the barriers to entry, not throw
>> > extra steps I don’t need at me.  If someone like me offers to knock 
>> > out something that's been a problem for the group and can do a very 
>> > professional job, next time get out of the way.  I don't make junk Josh.
>> > Sorry that Apache is not interested in a site with multi-media 
>> > support; or even sites with complete pages.  Show me one quality 
>> > open source Apache site.  Wake up.  Raise your bar!  Engineers 
>> > shouldn't speak in the language of mediocrity.
>> >
>> > Kenneth Brotman
>> >
>> > -Original Message-
>> > From: Josh McKenzie [mailto:jmcken...@apache.org]
>> > Sent: Monday, March 19, 2018 5:27 AM
>> > To: dev@cassandra.apache.org
>> > Subject: Re: A JIRA proposing a seperate repository for the online 
>> > documentation
>> >
>> > >
>> > > I've been writing html a long time; since about 1990.  You're 
>> > > asking me to learn a weird little program, a static site 
>> > > generator just to change something I can already do without using a 
>> > > program at all.
>> >
>> > You're one person among a community of back-end Java devs. If you 
>> > want people to contribute to things you need to lower the barriers 
>> > to entry, not deep-dive into some bespoke thing that may never see 
>> > the light of day and, when completed, misses the mark on what users 
>> > of
>> cassandra care 

Re: A JIRA proposing a seperate repository for the online documentation

[Josh McKenzie]

And to be explicit about this: I'm going to withdraw from this conversation
now. I don't think we're generating sufficient signal in this dialog
compared to the noise.

Thanks for the enthusiasm and input Kenneth.

On Mon, Mar 19, 2018 at 11:48 AM, Josh McKenzie 
wrote:

> You missed the point ...  let them do it their way when it makes no
>> difference
>
> If you're suggesting we use a static markdown based generator as the "go
> to" method for content generation and accept PR's for "New Hotness" (do it
> their way), then sure, that seems a totally fair compromise. Pretty sure
> that's not what you're suggesting, and people Wild Westing a contribution
> to a project, that the project then owns when you get bored of it and move
> on, doesn't qualify for "makes no difference".
>
> On Mon, Mar 19, 2018 at 11:10 AM, Kenneth Brotman <
> kenbrot...@yahoo.com.invalid> wrote:
>
>> You missed the point.  If someone can do a good job on something, just
>> let them do it their way when it makes no difference.  Specifically
>> regarding the website, I should be able to submit HTML, CSS and JS if I
>> want, others should be able to do it with the static generator thing if
>> they want.  I could have fixed the website with complete version specific
>> pages, with some really good text to fill in where there is none now and so
>> on; and done that several different ways by now.  I'm donating my time
>> too.  Please keep that in mind.
>>
>> Let me ask again, where are the standards?  How can you leave the website
>> for the project you will be associated with looking that substandard?
>> Rahul Singh has been making a very important point that different types of
>> uses with different uses cases use the website. This is a public website;
>> not an internal site for coders.
>>
>> Kenneth Brotman
>>
>> -Original Message-
>> From: Josh McKenzie [mailto:jmcken...@apache.org]
>> Sent: Monday, March 19, 2018 7:42 AM
>> To: dev@cassandra.apache.org
>> Subject: Re: A JIRA proposing a seperate repository for the online
>> documentation
>>
>> Wow. Ok, let's try this again.
>>
>> Josh, you made my point for me.   Lower the barriers to entry
>>
>> Kenneth, I disagree. The C* community is not expressing universal
>> interest in having a hand-crafted bespoke website, but many have expressed
>> being open to using markdown to create content. Former: high barrier to
>> entry *for the community as a whole, not just you.* Important distinction.
>>
>> If someone like me offers to knock out something that's been a problem for
>> > the group and can do a very professional job, next time get out of the
>> way.
>>
>> It's been a problem because people haven't devoted time to it, not
>> because they couldn't figure out markdown. The Apache Way is about
>> consensus, not telling people to get out of the way when they don't agree
>> with you.
>>
>> I don't make junk Josh.
>>
>> Actions speak louder than words and thus far your tone, combativeness,
>> and repeated unwillingness to acknowledge what looks to be a strong general
>> consensus from your peers is the evidence we have to go on.
>>
>> On Mon, Mar 19, 2018 at 10:21 AM, Kenneth Brotman <
>> kenbrot...@yahoo.com.invalid> wrote:
>>
>> > Josh, you made my point for me.   Lower the barriers to entry, not throw
>> > extra steps I don’t need at me.  If someone like me offers to knock
>> > out something that's been a problem for the group and can do a very
>> > professional job, next time get out of the way.  I don't make junk Josh.
>> > Sorry that Apache is not interested in a site with multi-media
>> > support; or even sites with complete pages.  Show me one quality open
>> > source Apache site.  Wake up.  Raise your bar!  Engineers shouldn't
>> > speak in the language of mediocrity.
>> >
>> > Kenneth Brotman
>> >
>> > -Original Message-
>> > From: Josh McKenzie [mailto:jmcken...@apache.org]
>> > Sent: Monday, March 19, 2018 5:27 AM
>> > To: dev@cassandra.apache.org
>> > Subject: Re: A JIRA proposing a seperate repository for the online
>> > documentation
>> >
>> > >
>> > > I've been writing html a long time; since about 1990.  You're asking
>> > > me to learn a weird little program, a static site generator just to
>> > > change something I can already do without using a program at all.
>> >
>> > You're one person among a community of back-end Java devs. If you want
>> > people to contribute to things you need to lower the barriers to
>> > entry, not deep-dive into some bespoke thing that may never see the
>> > light of day and, when completed, misses the mark on what users of
>> cassandra care about:
>> > clarity and speed. Also: bus-factor 1 is bad.
>> >
>> > Another weird thing: Wouldn't we want a website that is dynamic and
>> > > multi-media rich?
>> >
>> > Personally? No. We're talking function here, not form. As an engineer,
>> > I don't want to wade through someone else's idea of what "dynamic and
>> > multi-media rich" means when I'm trying to find 

Re: A JIRA proposing a seperate repository for the online documentation

[Josh McKenzie]

>
> You missed the point ...  let them do it their way when it makes no
> difference

If you're suggesting we use a static markdown based generator as the "go
to" method for content generation and accept PR's for "New Hotness" (do it
their way), then sure, that seems a totally fair compromise. Pretty sure
that's not what you're suggesting, and people Wild Westing a contribution
to a project, that the project then owns when you get bored of it and move
on, doesn't qualify for "makes no difference".

On Mon, Mar 19, 2018 at 11:10 AM, Kenneth Brotman <
kenbrot...@yahoo.com.invalid> wrote:

> You missed the point.  If someone can do a good job on something, just let
> them do it their way when it makes no difference.  Specifically regarding
> the website, I should be able to submit HTML, CSS and JS if I want, others
> should be able to do it with the static generator thing if they want.  I
> could have fixed the website with complete version specific pages, with
> some really good text to fill in where there is none now and so on; and
> done that several different ways by now.  I'm donating my time too.  Please
> keep that in mind.
>
> Let me ask again, where are the standards?  How can you leave the website
> for the project you will be associated with looking that substandard?
> Rahul Singh has been making a very important point that different types of
> uses with different uses cases use the website. This is a public website;
> not an internal site for coders.
>
> Kenneth Brotman
>
> -Original Message-
> From: Josh McKenzie [mailto:jmcken...@apache.org]
> Sent: Monday, March 19, 2018 7:42 AM
> To: dev@cassandra.apache.org
> Subject: Re: A JIRA proposing a seperate repository for the online
> documentation
>
> Wow. Ok, let's try this again.
>
> Josh, you made my point for me.   Lower the barriers to entry
>
> Kenneth, I disagree. The C* community is not expressing universal interest
> in having a hand-crafted bespoke website, but many have expressed being
> open to using markdown to create content. Former: high barrier to entry
> *for the community as a whole, not just you.* Important distinction.
>
> If someone like me offers to knock out something that's been a problem for
> > the group and can do a very professional job, next time get out of the
> way.
>
> It's been a problem because people haven't devoted time to it, not because
> they couldn't figure out markdown. The Apache Way is about consensus, not
> telling people to get out of the way when they don't agree with you.
>
> I don't make junk Josh.
>
> Actions speak louder than words and thus far your tone, combativeness, and
> repeated unwillingness to acknowledge what looks to be a strong general
> consensus from your peers is the evidence we have to go on.
>
> On Mon, Mar 19, 2018 at 10:21 AM, Kenneth Brotman <
> kenbrot...@yahoo.com.invalid> wrote:
>
> > Josh, you made my point for me.   Lower the barriers to entry, not throw
> > extra steps I don’t need at me.  If someone like me offers to knock
> > out something that's been a problem for the group and can do a very
> > professional job, next time get out of the way.  I don't make junk Josh.
> > Sorry that Apache is not interested in a site with multi-media
> > support; or even sites with complete pages.  Show me one quality open
> > source Apache site.  Wake up.  Raise your bar!  Engineers shouldn't
> > speak in the language of mediocrity.
> >
> > Kenneth Brotman
> >
> > -Original Message-
> > From: Josh McKenzie [mailto:jmcken...@apache.org]
> > Sent: Monday, March 19, 2018 5:27 AM
> > To: dev@cassandra.apache.org
> > Subject: Re: A JIRA proposing a seperate repository for the online
> > documentation
> >
> > >
> > > I've been writing html a long time; since about 1990.  You're asking
> > > me to learn a weird little program, a static site generator just to
> > > change something I can already do without using a program at all.
> >
> > You're one person among a community of back-end Java devs. If you want
> > people to contribute to things you need to lower the barriers to
> > entry, not deep-dive into some bespoke thing that may never see the
> > light of day and, when completed, misses the mark on what users of
> cassandra care about:
> > clarity and speed. Also: bus-factor 1 is bad.
> >
> > Another weird thing: Wouldn't we want a website that is dynamic and
> > > multi-media rich?
> >
> > Personally? No. We're talking function here, not form. As an engineer,
> > I don't want to wade through someone else's idea of what "dynamic and
> > multi-media rich" means when I'm trying to find an answer to something
> > or learn something so I can get on with my job.
> >
> >
> >
> > On Sun, Mar 18, 2018 at 5:12 PM, Nate McCall  wrote:
> >
> > > On Mon, Mar 19, 2018 at 12:41 AM, Kenneth Brotman
> > >  wrote:
> > > > I don't know what we are doing for the website technologies right
> > > > now
> > > because like everything else what we do 

RE: A JIRA proposing a seperate repository for the online documentation

[Kenneth Brotman]

You missed the point.  If someone can do a good job on something, just let them 
do it their way when it makes no difference.  Specifically regarding the 
website, I should be able to submit HTML, CSS and JS if I want, others should 
be able to do it with the static generator thing if they want.  I could have 
fixed the website with complete version specific pages, with some really good 
text to fill in where there is none now and so on; and done that several 
different ways by now.  I'm donating my time too.  Please keep that in mind.  

Let me ask again, where are the standards?  How can you leave the website for 
the project you will be associated with looking that substandard?  Rahul Singh 
has been making a very important point that different types of uses with 
different uses cases use the website. This is a public website; not an internal 
site for coders.

Kenneth Brotman

-Original Message-
From: Josh McKenzie [mailto:jmcken...@apache.org] 
Sent: Monday, March 19, 2018 7:42 AM
To: dev@cassandra.apache.org
Subject: Re: A JIRA proposing a seperate repository for the online documentation

Wow. Ok, let's try this again.

Josh, you made my point for me.   Lower the barriers to entry

Kenneth, I disagree. The C* community is not expressing universal interest in 
having a hand-crafted bespoke website, but many have expressed being open to 
using markdown to create content. Former: high barrier to entry *for the 
community as a whole, not just you.* Important distinction.

If someone like me offers to knock out something that's been a problem for
> the group and can do a very professional job, next time get out of the way.

It's been a problem because people haven't devoted time to it, not because they 
couldn't figure out markdown. The Apache Way is about consensus, not telling 
people to get out of the way when they don't agree with you.

I don't make junk Josh.

Actions speak louder than words and thus far your tone, combativeness, and 
repeated unwillingness to acknowledge what looks to be a strong general 
consensus from your peers is the evidence we have to go on.

On Mon, Mar 19, 2018 at 10:21 AM, Kenneth Brotman < 
kenbrot...@yahoo.com.invalid> wrote:

> Josh, you made my point for me.   Lower the barriers to entry, not throw
> extra steps I don’t need at me.  If someone like me offers to knock 
> out something that's been a problem for the group and can do a very 
> professional job, next time get out of the way.  I don't make junk Josh.
> Sorry that Apache is not interested in a site with multi-media 
> support; or even sites with complete pages.  Show me one quality open 
> source Apache site.  Wake up.  Raise your bar!  Engineers shouldn't 
> speak in the language of mediocrity.
>
> Kenneth Brotman
>
> -Original Message-
> From: Josh McKenzie [mailto:jmcken...@apache.org]
> Sent: Monday, March 19, 2018 5:27 AM
> To: dev@cassandra.apache.org
> Subject: Re: A JIRA proposing a seperate repository for the online 
> documentation
>
> >
> > I've been writing html a long time; since about 1990.  You're asking 
> > me to learn a weird little program, a static site generator just to 
> > change something I can already do without using a program at all.
>
> You're one person among a community of back-end Java devs. If you want 
> people to contribute to things you need to lower the barriers to 
> entry, not deep-dive into some bespoke thing that may never see the 
> light of day and, when completed, misses the mark on what users of cassandra 
> care about:
> clarity and speed. Also: bus-factor 1 is bad.
>
> Another weird thing: Wouldn't we want a website that is dynamic and
> > multi-media rich?
>
> Personally? No. We're talking function here, not form. As an engineer, 
> I don't want to wade through someone else's idea of what "dynamic and 
> multi-media rich" means when I'm trying to find an answer to something 
> or learn something so I can get on with my job.
>
>
>
> On Sun, Mar 18, 2018 at 5:12 PM, Nate McCall  wrote:
>
> > On Mon, Mar 19, 2018 at 12:41 AM, Kenneth Brotman 
> >  wrote:
> > > I don't know what we are doing for the website technologies right 
> > > now
> > because like everything else what we do is not documented anywhere.
> > Where are the servers: the cloud?  What server software are we 
> > running?  How is the html, etc. generated and published?  How is 
> > search
> done for the website?
> >
> > http://cassandra.apache.org/doc/latest/development/documentation.htm
> > l The resulting static HTML from Sphinx is hosted on ASF 
> > infrastructure.
> >
> > 
> > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional 

Re: Debug logging enabled by default since 2.2

[Jeremiah D Jordan]

People seem hung up on DEBUG here.  The goal of CASSANDRA-10241 was
to clean up the system.log so that it a very high “signal” in terms of what was 
logged
to it synchronously, but without reducing the ability of the logs to allow 
people to
solve problems and perform post mortem analysis of issues.  We have 
informational
log messages that are very useful to understanding the state of things, like 
compaction
status, repair status, flushing, or the state of gossip in the system that are 
very useful to
operators, but if they are all in the system.log make said log file harder to 
look over for
issues.  In 10241 the method chosen for how to keep these log messages around by
default, but get them out of the system.log was that these messages were 
changed from
INFO to DEBUG and the new debug.log was created.

From the discussion here it seems that many would like to change how this 
works.  Rather
than just turning off the debug.log I would propose that we switch to using the 
SLF4J
MARKER[1] ability to move the messages back to INFO but tag them as belonging to
the asynchronous_system.log rather than the normal system.log.

[1] https://logback.qos.ch/manual/layouts.html#marker 

https://www.slf4j.org/faq.html#fatal 


> On Mar 19, 2018, at 9:01 AM, Stefan Podkowinski  wrote:
> 
> I'd agree that INFO should be the default. Turning on the DEBUG logging
> can cause notable performance issues and I would not enable it on
> production systems unless I really have to. That's why I created 
> CASSANDRA-12696 for 4.0, so you'll be able to at least only partially
> enable DEBUG based on what's relevant to look at, e.g. `nodetool
> setlogginglevel bootstrap DEBUG`.
> 
> But small improvements like that won't change the fact that log files
> suck in general for more complex analysis, except for trivial tailing
> and grepping. You have to make sure that logging is enabled and old
> records you're interested in will not be rotated out. Then you have to
> gather log files from individual nodes somehow. Eventually I end up with
> a local tarball with logs in that situation and the fun starts creating
> hacky, regex loaded Python scripts to parse them. As each log message is
> limited to a single line of text, it's often missing out relevant
> details. You also got to create different parsers for different messages
> of course. It's just inefficient and too time consuming to gather
> information that way. Let alone implementing more advanced monitoring
> solutions on top of that.
> 
> That's exactly why I started working on the "diagnostic events"
> (CASSANDRA-12944) idea more than a year ago. There's also support for
> persistency (CASSANDRA-13460) that would implement storing important but
> infrequent events as rich json objects in a local keyspace and allows
> retrieving them by using CQL. I still like the idea and think it's worth
> pursuing.
> 
> 
> On 19.03.18 09:53, Alain RODRIGUEZ wrote:
>> Hello,
>> 
>> I am not developing Cassandra, but I am using it actively and helping
>> people to work with it. My perspective might be missing some code
>> considerations and history as I did not go through the ticket where this
>> 'debug' level was added by default. But here is a feedback after upgrading
>> a few clusters to Cassandra 2.2:
>> 
>> When upgrading a cluster to Cassandra 2.2, 'disable the debug logs' is in
>> my runbook. I mean, very often, when some cluster is upgraded to Cassandra
>> 2.2 and has problems with performances, the 2 most frequent issues are:
>> 
>> - DEBUG level being turned on
>> - and / or dynamic snitching being enabled
>> 
>> This is especially true for high percentile (very clear on p99). Let's put
>> the dynamic snitch aside as it is not our topic here.
>> 
>> From an operational perspective, I prefer to set the debug level to 'DEBUG'
>> when I need it than having, out of the box, something that is unexpected
>> and impact performances. Plus the debug level can be changed without
>> restarting the node, through 'JMX' or even using 'nodetool' now.
>> 
>> Also in most cases, the 'INFO' level is good enough for me to detect most
>> of the issues. I was even able to recreate a detailed history of events for
>> a customer recently, 'INFO' logs are already very powerful and complete I
>> believe (nice work on this by the way). Then monitoring is helping a lot
>> too. I did not have to use debug logs for a long time. It might happen, but
>> I will find my way to enable them.
>> 
>> Even though it feels great to be able to help people with that easily
>> because the cause is often the same and turning off the logs is a
>> low hanging fruit in C*2.2 clusters that have very nice results and is easy
>> to achieve, I would prefer people not to fall into these performances traps
>> in the first place. In my head, 'Debug' logs should be for debug purposes
>> (by opposition to 'always on'). It seems 

Re: A JIRA proposing a seperate repository for the online documentation

[Josh McKenzie]

Wow. Ok, let's try this again.

Josh, you made my point for me.   Lower the barriers to entry

Kenneth, I disagree. The C* community is not expressing universal interest
in having a hand-crafted bespoke website, but many have expressed being
open to using markdown to create content. Former: high barrier to entry *for
the community as a whole, not just you.* Important distinction.

If someone like me offers to knock out something that's been a problem for
> the group and can do a very professional job, next time get out of the way.

It's been a problem because people haven't devoted time to it, not because
they couldn't figure out markdown. The Apache Way is about consensus, not
telling people to get out of the way when they don't agree with you.

I don't make junk Josh.

Actions speak louder than words and thus far your tone, combativeness, and
repeated unwillingness to acknowledge what looks to be a strong general
consensus from your peers is the evidence we have to go on.

On Mon, Mar 19, 2018 at 10:21 AM, Kenneth Brotman <
kenbrot...@yahoo.com.invalid> wrote:

> Josh, you made my point for me.   Lower the barriers to entry, not throw
> extra steps I don’t need at me.  If someone like me offers to knock out
> something that's been a problem for the group and can do a very
> professional job, next time get out of the way.  I don't make junk Josh.
> Sorry that Apache is not interested in a site with multi-media support; or
> even sites with complete pages.  Show me one quality open source Apache
> site.  Wake up.  Raise your bar!  Engineers shouldn't speak in the language
> of mediocrity.
>
> Kenneth Brotman
>
> -Original Message-
> From: Josh McKenzie [mailto:jmcken...@apache.org]
> Sent: Monday, March 19, 2018 5:27 AM
> To: dev@cassandra.apache.org
> Subject: Re: A JIRA proposing a seperate repository for the online
> documentation
>
> >
> > I've been writing html a long time; since about 1990.  You're asking
> > me to learn a weird little program, a static site generator just to
> > change something I can already do without using a program at all.
>
> You're one person among a community of back-end Java devs. If you want
> people to contribute to things you need to lower the barriers to entry, not
> deep-dive into some bespoke thing that may never see the light of day and,
> when completed, misses the mark on what users of cassandra care about:
> clarity and speed. Also: bus-factor 1 is bad.
>
> Another weird thing: Wouldn't we want a website that is dynamic and
> > multi-media rich?
>
> Personally? No. We're talking function here, not form. As an engineer, I
> don't want to wade through someone else's idea of what "dynamic and
> multi-media rich" means when I'm trying to find an answer to something or
> learn something so I can get on with my job.
>
>
>
> On Sun, Mar 18, 2018 at 5:12 PM, Nate McCall  wrote:
>
> > On Mon, Mar 19, 2018 at 12:41 AM, Kenneth Brotman
> >  wrote:
> > > I don't know what we are doing for the website technologies right
> > > now
> > because like everything else what we do is not documented anywhere.
> > Where are the servers: the cloud?  What server software are we
> > running?  How is the html, etc. generated and published?  How is search
> done for the website?
> >
> > http://cassandra.apache.org/doc/latest/development/documentation.html
> > The resulting static HTML from Sphinx is hosted on ASF infrastructure.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

RE: Website front page broken links

[Kenneth Brotman]

Split the ticket up. Don't leave the home page broken for weeks!  Move the 
third party discussion to another JIRA.  Get the home page fixed ASAP!

Kenneth Brotman

-Original Message-
From: Hannu Kröger [mailto:hkro...@gmail.com] 
Sent: Monday, March 19, 2018 12:43 AM
To: dev@cassandra.apache.org
Subject: Re: Website front page broken links

ah, of course. Sorry for the duplicate.

Hannu

> On 19 Mar 2018, at 09:36, kurt greaves  wrote:
> 
> A ticket already exists that covers this, with a patch. just needs 
> some consensus around the third party page.
> https://issues.apache.org/jira/browse/CASSANDRA-14128
> 
> On 19 Mar. 2018 18:26, "Hannu Kröger"  wrote:
> 
>> Hello,
>> 
>> I created this ticket
>> https://issues.apache.org/jira/browse/CASSANDRA-14324
>> 
>> Basically the website front page contains manybroken links to 
>> planetcassandra.org
>> 
>> Hannu
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
>> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

RE: A JIRA proposing a seperate repository for the online documentation

[Kenneth Brotman]

Josh, you made my point for me.   Lower the barriers to entry, not throw extra 
steps I don’t need at me.  If someone like me offers to knock out something 
that's been a problem for the group and can do a very professional job, next 
time get out of the way.  I don't make junk Josh.  Sorry that Apache is not 
interested in a site with multi-media support; or even sites with complete 
pages.  Show me one quality open source Apache site.  Wake up.  Raise your bar! 
 Engineers shouldn't speak in the language of mediocrity.

Kenneth Brotman  

-Original Message-
From: Josh McKenzie [mailto:jmcken...@apache.org] 
Sent: Monday, March 19, 2018 5:27 AM
To: dev@cassandra.apache.org
Subject: Re: A JIRA proposing a seperate repository for the online documentation

>
> I've been writing html a long time; since about 1990.  You're asking 
> me to learn a weird little program, a static site generator just to 
> change something I can already do without using a program at all.

You're one person among a community of back-end Java devs. If you want people 
to contribute to things you need to lower the barriers to entry, not deep-dive 
into some bespoke thing that may never see the light of day and, when 
completed, misses the mark on what users of cassandra care about:
clarity and speed. Also: bus-factor 1 is bad.

Another weird thing: Wouldn't we want a website that is dynamic and
> multi-media rich?

Personally? No. We're talking function here, not form. As an engineer, I don't 
want to wade through someone else's idea of what "dynamic and multi-media rich" 
means when I'm trying to find an answer to something or learn something so I 
can get on with my job.



On Sun, Mar 18, 2018 at 5:12 PM, Nate McCall  wrote:

> On Mon, Mar 19, 2018 at 12:41 AM, Kenneth Brotman 
>  wrote:
> > I don't know what we are doing for the website technologies right 
> > now
> because like everything else what we do is not documented anywhere.  
> Where are the servers: the cloud?  What server software are we 
> running?  How is the html, etc. generated and published?  How is search done 
> for the website?
>
> http://cassandra.apache.org/doc/latest/development/documentation.html
> The resulting static HTML from Sphinx is hosted on ASF infrastructure.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Debug logging enabled by default since 2.2

[Stefan Podkowinski]

I'd agree that INFO should be the default. Turning on the DEBUG logging
can cause notable performance issues and I would not enable it on
production systems unless I really have to. That's why I created 
CASSANDRA-12696 for 4.0, so you'll be able to at least only partially
enable DEBUG based on what's relevant to look at, e.g. `nodetool
setlogginglevel bootstrap DEBUG`.

But small improvements like that won't change the fact that log files
suck in general for more complex analysis, except for trivial tailing
and grepping. You have to make sure that logging is enabled and old
records you're interested in will not be rotated out. Then you have to
gather log files from individual nodes somehow. Eventually I end up with
a local tarball with logs in that situation and the fun starts creating
hacky, regex loaded Python scripts to parse them. As each log message is
limited to a single line of text, it's often missing out relevant
details. You also got to create different parsers for different messages
of course. It's just inefficient and too time consuming to gather
information that way. Let alone implementing more advanced monitoring
solutions on top of that.

That's exactly why I started working on the "diagnostic events"
(CASSANDRA-12944) idea more than a year ago. There's also support for
persistency (CASSANDRA-13460) that would implement storing important but
infrequent events as rich json objects in a local keyspace and allows
retrieving them by using CQL. I still like the idea and think it's worth
pursuing.


On 19.03.18 09:53, Alain RODRIGUEZ wrote:
> Hello,
>
> I am not developing Cassandra, but I am using it actively and helping
> people to work with it. My perspective might be missing some code
> considerations and history as I did not go through the ticket where this
> 'debug' level was added by default. But here is a feedback after upgrading
> a few clusters to Cassandra 2.2:
>
> When upgrading a cluster to Cassandra 2.2, 'disable the debug logs' is in
> my runbook. I mean, very often, when some cluster is upgraded to Cassandra
> 2.2 and has problems with performances, the 2 most frequent issues are:
>
> - DEBUG level being turned on
> - and / or dynamic snitching being enabled
>
> This is especially true for high percentile (very clear on p99). Let's put
> the dynamic snitch aside as it is not our topic here.
>
> From an operational perspective, I prefer to set the debug level to 'DEBUG'
> when I need it than having, out of the box, something that is unexpected
> and impact performances. Plus the debug level can be changed without
> restarting the node, through 'JMX' or even using 'nodetool' now.
>
> Also in most cases, the 'INFO' level is good enough for me to detect most
> of the issues. I was even able to recreate a detailed history of events for
> a customer recently, 'INFO' logs are already very powerful and complete I
> believe (nice work on this by the way). Then monitoring is helping a lot
> too. I did not have to use debug logs for a long time. It might happen, but
> I will find my way to enable them.
>
> Even though it feels great to be able to help people with that easily
> because the cause is often the same and turning off the logs is a
> low hanging fruit in C*2.2 clusters that have very nice results and is easy
> to achieve, I would prefer people not to fall into these performances traps
> in the first place. In my head, 'Debug' logs should be for debug purposes
> (by opposition to 'always on'). It seems legit. I am surprised this brings
> so many discussions I thought this was a common standard widely accepted,
> and beyond Cassandra. That being said, it is good to see those exchanges
> are happening, so the decision that will be taken will be a good one, I am
> sure. I hope this comment will help, I have no other goal, for sure I am
> not willing to feed a conflict but a talk and I hope no one felt offended
> by this feedback. I believe this change was made aiming at
> helping/improving things, but it turns out it is more of an annoyance than
> truly helpful (my personal perspective).
>
> I would +1 on making 'INFO' default again, but if someone is missing
> information that should be in 'INFO'. If some informations are missing at
> the 'INFO' level, why not add informations that should be at the 'INFO'
> level there directly and keep log levels meaningful? Making sure we do not
> bring the logs degrading performances from 'Debug' to 'Info' as much as we
> can.
>
> Hope this is useful,
>
> C*heers,
>
> ---
> Alain Rodriguez - @arodream - al...@thelastpickle.com
> France / Spain
>
> The Last Pickle - Apache Cassandra Consulting
> http://www.thelastpickle.com
>
> 2018-03-19 2:18 GMT+00:00 kurt greaves :
>
>> On the same page as Michael here. We disable debug logs in production due
>> to the performance impact. Personally I think if debug logging is necessary
>> for users to use the software we're doing something wrong. Also in my
>> 

Re: Debug logging enabled by default since 2.2

[Josh McKenzie]

>
> In a way the real issue might be that we don’t have nightly performance
> runs that would make an accidentally introduced debug statement obvious.

First off, very much this.

Secondly, IMO it's inconsistent to leave / use assertions in a code-base as
a mix of preconditions and assertions but then disable debug logging as
it's currently used post C-10241. Either we trust our code-base to work and
protect itself against bad inputs or we don't, and our current collective
lack of trust (or rather conflation of concerns under single tools (asserts
/ debug logs)) has performance implications. Seems like adding a log level
not named DEBUG + perf regression testing + running latest version of 2.2
would make all this a non-issue.

Also, let me quote Brandon here:

It seems to me the power user who wants to eek out that last bit of
> performance can do so.  It also seems like the user who doesn't even know
> about that is the exact kind of user that's going to need the debug log in
> the future.


With where things are right now, sure seems like a "if it ain't broke" type
scenario.

On Mon, Mar 19, 2018 at 4:53 AM, Alain RODRIGUEZ  wrote:

> Hello,
>
> I am not developing Cassandra, but I am using it actively and helping
> people to work with it. My perspective might be missing some code
> considerations and history as I did not go through the ticket where this
> 'debug' level was added by default. But here is a feedback after upgrading
> a few clusters to Cassandra 2.2:
>
> When upgrading a cluster to Cassandra 2.2, 'disable the debug logs' is in
> my runbook. I mean, very often, when some cluster is upgraded to Cassandra
> 2.2 and has problems with performances, the 2 most frequent issues are:
>
> - DEBUG level being turned on
> - and / or dynamic snitching being enabled
>
> This is especially true for high percentile (very clear on p99). Let's put
> the dynamic snitch aside as it is not our topic here.
>
> From an operational perspective, I prefer to set the debug level to 'DEBUG'
> when I need it than having, out of the box, something that is unexpected
> and impact performances. Plus the debug level can be changed without
> restarting the node, through 'JMX' or even using 'nodetool' now.
>
> Also in most cases, the 'INFO' level is good enough for me to detect most
> of the issues. I was even able to recreate a detailed history of events for
> a customer recently, 'INFO' logs are already very powerful and complete I
> believe (nice work on this by the way). Then monitoring is helping a lot
> too. I did not have to use debug logs for a long time. It might happen, but
> I will find my way to enable them.
>
> Even though it feels great to be able to help people with that easily
> because the cause is often the same and turning off the logs is a
> low hanging fruit in C*2.2 clusters that have very nice results and is easy
> to achieve, I would prefer people not to fall into these performances traps
> in the first place. In my head, 'Debug' logs should be for debug purposes
> (by opposition to 'always on'). It seems legit. I am surprised this brings
> so many discussions I thought this was a common standard widely accepted,
> and beyond Cassandra. That being said, it is good to see those exchanges
> are happening, so the decision that will be taken will be a good one, I am
> sure. I hope this comment will help, I have no other goal, for sure I am
> not willing to feed a conflict but a talk and I hope no one felt offended
> by this feedback. I believe this change was made aiming at
> helping/improving things, but it turns out it is more of an annoyance than
> truly helpful (my personal perspective).
>
> I would +1 on making 'INFO' default again, but if someone is missing
> information that should be in 'INFO'. If some informations are missing at
> the 'INFO' level, why not add informations that should be at the 'INFO'
> level there directly and keep log levels meaningful? Making sure we do not
> bring the logs degrading performances from 'Debug' to 'Info' as much as we
> can.
>
> Hope this is useful,
>
> C*heers,
>
> ---
> Alain Rodriguez - @arodream - al...@thelastpickle.com
> France / Spain
>
> The Last Pickle - Apache Cassandra Consulting
> http://www.thelastpickle.com
>
> 2018-03-19 2:18 GMT+00:00 kurt greaves :
>
> > On the same page as Michael here. We disable debug logs in production due
> > to the performance impact. Personally I think if debug logging is
> necessary
> > for users to use the software we're doing something wrong. Also in my
> > experience, if something doesn't reproduce it will not get fixed. Debug
> > logging helps, but I've never seen a case where an actual bug simply
> > *doesn't* reproduce eventually, and I'm sure if this issue appears debug
> > logging could be enabled after the fact for the relevant classes and
> > eventually it will reoccur and we could solve the problem. I've never
> seen
> > a user say no to helping 

Re: A JIRA proposing a seperate repository for the online documentation

[Josh McKenzie]

>
> I've been writing html a long time; since about 1990.  You're asking me to
> learn a weird little program, a static site generator just to change
> something I can already do without using a program at all.

You're one person among a community of back-end Java devs. If you want
people to contribute to things you need to lower the barriers to entry, not
deep-dive into some bespoke thing that may never see the light of day and,
when completed, misses the mark on what users of cassandra care about:
clarity and speed. Also: bus-factor 1 is bad.

Another weird thing: Wouldn't we want a website that is dynamic and
> multi-media rich?

Personally? No. We're talking function here, not form. As an engineer, I
don't want to wade through someone else's idea of what "dynamic and
multi-media rich" means when I'm trying to find an answer to something or
learn something so I can get on with my job.



On Sun, Mar 18, 2018 at 5:12 PM, Nate McCall  wrote:

> On Mon, Mar 19, 2018 at 12:41 AM, Kenneth Brotman
>  wrote:
> > I don't know what we are doing for the website technologies right now
> because like everything else what we do is not documented anywhere.  Where
> are the servers: the cloud?  What server software are we running?  How is
> the html, etc. generated and published?  How is search done for the website?
>
> http://cassandra.apache.org/doc/latest/development/documentation.html
> The resulting static HTML from Sphinx is hosted on ASF infrastructure.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Debug logging enabled by default since 2.2

[Alain RODRIGUEZ]

Hello,

I am not developing Cassandra, but I am using it actively and helping
people to work with it. My perspective might be missing some code
considerations and history as I did not go through the ticket where this
'debug' level was added by default. But here is a feedback after upgrading
a few clusters to Cassandra 2.2:

When upgrading a cluster to Cassandra 2.2, 'disable the debug logs' is in
my runbook. I mean, very often, when some cluster is upgraded to Cassandra
2.2 and has problems with performances, the 2 most frequent issues are:

- DEBUG level being turned on
- and / or dynamic snitching being enabled

This is especially true for high percentile (very clear on p99). Let's put
the dynamic snitch aside as it is not our topic here.

>From an operational perspective, I prefer to set the debug level to 'DEBUG'
when I need it than having, out of the box, something that is unexpected
and impact performances. Plus the debug level can be changed without
restarting the node, through 'JMX' or even using 'nodetool' now.

Also in most cases, the 'INFO' level is good enough for me to detect most
of the issues. I was even able to recreate a detailed history of events for
a customer recently, 'INFO' logs are already very powerful and complete I
believe (nice work on this by the way). Then monitoring is helping a lot
too. I did not have to use debug logs for a long time. It might happen, but
I will find my way to enable them.

Even though it feels great to be able to help people with that easily
because the cause is often the same and turning off the logs is a
low hanging fruit in C*2.2 clusters that have very nice results and is easy
to achieve, I would prefer people not to fall into these performances traps
in the first place. In my head, 'Debug' logs should be for debug purposes
(by opposition to 'always on'). It seems legit. I am surprised this brings
so many discussions I thought this was a common standard widely accepted,
and beyond Cassandra. That being said, it is good to see those exchanges
are happening, so the decision that will be taken will be a good one, I am
sure. I hope this comment will help, I have no other goal, for sure I am
not willing to feed a conflict but a talk and I hope no one felt offended
by this feedback. I believe this change was made aiming at
helping/improving things, but it turns out it is more of an annoyance than
truly helpful (my personal perspective).

I would +1 on making 'INFO' default again, but if someone is missing
information that should be in 'INFO'. If some informations are missing at
the 'INFO' level, why not add informations that should be at the 'INFO'
level there directly and keep log levels meaningful? Making sure we do not
bring the logs degrading performances from 'Debug' to 'Info' as much as we
can.

Hope this is useful,

C*heers,

---
Alain Rodriguez - @arodream - al...@thelastpickle.com
France / Spain

The Last Pickle - Apache Cassandra Consulting
http://www.thelastpickle.com

2018-03-19 2:18 GMT+00:00 kurt greaves :

> On the same page as Michael here. We disable debug logs in production due
> to the performance impact. Personally I think if debug logging is necessary
> for users to use the software we're doing something wrong. Also in my
> experience, if something doesn't reproduce it will not get fixed. Debug
> logging helps, but I've never seen a case where an actual bug simply
> *doesn't* reproduce eventually, and I'm sure if this issue appears debug
> logging could be enabled after the fact for the relevant classes and
> eventually it will reoccur and we could solve the problem. I've never seen
> a user say no to helping debug a problem with patched jars/changes to their
> system (like logging). I'd much prefer we pushed that harder rather than
> just saying "Everyone gets debug logging!". I'm also really not sold that
> debug logging saves the day. To me it mostly just speeds up the
> identification process, it generally doesn't expose magical information
> that wasn't available before, you just had to think about it a bit more.
>
>
> In a way the real issue might be that we don’t have nightly performance
> > runs that would make an accidentally introduced debug statement obvious.
>
> This is an issue, but I don't think it's the *real* issue. As already
> noted, debug logging is for debugging, which normal users shouldn't have to
> think about when they are just operating the software. We shouldn't risk
> performance regressions just for developer convenience.
>
> On 19 March 2018 at 00:55, Ariel Weisberg  wrote:
>
> > Hi,
> >
> > In a way the real issue might be that we don’t have nightly performance
> > runs that would make an accidentally introduced debug statement obvious.
> >
> > A log statement that runs once or more per read or write should be easy
> to
> > spot. I haven’t measured the impact though. And as a bonus by having this
> > we can spot a variety of performance issues 

RE: Debug logging enabled by default since 2.2

[Jacques-Henri Berthemet]

If debug log is not a real debug then you should rename it to something else, 
maybe production.log. Also, I have the impression that all logs in system.log 
are also contained in debug.log so it's not really useful.

I feel that be moving all verbose debug logs to trace we're losing the good 
info in debug logs. I've been trying to troubleshoot issues from our QA and 
debug.log didn't really help me.

From my point of view there should be a single log file, defaults to info. 
Debug level should contain all useful info even if it means lower performance, 
trace should contain all possible relevant info. If some loggers (or groups) 
are known to cause huge performance hits they should be disabled by default.
--
Jacques-Henri Berthemet

-Original Message-
From: kurt greaves [mailto:k...@instaclustr.com] 
Sent: Monday, March 19, 2018 3:18 AM
To: dev@cassandra.apache.org
Subject: Re: Debug logging enabled by default since 2.2

On the same page as Michael here. We disable debug logs in production due to 
the performance impact. Personally I think if debug logging is necessary for 
users to use the software we're doing something wrong. Also in my experience, 
if something doesn't reproduce it will not get fixed. Debug logging helps, but 
I've never seen a case where an actual bug simply
*doesn't* reproduce eventually, and I'm sure if this issue appears debug 
logging could be enabled after the fact for the relevant classes and eventually 
it will reoccur and we could solve the problem. I've never seen a user say no 
to helping debug a problem with patched jars/changes to their system (like 
logging). I'd much prefer we pushed that harder rather than just saying 
"Everyone gets debug logging!". I'm also really not sold that debug logging 
saves the day. To me it mostly just speeds up the identification process, it 
generally doesn't expose magical information that wasn't available before, you 
just had to think about it a bit more.


In a way the real issue might be that we don’t have nightly performance
> runs that would make an accidentally introduced debug statement obvious.

This is an issue, but I don't think it's the *real* issue. As already noted, 
debug logging is for debugging, which normal users shouldn't have to think 
about when they are just operating the software. We shouldn't risk performance 
regressions just for developer convenience.

On 19 March 2018 at 00:55, Ariel Weisberg  wrote:

> Hi,
>
> In a way the real issue might be that we don’t have nightly 
> performance runs that would make an accidentally introduced debug statement 
> obvious.
>
> A log statement that runs once or more per read or write should be 
> easy to spot. I haven’t measured the impact though. And as a bonus by 
> having this we can spot a variety of performance issues introduced by 
> all kinds of changes.
>
> Ariel
>
> > On Mar 18, 2018, at 3:46 PM, Jeff Jirsa  wrote:
> >
> > In Cassandra-10241 I said I was torn on this whole ticket, since 
> > most
> people would end up turning it off if it had a negative impact. You said:
> >
> > “I'd like to emphasize that we're not talking about turning debug or
> trace on for client-generated request paths. There's way too much data 
> generated and it's unlikely to be useful.
> > What we're proposing is enabling debug logging ONLY for cluster 
> > state
> changes like gossip and schema, and infrequent activities like repair. 
> “
> >
> > Clearly there’s a disconnect here - we’ve turned debug logging on 
> > for
> everything and shuffled some stuff to trace, which is a one time 
> action but is hard to protect against regression. In fact, just 
> looking at the read callback shows two instances of debug log in the 
> client request path (exercise for the reader to “git blame”).
> >
> > Either we can go clean up all the surprises that leaked through, or 
> > we
> can turn off debug and start backing out some of the changes in 10241.
> Putting stuff like compaction in the same bucket as digest mismatch 
> and gossip state doesn’t make life materially better for most people.
> >
> >
> > --
> > Jeff Jirsa
> >
> >
> >> On Mar 18, 2018, at 11:21 AM, Jonathan Ellis  wrote:
> >>
> >> That really depends on whether you're judicious in deciding what to 
> >> log
> at
> >> debug, doesn't it?
> >>
> >> On Sun, Mar 18, 2018 at 12:57 PM, Michael Kjellman 
> >> 
> >> wrote:
> >>
> >>> +1. this is how it works.
> >>>
> >>> your computer doesn’t run at debug logging by default. your phone
> doesn’t
> >>> either. neither does your smart tv. your database can’t be running 
> >>> at
> debug
> >>> just because it makes our lives as engineers easier.
> >>>
>  On Mar 18, 2018, at 5:14 AM, Alexander Dejanovski <
> >>> a...@thelastpickle.com> wrote:
> 
>  It's a tiny bit unusual to turn on debug logging for all users by
> default
>  though, and there should be occasions to turn it on when facing 
>  

Re: Website front page broken links

[Hannu Kröger]

ah, of course. Sorry for the duplicate.

Hannu

> On 19 Mar 2018, at 09:36, kurt greaves  wrote:
> 
> A ticket already exists that covers this, with a patch. just needs some
> consensus around the third party page.
> https://issues.apache.org/jira/browse/CASSANDRA-14128
> 
> On 19 Mar. 2018 18:26, "Hannu Kröger"  wrote:
> 
>> Hello,
>> 
>> I created this ticket
>> https://issues.apache.org/jira/browse/CASSANDRA-14324
>> 
>> Basically the website front page contains manybroken links to
>> planetcassandra.org
>> 
>> Hannu
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
>> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Website front page broken links

[kurt greaves]

A ticket already exists that covers this, with a patch. just needs some
consensus around the third party page.
https://issues.apache.org/jira/browse/CASSANDRA-14128

On 19 Mar. 2018 18:26, "Hannu Kröger"  wrote:

> Hello,
>
> I created this ticket
> https://issues.apache.org/jira/browse/CASSANDRA-14324
>
> Basically the website front page contains manybroken links to
> planetcassandra.org
>
> Hannu
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Website front page broken links

[Hannu Kröger]

Hello,

I created this ticket
https://issues.apache.org/jira/browse/CASSANDRA-14324

Basically the website front page contains manybroken links to 
planetcassandra.org

Hannu
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org