Re: Debug logging enabled by default since 2.2

[Alexander Dejanovski]

Hi Paulo,

I agree that CASSANDRA-10241 prevents from simply turning off debug logging
and there's more work to do (we need compaction and flush traces among
others).

My 2 cents on the other points :

   - I was happy with a single log file for 99.5% of my ops needs and
   verbosity was never an issue in system.log, but don't mind having 2 if the
   naming is less confusing and performance isn't affected.
   - Nightly performance testing is a must have for a (community) database.
   Injecting perf regressions is way too easy. It's probably not easy to setup
   though in a way that each run has the exact same conditions and we don't
   get false alarms.
   - There has been mentions of more lightweight logging frameworks :
   that's definitely something we should look at.

In the scope of https://issues.apache.org/jira/browse/CASSANDRA-14318, I'll
start by fixing the identified performance issue that seems to affect C*
2.2 only, by lowering read path DEBUG loggings to TRACE level and run new
benchmarks.
I'll also check to what extent debug logging affects performance in 3.0.16
and 3.11.2.

Some changes apparently need to be done, may it be to rename the debug log
to system-verbose.log (or whatever) and use custom levels, or move back all
required verbose logs to the original system.log.
I've created a follow up ticket to continue this conversation :
https://issues.apache.org/jira/browse/CASSANDRA-14326

Thanks all for this very interesting discussion !

Cheers,


On Mon, Mar 19, 2018 at 7:52 PM 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 <
> 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 

Re: Debug logging enabled by default since 2.2

[Stefan Podkowinski]

Are you suggesting to move all messages currently logged via debug() to
info() with the additional marker set, or only particular messages?


On 19.03.2018 19: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://www.slf4j.org/faq.html#fatal 
>>
>>

-
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

[Paulo Motta]

That sounds like a good plan, Alexander! Thanks!

Stefan, someone needs to go through all messages being logged at DEBUG
and reclassify important ones as INFO. I suggest continuing discussion
on specifics on CASSANDRA-14326.

2018-03-20 6:46 GMT-03:00 Stefan Podkowinski :
> Are you suggesting to move all messages currently logged via debug() to
> info() with the additional marker set, or only particular messages?
>
>
> On 19.03.2018 19: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://www.slf4j.org/faq.html#fatal 
>>>
>>>
>
> -
> 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

[DISCUSS] java 9 and the future of cassandra on the jdk

[Jason Brown]

Hi all,


TL;DR Oracle has started revving the JDK version much faster, and we need
an agreed upon plan.

Well, we probably should has this discussion this already by now, but here
we are. Oracle announced plans to release updated JDK version every six
months, and each new version immediate supercedes the previous in all ways:
no updates/security fixes to previous versions is the main thing, and
previous versions are EOL'd immediately. In addition, Oracle has planned
parallel LTS versions that will live for three years, and then superceded
by the next LTS; but not immediately EOL'd from what I can tell. Please see
[1, 2] for Oracle's offical comments about this change ([3] was
particularly useful, imo), [4] and many other postings on the internet for
discussion/commentary.

We have a jira [5] where Robert Stupp did most of the work to get us onto
Java 9 (thanks, Robert), but then the announcement of the JDK version
changes happened last fall after Robert had done much of the work on the
ticket.

Here's an initial proposal of how to move forward. I don't suspect it's
complete, but a decent place to start a conversation.

1) receommend OracleJDK over OpenJDK. IIUC from [3], the OpenJDK will
release every six months, and the OracleJDK will release every three years.
Thus, the OracleJDK is the LTS version, and it just comes from a snapshot
of one of those OpenJDK builds.

2) always release cassandra on a LTS version. I don't think we can
reasonably expect operators to update the JDK every six months, on time.
Further, if there are breaking changes to the JDK, we don't want to have to
update established c* versions due to those changes, every six months.

3) keep trunk on the lasest jdk version, assumming we release a major
cassandra version close enough to a LTS release. Currently that seems
reasonable for cassandra 4.0 to be released with java 11 (18.9 LTS)
support. Perhaps we can evaluate this over time.


Once we agree on a path forward, *it is impreative that we publish the
decision to the docs* so we can point contributors and operators there,
instead of rehashing the same conversation.

I look forward to a lively discussion. Thanks!

-Jason

[1] http://www.oracle.com/technetwork/java/eol-135779.html
[2]
https://blogs.oracle.com/java-platform-group/faster-and-easier-use-and-redistribution-of-java-se
[3]
https://www.oracle.com/java/java9-screencasts.html?bcid=5582439790001&playerType=single-social&size=events
[4]
http://blog.joda.org/2018/02/java-9-has-six-weeks-to-live.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+StephenColebournesBlog+%28Stephen+Colebourne%27s+blog%29
[5] https://issues.apache.org/jira/browse/CASSANDRA-9608

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

[Josh McKenzie]

Need a little clarification on something:

> 2) always release cassandra on a LTS version
combined with:
> 3) keep trunk on the lasest jdk version, assumming we release a major
> cassandra version close enough to a LTS release.

Wouldn't that potentially leave us in a situation where we're ready
for a C* release but blocked waiting on a new LTS cut? For example, if
JDK 9 were the currently supported LTS and trunk was on JDK 11, we'd
either have to get trunk to work with 9 or wait for 11 to resolve
that.

On Tue, Mar 20, 2018 at 9:32 AM, Jason Brown  wrote:
> Hi all,
>
>
> TL;DR Oracle has started revving the JDK version much faster, and we need
> an agreed upon plan.
>
> Well, we probably should has this discussion this already by now, but here
> we are. Oracle announced plans to release updated JDK version every six
> months, and each new version immediate supercedes the previous in all ways:
> no updates/security fixes to previous versions is the main thing, and
> previous versions are EOL'd immediately. In addition, Oracle has planned
> parallel LTS versions that will live for three years, and then superceded
> by the next LTS; but not immediately EOL'd from what I can tell. Please see
> [1, 2] for Oracle's offical comments about this change ([3] was
> particularly useful, imo), [4] and many other postings on the internet for
> discussion/commentary.
>
> We have a jira [5] where Robert Stupp did most of the work to get us onto
> Java 9 (thanks, Robert), but then the announcement of the JDK version
> changes happened last fall after Robert had done much of the work on the
> ticket.
>
> Here's an initial proposal of how to move forward. I don't suspect it's
> complete, but a decent place to start a conversation.
>
> 1) receommend OracleJDK over OpenJDK. IIUC from [3], the OpenJDK will
> release every six months, and the OracleJDK will release every three years.
> Thus, the OracleJDK is the LTS version, and it just comes from a snapshot
> of one of those OpenJDK builds.
>
> 2) always release cassandra on a LTS version. I don't think we can
> reasonably expect operators to update the JDK every six months, on time.
> Further, if there are breaking changes to the JDK, we don't want to have to
> update established c* versions due to those changes, every six months.
>
> 3) keep trunk on the lasest jdk version, assumming we release a major
> cassandra version close enough to a LTS release. Currently that seems
> reasonable for cassandra 4.0 to be released with java 11 (18.9 LTS)
> support. Perhaps we can evaluate this over time.
>
>
> Once we agree on a path forward, *it is impreative that we publish the
> decision to the docs* so we can point contributors and operators there,
> instead of rehashing the same conversation.
>
> I look forward to a lively discussion. Thanks!
>
> -Jason
>
> [1] http://www.oracle.com/technetwork/java/eol-135779.html
> [2]
> https://blogs.oracle.com/java-platform-group/faster-and-easier-use-and-redistribution-of-java-se
> [3]
> https://www.oracle.com/java/java9-screencasts.html?bcid=5582439790001&playerType=single-social&size=events
> [4]
> http://blog.joda.org/2018/02/java-9-has-six-weeks-to-live.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+StephenColebournesBlog+%28Stephen+Colebourne%27s+blog%29
> [5] https://issues.apache.org/jira/browse/CASSANDRA-9608

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

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

[Jason Brown]

>> Wouldn't that potentially leave us in a situation where we're ready for
a C* release but blocked waiting on a new LTS cut?

Agreed, and perhaps if we're close enough to a LTS release (say three
months or less), we could choose to delay (probably with community
input/vote). If we're a year or two out, then, no, we should not wait. I
think this is what I meant to communicate by "Perhaps we can evaluate this
over time." (poorly stated, in hindsight)

On Tue, Mar 20, 2018 at 7:22 AM, Josh McKenzie  wrote:

