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 supp
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 p
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 alt
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
> 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 versio
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
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: "Th
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 differenc
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 elimin
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
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 l
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 matt
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 w
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 a
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
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, wi
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 g
>> 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
v
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 wi
>> 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
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
fo
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 superce
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 mo
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
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 i
25 matches
Mail list logo