> Need a little clarification on something:
>
> > 2) always release cassandra on a LTS version
> combined with:
> > 3) keep trunk on the lasest jdk version, assumming we release a major
> > cassandra version close enough to a LTS release.
>
> Wouldn't that potentially leave us in a situation where we're ready
> for a C* release but blocked waiting on a new LTS cut? For example, if
> JDK 9 were the currently supported LTS and trunk was on JDK 11, we'd
> either have to get trunk to work with 9 or wait for 11 to resolve
> that.
>
> On Tue, Mar 20, 2018 at 9:32 AM, Jason Brown  wrote:
> > Hi all,
> >
> >
> > TL;DR Oracle has started revving the JDK version much faster, and we need
> > an agreed upon plan.
> >
> > Well, we probably should has this discussion this already by now, but
> here
> > we are. Oracle announced plans to release updated JDK version every six
> > months, and each new version immediate supercedes the previous in all
> ways:
> > no updates/security fixes to previous versions is the main thing, and
> > previous versions are EOL'd immediately. In addition, Oracle has planned
> > parallel LTS versions that will live for three years, and then superceded
> > by the next LTS; but not immediately EOL'd from what I can tell. Please
> see
> > [1, 2] for Oracle's offical comments about this change ([3] was
> > particularly useful, imo), [4] and many other postings on the internet
> for
> > discussion/commentary.
> >
> > We have a jira [5] where Robert Stupp did most of the work to get us onto
> > Java 9 (thanks, Robert), but then the announcement of the JDK version
> > changes happened last fall after Robert had done much of the work on the
> > ticket.
> >
> > Here's an initial proposal of how to move forward. I don't suspect it's
> > complete, but a decent place to start a conversation.
> >
> > 1) receommend OracleJDK over OpenJDK. IIUC from [3], the OpenJDK will
> > release every six months, and the OracleJDK will release every three
> years.
> > Thus, the OracleJDK is the LTS version, and it just comes from a snapshot
> > of one of those OpenJDK builds.
> >
> > 2) always release cassandra on a LTS version. I don't think we can
> > reasonably expect operators to update the JDK every six months, on time.
> > Further, if there are breaking changes to the JDK, we don't want to have
> to
> > update established c* versions due to those changes, every six months.
> >
> > 3) keep trunk on the lasest jdk version, assumming we release a major
> > cassandra version close enough to a LTS release. Currently that seems
> > reasonable for cassandra 4.0 to be released with java 11 (18.9 LTS)
> > support. Perhaps we can evaluate this over time.
> >
> >
> > Once we agree on a path forward, *it is impreative that we publish the
> > decision to the docs* so we can point contributors and operators there,
> > instead of rehashing the same conversation.
> >
> > I look forward to a lively discussion. Thanks!
> >
> > -Jason
> >
> > [1] http://www.oracle.com/technetwork/java/eol-135779.html
> > [2]
> > https://blogs.oracle.com/java-platform-group/faster-and-
> easier-use-and-redistribution-of-java-se
> > [3]
> > https://www.oracle.com/java/java9-screencasts.html?bcid=
> 5582439790001&playerType=single-social&size=events
> > [4]
> > http://blog.joda.org/2018/02/java-9-has-six-weeks-to-live.
> html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+
> StephenColebournesBlog+%28Stephen+Colebourne%27s+blog%29
> > [5] https://issues.apache.org/jira/browse/CASSANDRA-9608
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

[Robert Stupp]

Don't forget that you have to spend bucks to get LTS.

My hope is that after that Java 9, upcoming releases should be smoother 
to use. I.e. settling the C* release on the Java release that's current 
at that point in time sounds good enough. I.e. my hope is that any C* 
release made for Java X will work with Java X+n (in the foreseeable 
future). Caveat is probably the use of "Unsafe"...


For example, if a major release would be planned for April, supporting 
Java 10 should be good enough. But that C* major release should stay on 
Java 10 and no code that requires a newer Java version must get in.


I'm not sure whether recommending OracleJDK over OpenJDK is required. 
You get some goodies with OracleJDK (CAs for example), sure.


On 03/20/2018 03:22 PM, Josh McKenzie wrote:

Need a little clarification on something:


2) always release cassandra on a LTS version

combined with:

3) keep trunk on the lasest jdk version, assumming we release a major
cassandra version close enough to a LTS release.

Wouldn't that potentially leave us in a situation where we're ready
for a C* release but blocked waiting on a new LTS cut? For example, if
JDK 9 were the currently supported LTS and trunk was on JDK 11, we'd
either have to get trunk to work with 9 or wait for 11 to resolve
that.

On Tue, Mar 20, 2018 at 9:32 AM, Jason Brown  wrote:

Hi all,


TL;DR Oracle has started revving the JDK version much faster, and we need
an agreed upon plan.

Well, we probably should has this discussion this already by now, but here
we are. Oracle announced plans to release updated JDK version every six
months, and each new version immediate supercedes the previous in all ways:
no updates/security fixes to previous versions is the main thing, and
previous versions are EOL'd immediately. In addition, Oracle has planned
parallel LTS versions that will live for three years, and then superceded
by the next LTS; but not immediately EOL'd from what I can tell. Please see
[1, 2] for Oracle's offical comments about this change ([3] was
particularly useful, imo), [4] and many other postings on the internet for
discussion/commentary.

We have a jira [5] where Robert Stupp did most of the work to get us onto
Java 9 (thanks, Robert), but then the announcement of the JDK version
changes happened last fall after Robert had done much of the work on the
ticket.

Here's an initial proposal of how to move forward. I don't suspect it's
complete, but a decent place to start a conversation.

1) receommend OracleJDK over OpenJDK. IIUC from [3], the OpenJDK will
release every six months, and the OracleJDK will release every three years.
Thus, the OracleJDK is the LTS version, and it just comes from a snapshot
of one of those OpenJDK builds.

2) always release cassandra on a LTS version. I don't think we can
reasonably expect operators to update the JDK every six months, on time.
Further, if there are breaking changes to the JDK, we don't want to have to
update established c* versions due to those changes, every six months.

3) keep trunk on the lasest jdk version, assumming we release a major
cassandra version close enough to a LTS release. Currently that seems
reasonable for cassandra 4.0 to be released with java 11 (18.9 LTS)
support. Perhaps we can evaluate this over time.


Once we agree on a path forward, *it is impreative that we publish the
decision to the docs* so we can point contributors and operators there,
instead of rehashing the same conversation.

I look forward to a lively discussion. Thanks!

-Jason

[1] http://www.oracle.com/technetwork/java/eol-135779.html
[2]
https://blogs.oracle.com/java-platform-group/faster-and-easier-use-and-redistribution-of-java-se
[3]
https://www.oracle.com/java/java9-screencasts.html?bcid=5582439790001&playerType=single-social&size=events
[4]
http://blog.joda.org/2018/02/java-9-has-six-weeks-to-live.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+StephenColebournesBlog+%28Stephen+Colebourne%27s+blog%29
[5] https://issues.apache.org/jira/browse/CASSANDRA-9608

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



--
Robert Stupp
@snazy


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

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

[Jason Brown]

>> Don't forget that you have to spend bucks to get LTS.

Huh? Is that true? Can you point me to any docs that I may have missed?
That would be an important point to consider.

>> supporting Java 10 should be good enough.

Sure but what about 2 years after we release a major, on a JDK that is 2-4
versions outdated? Are we going to get requests to keep
upgrading/validating all 'live' versions under the JDK flavor of the month?
That's what I'd like to avoid, if it's at all possible.

On Tue, Mar 20, 2018 at 7:56 AM, Robert Stupp  wrote:

> Don't forget that you have to spend bucks to get LTS.
>
> My hope is that after that Java 9, upcoming releases should be smoother to
> use. I.e. settling the C* release on the Java release that's current at
> that point in time sounds good enough. I.e. my hope is that any C* release
> made for Java X will work with Java X+n (in the foreseeable future). Caveat
> is probably the use of "Unsafe"...
>
> For example, if a major release would be planned for April, supporting
> Java 10 should be good enough. But that C* major release should stay on
> Java 10 and no code that requires a newer Java version must get in.
>
> I'm not sure whether recommending OracleJDK over OpenJDK is required. You
> get some goodies with OracleJDK (CAs for example), sure.
>
>
> On 03/20/2018 03:22 PM, Josh McKenzie wrote:
>
>> Need a little clarification on something:
>>
>> 2) always release cassandra on a LTS version
>>>
>> combined with:
>>
>>> 3) keep trunk on the lasest jdk version, assumming we release a major
>>> cassandra version close enough to a LTS release.
>>>
>> Wouldn't that potentially leave us in a situation where we're ready
>> for a C* release but blocked waiting on a new LTS cut? For example, if
>> JDK 9 were the currently supported LTS and trunk was on JDK 11, we'd
>> either have to get trunk to work with 9 or wait for 11 to resolve
>> that.
>>
>> On Tue, Mar 20, 2018 at 9:32 AM, Jason Brown 
>> wrote:
>>
>>> Hi all,
>>>
>>>
>>> TL;DR Oracle has started revving the JDK version much faster, and we need
>>> an agreed upon plan.
>>>
>>> Well, we probably should has this discussion this already by now, but
>>> here
>>> we are. Oracle announced plans to release updated JDK version every six
>>> months, and each new version immediate supercedes the previous in all
>>> ways:
>>> no updates/security fixes to previous versions is the main thing, and
>>> previous versions are EOL'd immediately. In addition, Oracle has planned
>>> parallel LTS versions that will live for three years, and then superceded
>>> by the next LTS; but not immediately EOL'd from what I can tell. Please
>>> see
>>> [1, 2] for Oracle's offical comments about this change ([3] was
>>> particularly useful, imo), [4] and many other postings on the internet
>>> for
>>> discussion/commentary.
>>>
>>> We have a jira [5] where Robert Stupp did most of the work to get us onto
>>> Java 9 (thanks, Robert), but then the announcement of the JDK version
>>> changes happened last fall after Robert had done much of the work on the
>>> ticket.
>>>
>>> Here's an initial proposal of how to move forward. I don't suspect it's
>>> complete, but a decent place to start a conversation.
>>>
>>> 1) receommend OracleJDK over OpenJDK. IIUC from [3], the OpenJDK will
>>> release every six months, and the OracleJDK will release every three
>>> years.
>>> Thus, the OracleJDK is the LTS version, and it just comes from a snapshot
>>> of one of those OpenJDK builds.
>>>
>>> 2) always release cassandra on a LTS version. I don't think we can
>>> reasonably expect operators to update the JDK every six months, on time.
>>> Further, if there are breaking changes to the JDK, we don't want to have
>>> to
>>> update established c* versions due to those changes, every six months.
>>>
>>> 3) keep trunk on the lasest jdk version, assumming we release a major
>>> cassandra version close enough to a LTS release. Currently that seems
>>> reasonable for cassandra 4.0 to be released with java 11 (18.9 LTS)
>>> support. Perhaps we can evaluate this over time.
>>>
>>>
>>> Once we agree on a path forward, *it is impreative that we publish the
>>> decision to the docs* so we can point contributors and operators there,
>>> instead of rehashing the same conversation.
>>>
>>> I look forward to a lively discussion. Thanks!
>>>
>>> -Jason
>>>
>>> [1] http://www.oracle.com/technetwork/java/eol-135779.html
>>> [2]
>>> https://blogs.oracle.com/java-platform-group/faster-and-easi
>>> er-use-and-redistribution-of-java-se
>>> [3]
>>> https://www.oracle.com/java/java9-screencasts.html?bcid=5582
>>> 439790001&playerType=single-social&size=events
>>> [4]
>>> http://blog.joda.org/2018/02/java-9-has-six-weeks-to-live.ht
>>> ml?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%
>>> 3A+StephenColebournesBlog+%28Stephen+Colebourne%27s+blog%29
>>> [5] https://issues.apache.org/jira/browse/CASSANDRA-9608
>>>
>> -
>> To 

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

[Hannu Kröger]

When reading about the LTS and JDK being non-free, OracleJDK 
requirement/recommendation seems like a sub-optimal idea:
https://medium.com/codefx-weekly/no-free-java-lts-version-b850192745fb

Hannu

> On 20 Mar 2018, at 16:56, Robert Stupp  wrote:
> 
> Don't forget that you have to spend bucks to get LTS.
> 
> My hope is that after that Java 9, upcoming releases should be smoother to 
> use. I.e. settling the C* release on the Java release that's current at that 
> point in time sounds good enough. I.e. my hope is that any C* release made 
> for Java X will work with Java X+n (in the foreseeable future). Caveat is 
> probably the use of "Unsafe"...
> 
> For example, if a major release would be planned for April, supporting Java 
> 10 should be good enough. But that C* major release should stay on Java 10 
> and no code that requires a newer Java version must get in.
> 
> I'm not sure whether recommending OracleJDK over OpenJDK is required. You get 
> some goodies with OracleJDK (CAs for example), sure.
> 
> On 03/20/2018 03:22 PM, Josh McKenzie wrote:
>> Need a little clarification on something:
>> 
>>> 2) always release cassandra on a LTS version
>> combined with:
>>> 3) keep trunk on the lasest jdk version, assumming we release a major
>>> cassandra version close enough to a LTS release.
>> Wouldn't that potentially leave us in a situation where we're ready
>> for a C* release but blocked waiting on a new LTS cut? For example, if
>> JDK 9 were the currently supported LTS and trunk was on JDK 11, we'd
>> either have to get trunk to work with 9 or wait for 11 to resolve
>> that.
>> 
>> On Tue, Mar 20, 2018 at 9:32 AM, Jason Brown  wrote:
>>> Hi all,
>>> 
>>> 
>>> TL;DR Oracle has started revving the JDK version much faster, and we need
>>> an agreed upon plan.
>>> 
>>> Well, we probably should has this discussion this already by now, but here
>>> we are. Oracle announced plans to release updated JDK version every six
>>> months, and each new version immediate supercedes the previous in all ways:
>>> no updates/security fixes to previous versions is the main thing, and
>>> previous versions are EOL'd immediately. In addition, Oracle has planned
>>> parallel LTS versions that will live for three years, and then superceded
>>> by the next LTS; but not immediately EOL'd from what I can tell. Please see
>>> [1, 2] for Oracle's offical comments about this change ([3] was
>>> particularly useful, imo), [4] and many other postings on the internet for
>>> discussion/commentary.
>>> 
>>> We have a jira [5] where Robert Stupp did most of the work to get us onto
>>> Java 9 (thanks, Robert), but then the announcement of the JDK version
>>> changes happened last fall after Robert had done much of the work on the
>>> ticket.
>>> 
>>> Here's an initial proposal of how to move forward. I don't suspect it's
>>> complete, but a decent place to start a conversation.
>>> 
>>> 1) receommend OracleJDK over OpenJDK. IIUC from [3], the OpenJDK will
>>> release every six months, and the OracleJDK will release every three years.
>>> Thus, the OracleJDK is the LTS version, and it just comes from a snapshot
>>> of one of those OpenJDK builds.
>>> 
>>> 2) always release cassandra on a LTS version. I don't think we can
>>> reasonably expect operators to update the JDK every six months, on time.
>>> Further, if there are breaking changes to the JDK, we don't want to have to
>>> update established c* versions due to those changes, every six months.
>>> 
>>> 3) keep trunk on the lasest jdk version, assumming we release a major
>>> cassandra version close enough to a LTS release. Currently that seems
>>> reasonable for cassandra 4.0 to be released with java 11 (18.9 LTS)
>>> support. Perhaps we can evaluate this over time.
>>> 
>>> 
>>> Once we agree on a path forward, *it is impreative that we publish the
>>> decision to the docs* so we can point contributors and operators there,
>>> instead of rehashing the same conversation.
>>> 
>>> I look forward to a lively discussion. Thanks!
>>> 
>>> -Jason
>>> 
>>> [1] http://www.oracle.com/technetwork/java/eol-135779.html
>>> [2]
>>> https://blogs.oracle.com/java-platform-group/faster-and-easier-use-and-redistribution-of-java-se
>>> [3]
>>> https://www.oracle.com/java/java9-screencasts.html?bcid=5582439790001&playerType=single-social&size=events
>>> [4]
>>> http://blog.joda.org/2018/02/java-9-has-six-weeks-to-live.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+StephenColebournesBlog+%28Stephen+Colebourne%27s+blog%29
>>> [5] https://issues.apache.org/jira/browse/CASSANDRA-9608
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
> 
> -- 
> Robert Stupp
> @snazy
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-ma

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

[Jeremiah Jordan]

My suggestion would be to keep trunk on the latest LTS by default, but with 
compatibility with the latest release if possible.  Since Oracle LTS releases 
are every 3 years, I would not want to tie us to that release cycle?
So until Java 11 is out that would mean trunk should work under Java 8, with 
the option of being compiled/run under Java 9 or 10.  Once Java 11 is out we 
could then switch to 11 only.

-Jeremiah

On Mar 20, 2018, at 10:48 AM, Jason Brown  wrote:

>>> Wouldn't that potentially leave us in a situation where we're ready for
> a C* release but blocked waiting on a new LTS cut?
> 
> Agreed, and perhaps if we're close enough to a LTS release (say three
> months or less), we could choose to delay (probably with community
> input/vote). If we're a year or two out, then, no, we should not wait. I
> think this is what I meant to communicate by "Perhaps we can evaluate this
> over time." (poorly stated, in hindsight)
> 
>> On Tue, Mar 20, 2018 at 7:22 AM, Josh McKenzie  wrote:
>> 
>> Need a little clarification on something:
>> 
>>> 2) always release cassandra on a LTS version
>> combined with:
>>> 3) keep trunk on the lasest jdk version, assumming we release a major
>>> cassandra version close enough to a LTS release.
>> 
>> Wouldn't that potentially leave us in a situation where we're ready
>> for a C* release but blocked waiting on a new LTS cut? For example, if
>> JDK 9 were the currently supported LTS and trunk was on JDK 11, we'd
>> either have to get trunk to work with 9 or wait for 11 to resolve
>> that.
>> 
>>> On Tue, Mar 20, 2018 at 9:32 AM, Jason Brown  wrote:
>>> Hi all,
>>> 
>>> 
>>> TL;DR Oracle has started revving the JDK version much faster, and we need
>>> an agreed upon plan.
>>> 
>>> Well, we probably should has this discussion this already by now, but
>> here
>>> we are. Oracle announced plans to release updated JDK version every six
>>> months, and each new version immediate supercedes the previous in all
>> ways:
>>> no updates/security fixes to previous versions is the main thing, and
>>> previous versions are EOL'd immediately. In addition, Oracle has planned
>>> parallel LTS versions that will live for three years, and then superceded
>>> by the next LTS; but not immediately EOL'd from what I can tell. Please
>> see
>>> [1, 2] for Oracle's offical comments about this change ([3] was
>>> particularly useful, imo), [4] and many other postings on the internet
>> for
>>> discussion/commentary.
>>> 
>>> We have a jira [5] where Robert Stupp did most of the work to get us onto
>>> Java 9 (thanks, Robert), but then the announcement of the JDK version
>>> changes happened last fall after Robert had done much of the work on the
>>> ticket.
>>> 
>>> Here's an initial proposal of how to move forward. I don't suspect it's
>>> complete, but a decent place to start a conversation.
>>> 
>>> 1) receommend OracleJDK over OpenJDK. IIUC from [3], the OpenJDK will
>>> release every six months, and the OracleJDK will release every three
>> years.
>>> Thus, the OracleJDK is the LTS version, and it just comes from a snapshot
>>> of one of those OpenJDK builds.
>>> 
>>> 2) always release cassandra on a LTS version. I don't think we can
>>> reasonably expect operators to update the JDK every six months, on time.
>>> Further, if there are breaking changes to the JDK, we don't want to have
>> to
>>> update established c* versions due to those changes, every six months.
>>> 
>>> 3) keep trunk on the lasest jdk version, assumming we release a major
>>> cassandra version close enough to a LTS release. Currently that seems
>>> reasonable for cassandra 4.0 to be released with java 11 (18.9 LTS)
>>> support. Perhaps we can evaluate this over time.
>>> 
>>> 
>>> Once we agree on a path forward, *it is impreative that we publish the
>>> decision to the docs* so we can point contributors and operators there,
>>> instead of rehashing the same conversation.
>>> 
>>> I look forward to a lively discussion. Thanks!
>>> 
>>> -Jason
>>> 
>>> [1] http://www.oracle.com/technetwork/java/eol-135779.html
>>> [2]
>>> https://blogs.oracle.com/java-platform-group/faster-and-
>> easier-use-and-redistribution-of-java-se
>>> [3]
>>> https://www.oracle.com/java/java9-screencasts.html?bcid=
>> 5582439790001&playerType=single-social&size=events
>>> [4]
>>> http://blog.joda.org/2018/02/java-9-has-six-weeks-to-live.
>> html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+
>> StephenColebournesBlog+%28Stephen+Colebourne%27s+blog%29
>>> [5] https://issues.apache.org/jira/browse/CASSANDRA-9608
>> 
>> -
>> 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: [DISCUSS] java 9 and the future of cassandra on the jdk

[Ariel Weisberg]

Hi,

+1 to what Jordan is saying.

It seems like if we are cutting a release off of trunk we want to make sure we 
get N years of supported JDK out of it. For a single LTS release N could be at 
most 3 and historically that isn't long enough and it's very likely we will get 
< 3 after a release is cut.

Going beyond 3 years could be tricky in the worst case because bringing in up 
to 3 years of JDK changes to an older release might mean some of our 
dependencies no longer function and now it's not just minor fixes it's bringing 
in who knows what in terms of updated dependencies.

I think in some cases we are going to need to take a release we have already 
cut and make it work with an LTS release that didn't exist when the release was 
cut.

We also need to update how CI works. We should at least build and run a quick 
smoke test with the JDKs we are claiming to support and asynchronously run all 
the tests on the rather large matrix that now exists.

Ariel

On Tue, Mar 20, 2018, at 11:07 AM, Jeremiah Jordan wrote:
> My suggestion would be to keep trunk on the latest LTS by default, but 
> with compatibility with the latest release if possible.  Since Oracle 
> LTS releases are every 3 years, I would not want to tie us to that 
> release cycle?
> So until Java 11 is out that would mean trunk should work under Java 8, 
> with the option of being compiled/run under Java 9 or 10.  Once Java 11 
> is out we could then switch to 11 only.
> 
> -Jeremiah
> 
> On Mar 20, 2018, at 10:48 AM, Jason Brown  wrote:
> 
> >>> Wouldn't that potentially leave us in a situation where we're ready for
> > a C* release but blocked waiting on a new LTS cut?
> > 
> > Agreed, and perhaps if we're close enough to a LTS release (say three
> > months or less), we could choose to delay (probably with community
> > input/vote). If we're a year or two out, then, no, we should not wait. I
> > think this is what I meant to communicate by "Perhaps we can evaluate this
> > over time." (poorly stated, in hindsight)
> > 
> >> On Tue, Mar 20, 2018 at 7:22 AM, Josh McKenzie  
> >> wrote:
> >> 
> >> Need a little clarification on something:
> >> 
> >>> 2) always release cassandra on a LTS version
> >> combined with:
> >>> 3) keep trunk on the lasest jdk version, assumming we release a major
> >>> cassandra version close enough to a LTS release.
> >> 
> >> Wouldn't that potentially leave us in a situation where we're ready
> >> for a C* release but blocked waiting on a new LTS cut? For example, if
> >> JDK 9 were the currently supported LTS and trunk was on JDK 11, we'd
> >> either have to get trunk to work with 9 or wait for 11 to resolve
> >> that.
> >> 
> >>> On Tue, Mar 20, 2018 at 9:32 AM, Jason Brown  wrote:
> >>> Hi all,
> >>> 
> >>> 
> >>> TL;DR Oracle has started revving the JDK version much faster, and we need
> >>> an agreed upon plan.
> >>> 
> >>> Well, we probably should has this discussion this already by now, but
> >> here
> >>> we are. Oracle announced plans to release updated JDK version every six
> >>> months, and each new version immediate supercedes the previous in all
> >> ways:
> >>> no updates/security fixes to previous versions is the main thing, and
> >>> previous versions are EOL'd immediately. In addition, Oracle has planned
> >>> parallel LTS versions that will live for three years, and then superceded
> >>> by the next LTS; but not immediately EOL'd from what I can tell. Please
> >> see
> >>> [1, 2] for Oracle's offical comments about this change ([3] was
> >>> particularly useful, imo), [4] and many other postings on the internet
> >> for
> >>> discussion/commentary.
> >>> 
> >>> We have a jira [5] where Robert Stupp did most of the work to get us onto
> >>> Java 9 (thanks, Robert), but then the announcement of the JDK version
> >>> changes happened last fall after Robert had done much of the work on the
> >>> ticket.
> >>> 
> >>> Here's an initial proposal of how to move forward. I don't suspect it's
> >>> complete, but a decent place to start a conversation.
> >>> 
> >>> 1) receommend OracleJDK over OpenJDK. IIUC from [3], the OpenJDK will
> >>> release every six months, and the OracleJDK will release every three
> >> years.
> >>> Thus, the OracleJDK is the LTS version, and it just comes from a snapshot
> >>> of one of those OpenJDK builds.
> >>> 
> >>> 2) always release cassandra on a LTS version. I don't think we can
> >>> reasonably expect operators to update the JDK every six months, on time.
> >>> Further, if there are breaking changes to the JDK, we don't want to have
> >> to
> >>> update established c* versions due to those changes, every six months.
> >>> 
> >>> 3) keep trunk on the lasest jdk version, assumming we release a major
> >>> cassandra version close enough to a LTS release. Currently that seems
> >>> reasonable for cassandra 4.0 to be released with java 11 (18.9 LTS)
> >>> support. Perhaps we can evaluate this over time.
> >>> 
> >>> 
> >>> Once we agree on a path forward, *it is impreative that

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

[Kant Kodali]

Java 10 is releasing today!

On Tue, Mar 20, 2018 at 9:07 AM, Ariel Weisberg  wrote:

> Hi,
>
> +1 to what Jordan is saying.
>
> It seems like if we are cutting a release off of trunk we want to make
> sure we get N years of supported JDK out of it. For a single LTS release N
> could be at most 3 and historically that isn't long enough and it's very
> likely we will get < 3 after a release is cut.
>
> Going beyond 3 years could be tricky in the worst case because bringing in
> up to 3 years of JDK changes to an older release might mean some of our
> dependencies no longer function and now it's not just minor fixes it's
> bringing in who knows what in terms of updated dependencies.
>
> I think in some cases we are going to need to take a release we have
> already cut and make it work with an LTS release that didn't exist when the
> release was cut.
>
> We also need to update how CI works. We should at least build and run a
> quick smoke test with the JDKs we are claiming to support and
> asynchronously run all the tests on the rather large matrix that now exists.
>
> Ariel
>
> On Tue, Mar 20, 2018, at 11:07 AM, Jeremiah Jordan wrote:
> > My suggestion would be to keep trunk on the latest LTS by default, but
> > with compatibility with the latest release if possible.  Since Oracle
> > LTS releases are every 3 years, I would not want to tie us to that
> > release cycle?
> > So until Java 11 is out that would mean trunk should work under Java 8,
> > with the option of being compiled/run under Java 9 or 10.  Once Java 11
> > is out we could then switch to 11 only.
> >
> > -Jeremiah
> >
> > On Mar 20, 2018, at 10:48 AM, Jason Brown  wrote:
> >
> > >>> Wouldn't that potentially leave us in a situation where we're ready
> for
> > > a C* release but blocked waiting on a new LTS cut?
> > >
> > > Agreed, and perhaps if we're close enough to a LTS release (say three
> > > months or less), we could choose to delay (probably with community
> > > input/vote). If we're a year or two out, then, no, we should not wait.
> I
> > > think this is what I meant to communicate by "Perhaps we can evaluate
> this
> > > over time." (poorly stated, in hindsight)
> > >
> > >> On Tue, Mar 20, 2018 at 7:22 AM, Josh McKenzie 
> wrote:
> > >>
> > >> Need a little clarification on something:
> > >>
> > >>> 2) always release cassandra on a LTS version
> > >> combined with:
> > >>> 3) keep trunk on the lasest jdk version, assumming we release a major
> > >>> cassandra version close enough to a LTS release.
> > >>
> > >> Wouldn't that potentially leave us in a situation where we're ready
> > >> for a C* release but blocked waiting on a new LTS cut? For example, if
> > >> JDK 9 were the currently supported LTS and trunk was on JDK 11, we'd
> > >> either have to get trunk to work with 9 or wait for 11 to resolve
> > >> that.
> > >>
> > >>> On Tue, Mar 20, 2018 at 9:32 AM, Jason Brown 
> wrote:
> > >>> Hi all,
> > >>>
> > >>>
> > >>> TL;DR Oracle has started revving the JDK version much faster, and we
> need
> > >>> an agreed upon plan.
> > >>>
> > >>> Well, we probably should has this discussion this already by now, but
> > >> here
> > >>> we are. Oracle announced plans to release updated JDK version every
> six
> > >>> months, and each new version immediate supercedes the previous in all
> > >> ways:
> > >>> no updates/security fixes to previous versions is the main thing, and
> > >>> previous versions are EOL'd immediately. In addition, Oracle has
> planned
> > >>> parallel LTS versions that will live for three years, and then
> superceded
> > >>> by the next LTS; but not immediately EOL'd from what I can tell.
> Please
> > >> see
> > >>> [1, 2] for Oracle's offical comments about this change ([3] was
> > >>> particularly useful, imo), [4] and many other postings on the
> internet
> > >> for
> > >>> discussion/commentary.
> > >>>
> > >>> We have a jira [5] where Robert Stupp did most of the work to get us
> onto
> > >>> Java 9 (thanks, Robert), but then the announcement of the JDK version
> > >>> changes happened last fall after Robert had done much of the work on
> the
> > >>> ticket.
> > >>>
> > >>> Here's an initial proposal of how to move forward. I don't suspect
> it's
> > >>> complete, but a decent place to start a conversation.
> > >>>
> > >>> 1) receommend OracleJDK over OpenJDK. IIUC from [3], the OpenJDK will
> > >>> release every six months, and the OracleJDK will release every three
> > >> years.
> > >>> Thus, the OracleJDK is the LTS version, and it just comes from a
> snapshot
> > >>> of one of those OpenJDK builds.
> > >>>
> > >>> 2) always release cassandra on a LTS version. I don't think we can
> > >>> reasonably expect operators to update the JDK every six months, on
> time.
> > >>> Further, if there are breaking changes to the JDK, we don't want to
> have
> > >> to
> > >>> update established c* versions due to those changes, every six
> months.
> > >>>
> > >>> 3) keep trunk on the lasest jdk version, assumming we release a m

Re: Debug logging enabled by default since 2.2

[Ariel Weisberg]

Hi,

Signal to noise ratio matters for logs. Things that we log at DEBUG aren't at 
all bound by constraints of human readability or being particularly relevant 
most of the time. I don't want to see most of this stuff unless I have already 
not found what I am looking for at INFO and above.

Can we at least maintain the separation of what is effectively debug logging 
(switching to an annotation aside) from INFO and above? I want to avoid two 
steps forward one step back.

Ariel
On Tue, Mar 20, 2018, at 9:23 AM, Paulo Motta wrote:
> That sounds like a good plan, Alexander! Thanks!
> 
> Stefan, someone needs to go through all messages being logged at DEBUG
> and reclassify important ones as INFO. I suggest continuing discussion
> on specifics on CASSANDRA-14326.
> 
> 2018-03-20 6:46 GMT-03:00 Stefan Podkowinski :
> > Are you suggesting to move all messages currently logged via debug() to
> > info() with the additional marker set, or only particular messages?
> >
> >
> > On 19.03.2018 19: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://www.slf4j.org/faq.html#fatal 
> >>> 
> >>>
> >>>
> >
> > -
> > 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: Debug logging enabled by default since 2.2

[Ariel Weisberg]

Hi,

Another point I want to mention. Another reason we separate the files is that 
they can then use separate log rolling policies. A verbose debug log no longer 
rolls the INFO level system.log.

Ariel

On Tue, Mar 20, 2018, at 12:19 PM, Ariel Weisberg wrote:
> Hi,
> 
> Signal to noise ratio matters for logs. Things that we log at DEBUG 
> aren't at all bound by constraints of human readability or being 
> particularly relevant most of the time. I don't want to see most of this 
> stuff unless I have already not found what I am looking for at INFO and 
> above.
> 
> Can we at least maintain the separation of what is effectively debug 
> logging (switching to an annotation aside) from INFO and above? I want 
> to avoid two steps forward one step back.
> 
> Ariel
> On Tue, Mar 20, 2018, at 9:23 AM, Paulo Motta wrote:
> > That sounds like a good plan, Alexander! Thanks!
> > 
> > Stefan, someone needs to go through all messages being logged at DEBUG
> > and reclassify important ones as INFO. I suggest continuing discussion
> > on specifics on CASSANDRA-14326.
> > 
> > 2018-03-20 6:46 GMT-03:00 Stefan Podkowinski :
> > > Are you suggesting to move all messages currently logged via debug() to
> > > info() with the additional marker set, or only particular messages?
> > >
> > >
> > > On 19.03.2018 19: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://www.slf4j.org/faq.html#fatal 
> > >>> 
> > >>>
> > >>>
> > >
> > > -
> > > 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-

Re: Debug logging enabled by default since 2.2

[Alexander Dejanovski]

Ariel,

the current plan that's discussed on the ticket (
https://issues.apache.org/jira/browse/CASSANDRA-14326) is to maintain the
separation and keep the debug.log for "real" DEBUG level logging, which
would be disabled by default.
A new intermediate marker would be created to have VERBOSE_INFO logging
(some current debug loggings must be changed to that new level/marker),
which would be enabled by default, and "standard" INFO logging would go to
system.log.

I guess in that configuration, some/most TRACE level loggings would then be
eligible to graduate to DEBUG...?




On Tue, Mar 20, 2018 at 4:19 PM Ariel Weisberg  wrote:

> Hi,
>
> Signal to noise ratio matters for logs. Things that we log at DEBUG aren't
> at all bound by constraints of human readability or being particularly
> relevant most of the time. I don't want to see most of this stuff unless I
> have already not found what I am looking for at INFO and above.
>
> Can we at least maintain the separation of what is effectively debug
> logging (switching to an annotation aside) from INFO and above? I want to
> avoid two steps forward one step back.
>
> Ariel
> On Tue, Mar 20, 2018, at 9:23 AM, Paulo Motta wrote:
> > That sounds like a good plan, Alexander! Thanks!
> >
> > Stefan, someone needs to go through all messages being logged at DEBUG
> > and reclassify important ones as INFO. I suggest continuing discussion
> > on specifics on CASSANDRA-14326.
> >
> > 2018-03-20 6:46 GMT-03:00 Stefan Podkowinski :
> > > Are you suggesting to move all messages currently logged via debug() to
> > > info() with the additional marker set, or only particular messages?
> > >
> > >
> > > On 19.03.2018 19: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 <
> https://www.slf4j.org/faq.html#fatal>
> > >>>
> > >>>
> > >
> > > -
> > > 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

[Ariel Weisberg]

Hi,

That's good to hear.

What's the difference between DEBUG and TRACE? Obviously we decide ourselves. I 
don't have a good answer because right now we are in the process of eliminating 
the distinction we used to make which is that DEBUG is safe to turn on in 
production and TRACE is not.

Ariel

On Tue, Mar 20, 2018, at 12:36 PM, Alexander Dejanovski wrote:
> Ariel,
> 
> the current plan that's discussed on the ticket (
> https://issues.apache.org/jira/browse/CASSANDRA-14326) is to maintain the
> separation and keep the debug.log for "real" DEBUG level logging, which
> would be disabled by default.
> A new intermediate marker would be created to have VERBOSE_INFO logging
> (some current debug loggings must be changed to that new level/marker),
> which would be enabled by default, and "standard" INFO logging would go to
> system.log.
> 
> I guess in that configuration, some/most TRACE level loggings would then be
> eligible to graduate to DEBUG...?
> 
> 
> 
> 
> On Tue, Mar 20, 2018 at 4:19 PM Ariel Weisberg  wrote:
> 
> > Hi,
> >
> > Signal to noise ratio matters for logs. Things that we log at DEBUG aren't
> > at all bound by constraints of human readability or being particularly
> > relevant most of the time. I don't want to see most of this stuff unless I
> > have already not found what I am looking for at INFO and above.
> >
> > Can we at least maintain the separation of what is effectively debug
> > logging (switching to an annotation aside) from INFO and above? I want to
> > avoid two steps forward one step back.
> >
> > Ariel
> > On Tue, Mar 20, 2018, at 9:23 AM, Paulo Motta wrote:
> > > That sounds like a good plan, Alexander! Thanks!
> > >
> > > Stefan, someone needs to go through all messages being logged at DEBUG
> > > and reclassify important ones as INFO. I suggest continuing discussion
> > > on specifics on CASSANDRA-14326.
> > >
> > > 2018-03-20 6:46 GMT-03:00 Stefan Podkowinski :
> > > > Are you suggesting to move all messages currently logged via debug() to
> > > > info() with the additional marker set, or only particular messages?
> > > >
> > > >
> > > > On 19.03.2018 19: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
> > > >>

Re: Debug logging enabled by default since 2.2

[Alexander Dejanovski]

That's a good question.

At this point ¯\_(ツ)_/¯

On Tue, Mar 20, 2018 at 4:42 PM Ariel Weisberg  wrote:

> Hi,
>
> That's good to hear.
>
> What's the difference between DEBUG and TRACE? Obviously we decide
> ourselves. I don't have a good answer because right now we are in the
> process of eliminating the distinction we used to make which is that DEBUG
> is safe to turn on in production and TRACE is not.
>
> Ariel
>
> On Tue, Mar 20, 2018, at 12:36 PM, Alexander Dejanovski wrote:
> > Ariel,
> >
> > the current plan that's discussed on the ticket (
> > https://issues.apache.org/jira/browse/CASSANDRA-14326) is to maintain
> the
> > separation and keep the debug.log for "real" DEBUG level logging, which
> > would be disabled by default.
> > A new intermediate marker would be created to have VERBOSE_INFO logging
> > (some current debug loggings must be changed to that new level/marker),
> > which would be enabled by default, and "standard" INFO logging would go
> to
> > system.log.
> >
> > I guess in that configuration, some/most TRACE level loggings would then
> be
> > eligible to graduate to DEBUG...?
> >
> >
> >
> >
> > On Tue, Mar 20, 2018 at 4:19 PM Ariel Weisberg 
> wrote:
> >
> > > Hi,
> > >
> > > Signal to noise ratio matters for logs. Things that we log at DEBUG
> aren't
> > > at all bound by constraints of human readability or being particularly
> > > relevant most of the time. I don't want to see most of this stuff
> unless I
> > > have already not found what I am looking for at INFO and above.
> > >
> > > Can we at least maintain the separation of what is effectively debug
> > > logging (switching to an annotation aside) from INFO and above? I want
> to
> > > avoid two steps forward one step back.
> > >
> > > Ariel
> > > On Tue, Mar 20, 2018, at 9:23 AM, Paulo Motta wrote:
> > > > That sounds like a good plan, Alexander! Thanks!
> > > >
> > > > Stefan, someone needs to go through all messages being logged at
> DEBUG
> > > > and reclassify important ones as INFO. I suggest continuing
> discussion
> > > > on specifics on CASSANDRA-14326.
> > > >
> > > > 2018-03-20 6:46 GMT-03:00 Stefan Podkowinski :
> > > > > Are you suggesting to move all messages currently logged via
> debug() to
> > > > > info() with the additional marker set, or only particular messages?
> > > > >
> > > > >
> > > > > On 19.03.2018 19: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 <
> jerem...@datastax.com>:
> > > > >>> 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
> > > >

Re: Debug logging enabled by default since 2.2

[J. D. Jordan]

Ariel can we move discussion to the ticket now that we have one open?  That way 
we can keep all thoughts in one place. Thanks.
https://issues.apache.org/jira/browse/CASSANDRA-14326


> On Mar 20, 2018, at 12:42 PM, Ariel Weisberg  wrote:
> 
> Hi,
> 
> That's good to hear.
> 
> What's the difference between DEBUG and TRACE? Obviously we decide ourselves. 
> I don't have a good answer because right now we are in the process of 
> eliminating the distinction we used to make which is that DEBUG is safe to 
> turn on in production and TRACE is not.
> 
> Ariel
> 
>> On Tue, Mar 20, 2018, at 12:36 PM, Alexander Dejanovski wrote:
>> Ariel,
>> 
>> the current plan that's discussed on the ticket (
>> https://issues.apache.org/jira/browse/CASSANDRA-14326) is to maintain the
>> separation and keep the debug.log for "real" DEBUG level logging, which
>> would be disabled by default.
>> A new intermediate marker would be created to have VERBOSE_INFO logging
>> (some current debug loggings must be changed to that new level/marker),
>> which would be enabled by default, and "standard" INFO logging would go to
>> system.log.
>> 
>> I guess in that configuration, some/most TRACE level loggings would then be
>> eligible to graduate to DEBUG...?
>> 
>> 
>> 
>> 
>>> On Tue, Mar 20, 2018 at 4:19 PM Ariel Weisberg  wrote:
>>> 
>>> Hi,
>>> 
>>> Signal to noise ratio matters for logs. Things that we log at DEBUG aren't
>>> at all bound by constraints of human readability or being particularly
>>> relevant most of the time. I don't want to see most of this stuff unless I
>>> have already not found what I am looking for at INFO and above.
>>> 
>>> Can we at least maintain the separation of what is effectively debug
>>> logging (switching to an annotation aside) from INFO and above? I want to
>>> avoid two steps forward one step back.
>>> 
>>> Ariel
 On Tue, Mar 20, 2018, at 9:23 AM, Paulo Motta wrote:
 That sounds like a good plan, Alexander! Thanks!
 
 Stefan, someone needs to go through all messages being logged at DEBUG
 and reclassify important ones as INFO. I suggest continuing discussion
 on specifics on CASSANDRA-14326.
 
 2018-03-20 6:46 GMT-03:00 Stefan Podkowinski :
> Are you suggesting to move all messages currently logged via debug() to
> info() with the additional marker set, or only particular messages?
> 
> 
>> On 19.03.2018 19: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.  Ra

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

[Jason Brown]

copied directly from dev channel, just to keep with this ML conversation

08:08:26   Robert Stupp jasobrown:
https://www.azul.com/java-stable-secure-free-choose-two-three/ and
https://blogs.oracle.com/java-platform-group/faster-and-easier-use-and-redistribution-of-java-se
08:08:38 the 2nd says: "The Oracle JDK will continue as a commercial long
term support offering"
08:08:46 also: http://www.oracle.com/technetwork/java/eol-135779.html
08:09:21 the keyword in that cite is "commercial"
08:21:21  Michael Shuler a couple more thoughts.. 1) keep C* support
in step with latest Ubuntu LTS OpenJDK major in main, 2) bundle JRE in C*
releases? (JDK is not "legal" to bundle)
08:23:44 
https://www.elastic.co/blog/elasticsearch-java-9-and-beyond  - interesting
read on that matter
08:26:04 can't wait for the infra and CI testing implications.. will be
lot's of fun ;(
08:42:13  Robert Stupp Not sure whether stepping with Ubuntu is
necessary. It's not so difficult to update apt.source ;)
08:42:43 CI ? It just let's your test matrix explode - a litte ;)
08:46:48  Michael Shuler yep, we currently `def jdkLabel = 'JDK 1.8
(latest)'` in job DSL and could easily modify that

On Tue, Mar 20, 2018 at 9:08 AM, Kant Kodali  wrote:

> Java 10 is releasing today!
>
> On Tue, Mar 20, 2018 at 9:07 AM, Ariel Weisberg  wrote:
>
> > Hi,
> >
> > +1 to what Jordan is saying.
> >
> > It seems like if we are cutting a release off of trunk we want to make
> > sure we get N years of supported JDK out of it. For a single LTS release
> N
> > could be at most 3 and historically that isn't long enough and it's very
> > likely we will get < 3 after a release is cut.
> >
> > Going beyond 3 years could be tricky in the worst case because bringing
> in
> > up to 3 years of JDK changes to an older release might mean some of our
> > dependencies no longer function and now it's not just minor fixes it's
> > bringing in who knows what in terms of updated dependencies.
> >
> > I think in some cases we are going to need to take a release we have
> > already cut and make it work with an LTS release that didn't exist when
> the
> > release was cut.
> >
> > We also need to update how CI works. We should at least build and run a
> > quick smoke test with the JDKs we are claiming to support and
> > asynchronously run all the tests on the rather large matrix that now
> exists.
> >
> > Ariel
> >
> > On Tue, Mar 20, 2018, at 11:07 AM, Jeremiah Jordan wrote:
> > > My suggestion would be to keep trunk on the latest LTS by default, but
> > > with compatibility with the latest release if possible.  Since Oracle
> > > LTS releases are every 3 years, I would not want to tie us to that
> > > release cycle?
> > > So until Java 11 is out that would mean trunk should work under Java 8,
> > > with the option of being compiled/run under Java 9 or 10.  Once Java 11
> > > is out we could then switch to 11 only.
> > >
> > > -Jeremiah
> > >
> > > On Mar 20, 2018, at 10:48 AM, Jason Brown 
> wrote:
> > >
> > > >>> Wouldn't that potentially leave us in a situation where we're ready
> > for
> > > > a C* release but blocked waiting on a new LTS cut?
> > > >
> > > > Agreed, and perhaps if we're close enough to a LTS release (say three
> > > > months or less), we could choose to delay (probably with community
> > > > input/vote). If we're a year or two out, then, no, we should not
> wait.
> > I
> > > > think this is what I meant to communicate by "Perhaps we can evaluate
> > this
> > > > over time." (poorly stated, in hindsight)
> > > >
> > > >> On Tue, Mar 20, 2018 at 7:22 AM, Josh McKenzie <
> jmcken...@apache.org>
> > wrote:
> > > >>
> > > >> Need a little clarification on something:
> > > >>
> > > >>> 2) always release cassandra on a LTS version
> > > >> combined with:
> > > >>> 3) keep trunk on the lasest jdk version, assumming we release a
> major
> > > >>> cassandra version close enough to a LTS release.
> > > >>
> > > >> Wouldn't that potentially leave us in a situation where we're ready
> > > >> for a C* release but blocked waiting on a new LTS cut? For example,
> if
> > > >> JDK 9 were the currently supported LTS and trunk was on JDK 11, we'd
> > > >> either have to get trunk to work with 9 or wait for 11 to resolve
> > > >> that.
> > > >>
> > > >>> On Tue, Mar 20, 2018 at 9:32 AM, Jason Brown  >
> > wrote:
> > > >>> Hi all,
> > > >>>
> > > >>>
> > > >>> TL;DR Oracle has started revving the JDK version much faster, and
> we
> > need
> > > >>> an agreed upon plan.
> > > >>>
> > > >>> Well, we probably should has this discussion this already by now,
> but
> > > >> here
> > > >>> we are. Oracle announced plans to release updated JDK version every
> > six
> > > >>> months, and each new version immediate supercedes the previous in
> all
> > > >> ways:
> > > >>> no updates/security fixes to previous versions is the main thing,
> and
> > > >>> previous versions are EOL'd immediately. In addition, Oracle has
> > planned
> > > >>> parallel LTS versions that will live for three years, 

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

[Jason Brown]

Thanks to Hannu and others pointing out that the OracleJDK is a
*commercial* LTS, and thus not an option. mea culpa for missing the
"commercial" and just focusing on the "LTS" bit. OpenJDK is is, then.

Stefan's elastic search link is rather interesting. Looks like they are
compiling for both a LTS version as well as the current OpenJDK. They
assume some of their users will stick to a LTS version and some will run
the current version of OpenJDK.

While it's extra work to add JDK version as yet another matrix variable in
addition to our branching, is that something we should consider? Or are we
going to burden maintainers even more? Do we have a choice? Note: I think
this is similar to what Jeremiah is proposed.

@Ariel: Going beyond 3 years could be tricky in the worst case because
bringing in up to 3 years of JDK changes to an older release might mean
some of our dependencies no longer function and now it's not just minor
fixes it's bringing in who knows what in terms of updated dependencies

I'm not sure we have a choice anymore, as we're basically bound to what the
JDK developers choose to do (and we're bound to the JDK ...). However, if
we have the changes necessary for the JDK releases higher than the LTS (if
we following the elastic search model), perhaps it'll be a reasonably
smooth transition?

On Tue, Mar 20, 2018 at 1:31 PM, Jason Brown  wrote:

> copied directly from dev channel, just to keep with this ML conversation
>
> 08:08:26   Robert Stupp jasobrown: https://www.azul.com/java-
> stable-secure-free-choose-two-three/ and https://blogs.oracle.com/java-
> platform-group/faster-and-easier-use-and-redistribution-of-java-se
> 08:08:38 the 2nd says: "The Oracle JDK will continue as a commercial long
> term support offering"
> 08:08:46 also: http://www.oracle.com/technetwork/java/eol-135779.html
> 08:09:21 the keyword in that cite is "commercial"
> 08:21:21  Michael Shuler a couple more thoughts.. 1) keep C*
> support in step with latest Ubuntu LTS OpenJDK major in main, 2) bundle JRE
> in C* releases? (JDK is not "legal" to bundle)
> 08:23:44  https://www.elastic.co/blog/elasticsearch-
> java-9-and-beyond  - interesting read on that matter
> 08:26:04 can't wait for the infra and CI testing implications.. will be
> lot's of fun ;(
> 08:42:13  Robert Stupp Not sure whether stepping with Ubuntu is
> necessary. It's not so difficult to update apt.source ;)
> 08:42:43 CI ? It just let's your test matrix explode - a litte ;)
> 08:46:48  Michael Shuler yep, we currently `def jdkLabel = 'JDK 1.8
> (latest)'` in job DSL and could easily modify that
>
> On Tue, Mar 20, 2018 at 9:08 AM, Kant Kodali  wrote:
>
>> Java 10 is releasing today!
>>
>> On Tue, Mar 20, 2018 at 9:07 AM, Ariel Weisberg 
>> wrote:
>>
>> > Hi,
>> >
>> > +1 to what Jordan is saying.
>> >
>> > It seems like if we are cutting a release off of trunk we want to make
>> > sure we get N years of supported JDK out of it. For a single LTS
>> release N
>> > could be at most 3 and historically that isn't long enough and it's very
>> > likely we will get < 3 after a release is cut.
>> >
>> > Going beyond 3 years could be tricky in the worst case because bringing
>> in
>> > up to 3 years of JDK changes to an older release might mean some of our
>> > dependencies no longer function and now it's not just minor fixes it's
>> > bringing in who knows what in terms of updated dependencies.
>> >
>> > I think in some cases we are going to need to take a release we have
>> > already cut and make it work with an LTS release that didn't exist when
>> the
>> > release was cut.
>> >
>> > We also need to update how CI works. We should at least build and run a
>> > quick smoke test with the JDKs we are claiming to support and
>> > asynchronously run all the tests on the rather large matrix that now
>> exists.
>> >
>> > Ariel
>> >
>> > On Tue, Mar 20, 2018, at 11:07 AM, Jeremiah Jordan wrote:
>> > > My suggestion would be to keep trunk on the latest LTS by default, but
>> > > with compatibility with the latest release if possible.  Since Oracle
>> > > LTS releases are every 3 years, I would not want to tie us to that
>> > > release cycle?
>> > > So until Java 11 is out that would mean trunk should work under Java
>> 8,
>> > > with the option of being compiled/run under Java 9 or 10.  Once Java
>> 11
>> > > is out we could then switch to 11 only.
>> > >
>> > > -Jeremiah
>> > >
>> > > On Mar 20, 2018, at 10:48 AM, Jason Brown 
>> wrote:
>> > >
>> > > >>> Wouldn't that potentially leave us in a situation where we're
>> ready
>> > for
>> > > > a C* release but blocked waiting on a new LTS cut?
>> > > >
>> > > > Agreed, and perhaps if we're close enough to a LTS release (say
>> three
>> > > > months or less), we could choose to delay (probably with community
>> > > > input/vote). If we're a year or two out, then, no, we should not
>> wait.
>> > I
>> > > > think this is what I meant to communicate by "Perhaps we can
>> evaluate
>> > this
>> > > > over time." (poorly state

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

[Jeremiah D Jordan]

> Stefan's elastic search link is rather interesting. Looks like they are
> compiling for both a LTS version as well as the current OpenJDK. They
> assume some of their users will stick to a LTS version and some will run
> the current version of OpenJDK.
> 
> While it's extra work to add JDK version as yet another matrix variable in
> addition to our branching, is that something we should consider? Or are we
> going to burden maintainers even more? Do we have a choice? Note: I think
> this is similar to what Jeremiah is proposed.

Yes, this is basically what I was proposing for trunk.


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

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

[Carl Mueller]

So this is basically Oracle imposing a rapid upgrade path on free users to
force them to buy commercial to get LTS stability?

This will probably shake out in the community somehow. Cassandra is complex
but we are small fry in the land of IT supports and Enterprise upgrades.
Something will organize around OpenJDK I'd guess. There's probably a
collective tens or hundreds of billions of dollars in IT budgets affected
by this, so something will shake out.

So many other projects are impacted by this. What is the official/consensus
Apache Software Foundation strategy on this?

On Tue, Mar 20, 2018 at 3:50 PM, Jason Brown  wrote:

> Thanks to Hannu and others pointing out that the OracleJDK is a
> *commercial* LTS, and thus not an option. mea culpa for missing the
> "commercial" and just focusing on the "LTS" bit. OpenJDK is is, then.
>
> Stefan's elastic search link is rather interesting. Looks like they are
> compiling for both a LTS version as well as the current OpenJDK. They
> assume some of their users will stick to a LTS version and some will run
> the current version of OpenJDK.
>
> While it's extra work to add JDK version as yet another matrix variable in
> addition to our branching, is that something we should consider? Or are we
> going to burden maintainers even more? Do we have a choice? Note: I think
> this is similar to what Jeremiah is proposed.
>
> @Ariel: Going beyond 3 years could be tricky in the worst case because
> bringing in up to 3 years of JDK changes to an older release might mean
> some of our dependencies no longer function and now it's not just minor
> fixes it's bringing in who knows what in terms of updated dependencies
>
> I'm not sure we have a choice anymore, as we're basically bound to what the
> JDK developers choose to do (and we're bound to the JDK ...). However, if
> we have the changes necessary for the JDK releases higher than the LTS (if
> we following the elastic search model), perhaps it'll be a reasonably
> smooth transition?
>
> On Tue, Mar 20, 2018 at 1:31 PM, Jason Brown  wrote:
>
> > copied directly from dev channel, just to keep with this ML conversation
> >
> > 08:08:26   Robert Stupp jasobrown: https://www.azul.com/java-
> > stable-secure-free-choose-two-three/ and https://blogs.oracle.com/java-
> > platform-group/faster-and-easier-use-and-redistribution-of-java-se
> > 08:08:38 the 2nd says: "The Oracle JDK will continue as a commercial long
> > term support offering"
> > 08:08:46 also: http://www.oracle.com/technetwork/java/eol-135779.html
> > 08:09:21 the keyword in that cite is "commercial"
> > 08:21:21  Michael Shuler a couple more thoughts.. 1) keep C*
> > support in step with latest Ubuntu LTS OpenJDK major in main, 2) bundle
> JRE
> > in C* releases? (JDK is not "legal" to bundle)
> > 08:23:44  https://www.elastic.co/blog/elasticsearch-
> > java-9-and-beyond  - interesting read on that matter
> > 08:26:04 can't wait for the infra and CI testing implications.. will be
> > lot's of fun ;(
> > 08:42:13  Robert Stupp Not sure whether stepping with Ubuntu is
> > necessary. It's not so difficult to update apt.source ;)
> > 08:42:43 CI ? It just let's your test matrix explode - a litte ;)
> > 08:46:48  Michael Shuler yep, we currently `def jdkLabel = 'JDK 1.8
> > (latest)'` in job DSL and could easily modify that
> >
> > On Tue, Mar 20, 2018 at 9:08 AM, Kant Kodali  wrote:
> >
> >> Java 10 is releasing today!
> >>
> >> On Tue, Mar 20, 2018 at 9:07 AM, Ariel Weisberg 
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > +1 to what Jordan is saying.
> >> >
> >> > It seems like if we are cutting a release off of trunk we want to make
> >> > sure we get N years of supported JDK out of it. For a single LTS
> >> release N
> >> > could be at most 3 and historically that isn't long enough and it's
> very
> >> > likely we will get < 3 after a release is cut.
> >> >
> >> > Going beyond 3 years could be tricky in the worst case because
> bringing
> >> in
> >> > up to 3 years of JDK changes to an older release might mean some of
> our
> >> > dependencies no longer function and now it's not just minor fixes it's
> >> > bringing in who knows what in terms of updated dependencies.
> >> >
> >> > I think in some cases we are going to need to take a release we have
> >> > already cut and make it work with an LTS release that didn't exist
> when
> >> the
> >> > release was cut.
> >> >
> >> > We also need to update how CI works. We should at least build and run
> a
> >> > quick smoke test with the JDKs we are claiming to support and
> >> > asynchronously run all the tests on the rather large matrix that now
> >> exists.
> >> >
> >> > Ariel
> >> >
> >> > On Tue, Mar 20, 2018, at 11:07 AM, Jeremiah Jordan wrote:
> >> > > My suggestion would be to keep trunk on the latest LTS by default,
> but
> >> > > with compatibility with the latest release if possible.  Since
> Oracle
> >> > > LTS releases are every 3 years, I would not want to tie us to that
> >> > > release cycle?
> >> > > So until Jav

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

[Ariel Weisberg]

Hi,

Synchronizing with Oracle LTS releases is kind of low value if it's a paid 
offering. But if someone in the community doesn't want to upgrade and pays 
Oracle we don't want to get in the way of that.

Which is how you end up with what Jordan and ElasticSearch suggest. I'm still 
+1 on that although in my heart of hearts I want  to only support the latest 
OpenJDK on trunk and after we cut a release only change the JDK if there is a 
serious issue.

It's going to be annoying once we have a serious security or correctness issue 
and we need to move to a later OpenJDK. The majority won't be paying Oracle for 
LTS. I don't think that will happen that often though.

Regards,
Ariel

If that ends up not working and we find it's a problem to not be getting 
On Tue, Mar 20, 2018, at 4:50 PM, Jason Brown wrote:
> Thanks to Hannu and others pointing out that the OracleJDK is a
> *commercial* LTS, and thus not an option. mea culpa for missing the
> "commercial" and just focusing on the "LTS" bit. OpenJDK is is, then.
> 
> Stefan's elastic search link is rather interesting. Looks like they are
> compiling for both a LTS version as well as the current OpenJDK. They
> assume some of their users will stick to a LTS version and some will run
> the current version of OpenJDK.
> 
> While it's extra work to add JDK version as yet another matrix variable in
> addition to our branching, is that something we should consider? Or are we
> going to burden maintainers even more? Do we have a choice? Note: I think
> this is similar to what Jeremiah is proposed.
> 
> @Ariel: Going beyond 3 years could be tricky in the worst case because
> bringing in up to 3 years of JDK changes to an older release might mean
> some of our dependencies no longer function and now it's not just minor
> fixes it's bringing in who knows what in terms of updated dependencies
> 
> I'm not sure we have a choice anymore, as we're basically bound to what the
> JDK developers choose to do (and we're bound to the JDK ...). However, if
> we have the changes necessary for the JDK releases higher than the LTS (if
> we following the elastic search model), perhaps it'll be a reasonably
> smooth transition?
> 
> On Tue, Mar 20, 2018 at 1:31 PM, Jason Brown  wrote:
> 
> > copied directly from dev channel, just to keep with this ML conversation
> >
> > 08:08:26   Robert Stupp jasobrown: https://www.azul.com/java-
> > stable-secure-free-choose-two-three/ and https://blogs.oracle.com/java-
> > platform-group/faster-and-easier-use-and-redistribution-of-java-se
> > 08:08:38 the 2nd says: "The Oracle JDK will continue as a commercial long
> > term support offering"
> > 08:08:46 also: http://www.oracle.com/technetwork/java/eol-135779.html
> > 08:09:21 the keyword in that cite is "commercial"
> > 08:21:21  Michael Shuler a couple more thoughts.. 1) keep C*
> > support in step with latest Ubuntu LTS OpenJDK major in main, 2) bundle JRE
> > in C* releases? (JDK is not "legal" to bundle)
> > 08:23:44  https://www.elastic.co/blog/elasticsearch-
> > java-9-and-beyond  - interesting read on that matter
> > 08:26:04 can't wait for the infra and CI testing implications.. will be
> > lot's of fun ;(
> > 08:42:13  Robert Stupp Not sure whether stepping with Ubuntu is
> > necessary. It's not so difficult to update apt.source ;)
> > 08:42:43 CI ? It just let's your test matrix explode - a litte ;)
> > 08:46:48  Michael Shuler yep, we currently `def jdkLabel = 'JDK 1.8
> > (latest)'` in job DSL and could easily modify that
> >
> > On Tue, Mar 20, 2018 at 9:08 AM, Kant Kodali  wrote:
> >
> >> Java 10 is releasing today!
> >>
> >> On Tue, Mar 20, 2018 at 9:07 AM, Ariel Weisberg 
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > +1 to what Jordan is saying.
> >> >
> >> > It seems like if we are cutting a release off of trunk we want to make
> >> > sure we get N years of supported JDK out of it. For a single LTS
> >> release N
> >> > could be at most 3 and historically that isn't long enough and it's very
> >> > likely we will get < 3 after a release is cut.
> >> >
> >> > Going beyond 3 years could be tricky in the worst case because bringing
> >> in
> >> > up to 3 years of JDK changes to an older release might mean some of our
> >> > dependencies no longer function and now it's not just minor fixes it's
> >> > bringing in who knows what in terms of updated dependencies.
> >> >
> >> > I think in some cases we are going to need to take a release we have
> >> > already cut and make it work with an LTS release that didn't exist when
> >> the
> >> > release was cut.
> >> >
> >> > We also need to update how CI works. We should at least build and run a
> >> > quick smoke test with the JDKs we are claiming to support and
> >> > asynchronously run all the tests on the rather large matrix that now
> >> exists.
> >> >
> >> > Ariel
> >> >
> >> > On Tue, Mar 20, 2018, at 11:07 AM, Jeremiah Jordan wrote:
> >> > > My suggestion would be to keep trunk on the latest LTS by default, but
> >> > > with compatibilit

Paying off tech debt and correctly naming things

[Jon Haddad]

Whenever I hop around in the codebase, one thing that always manages to slow me 
down is needing to understand the context of the variable names that I’m 
looking at.  We’ve now removed thrift the transport, but the variables, classes 
and comments still remain.  Personally, I’d like to go in and pay off as much 
technical debt as possible by refactoring the code to be as close to CQL as 
possible.  Rows should be rows, not partitions, I’d love to see the term column 
family removed forever in favor of always using tables.  That said, it’s a big 
task.  I did a quick refactor in a branch, simply changing the 
ColumnFamilyStore class to TableStore, and pushed it up to GitHub. [1]

Didn’t click on the link?  That’s ok.  The TL;DR is that it’s almost 2K LOC 
changed across 275 files.  I’ll note that my branch doesn’t change any of the 
almost 1000 search results of “columnfamilystore” found in the codebase and 
hundreds of tests failed on my branch in CircleCI, so that 2K LOC change would 
probably be quite a bit bigger.  There is, of course, a lot more than just 
renaming this one class, there’s thousands of variable names using any manner 
of “cf”, “cfs”, “columnfamily”, names plus comments and who knows what else.  
There’s lots of references in probably every file that would have to get 
updated.

What are people’s thoughts on this?  We should be honest with ourselves and 
know this isn’t going to get any easier over time.  It’s only going to get more 
confusing for new people to the project, and having to figure out “what kind of 
row am i even looking at” is a waste of time.  There’s obviously a much bigger 
impact than just renaming a bunch of files, there’s any number of patches and 
branches that would become outdated, plus anyone pulling in Cassandra as a 
dependency would be affected.  I don’t really have a solution for the 
disruption other than “leave it in place”, but in my mind that’s not a great 
(or even good) solution.

Anyways, enough out of me.  My concern for ergonomics and naming might be 
significantly higher than the rest of the folks working in the code, and I 
wanted to put a feeler out there before I decided to dig into this in a more 
serious manner. 

Jon

[1] 
https://github.com/apache/cassandra/compare/trunk...rustyrazorblade:refactor_column_family_store?expand=1
 

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

[Gerald Henriksen]

On Tue, 20 Mar 2018 16:26:30 -0500, you wrote:

>So this is basically Oracle imposing a rapid upgrade path on free users to
>force them to buy commercial to get LTS stability?
>
>This will probably shake out in the community somehow. Cassandra is complex
>but we are small fry in the land of IT supports and Enterprise upgrades.
>Something will organize around OpenJDK I'd guess. There's probably a

Don't forget that the commercial Linux distributions support what they
ship.

So for example if you purchase Red Hat Enterprise Linux they current
will provide support for Java 8 until October 2020(*).

I assume Ubuntu does something similar.

The only ones likely to be hurt by Oracle's actions are anyone who is
running anything Java based on either Windows or MacOS.

*https://access.redhat.com/articles/1299013

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