Re: Introducing mockito-inline library among test dependencies

[Andrés de la Peña]

+1 for the same reasons.

On Wed, 11 Jan 2023 at 20:14, David Capwell  wrote:

> +1. We already use mockito.  Also that library is basically empty, its
> just defining configs for extensions (see
> https://github.com/mockito/mockito/tree/main/subprojects/inline/src/main/resources/mockito-extensions
> )
>
> On Jan 11, 2023, at 12:02 PM, Miklosovic, Stefan <
> stefan.mikloso...@netapp.com> wrote:
>
> Hi list,
>
> the test for (1) is using mockito-inline dependency for mocking static
> methods as mockito-core is not able to do that on its own. mockito-inline
> was not part of our test dependencies prior this work. I want to ask if we
> are all OK with being able to mock static methods from now on with the help
> of this library.
>
> Please tell me if we are mocking static methods already by some other (to
> me yet unknown) mean so we do not include this unnecessarily.
>
> G:A:V is org.mockito:mockito-inline:4.7.0
>
> (1) https://issues.apache.org/jira/browse/CASSANDRA-14361
>
> Thanks
>
>
>

Re: Introducing mockito-inline library among test dependencies

[Brandon Williams]

+1

Kind Regards,
Brandon

On Wed, Jan 11, 2023 at 2:02 PM Miklosovic, Stefan
 wrote:
>
> Hi list,
>
> the test for (1) is using mockito-inline dependency for mocking static 
> methods as mockito-core is not able to do that on its own. mockito-inline was 
> not part of our test dependencies prior this work. I want to ask if we are 
> all OK with being able to mock static methods from now on with the help of 
> this library.
>
> Please tell me if we are mocking static methods already by some other (to me 
> yet unknown) mean so we do not include this unnecessarily.
>
> G:A:V is org.mockito:mockito-inline:4.7.0
>
> (1) https://issues.apache.org/jira/browse/CASSANDRA-14361
>
> Thanks

Re: Introducing mockito-inline library among test dependencies

[Jacek Lewandowski]

Will it work with Java17?

czw., 12 sty 2023, 12:56 użytkownik Brandon Williams 
napisał:

> +1
>
> Kind Regards,
> Brandon
>
> On Wed, Jan 11, 2023 at 2:02 PM Miklosovic, Stefan
>  wrote:
> >
> > Hi list,
> >
> > the test for (1) is using mockito-inline dependency for mocking static
> methods as mockito-core is not able to do that on its own. mockito-inline
> was not part of our test dependencies prior this work. I want to ask if we
> are all OK with being able to mock static methods from now on with the help
> of this library.
> >
> > Please tell me if we are mocking static methods already by some other
> (to me yet unknown) mean so we do not include this unnecessarily.
> >
> > G:A:V is org.mockito:mockito-inline:4.7.0
> >
> > (1) https://issues.apache.org/jira/browse/CASSANDRA-14361
> >
> > Thanks
>

Re: Should we change 4.1 to G1 and offheap_objects ?

[Mick Semb Wever]

> Ok, wrt G1 default, this is won't go ahead for 4.1-rc1
>
> We can revisit it for 4.1.x
>
> We have a lot of voices here adamantly positive for it, and those of us that 
> have done the performance testing over the years know why. But being called 
> to prove it is totally valid, if you have data to any such tests please add 
> them to the ticket 18027


Revisiting. Are there any vetoes to making G1 the default (and
updating the G1 settings, see the patch on
https://issues.apache.org/jira/browse/CASSANDRA-18027 ) for 4.1.1 ?

IIUC , the summary of this thread till now was: there were no vetoes
to the change in trunk, but there were vetoes to 4.1.0 (because we
were inside the beta to GA window), and there was a desire to have
benchmarking data presented.

WRT benchmarking, we have a separate thread for performance testing in
the project.  The ticket admittedly does not do its due diligence on
data presentation and analysis of smaller heaps: a precedent we should
be creating; but instead relies upon experience from many. Are we ok
with this this time around, or shall the patch only be applied to
trunk (where we have no choice w/ jdk17 landing)?

Re: Introducing mockito-inline library among test dependencies

[Miklosovic, Stefan]

Hi Jacek,

that is very good question, I will try to get back to you with the answer.

Also, just before merging 14361, we noticed that we are also hitting some 
issues on mocking stuff in 
org.apache.cassandra.distributed.mock.nodetool.InternalNodeProbe which failed 
some other tests.

I remember that I wanted to mock static methods like two years ago and I hit 
the very same issue back then as I do now (1).

Please keep in mind that the error is not related to what I wanted to test for 
CASSANDRA-14361, it is rather the consequence of us including mockito-inline to 
mock static methods and as we included it into the build and run full CI, the 
completely unrelated tests started to fail because of that. This issue seems to 
be in Mockito from times of 3.x and they are still present in 4.7.0.

I was able to workaround this issue in Cassandra code. The path towards using 
static mocks is not so straightforward but should be possible with a little bit 
more love. (2)

(1) https://github.com/mockito/mockito/issues/2203
(2) https://issues.apache.org/jira/browse/CASSANDRA-18152


From: Jacek Lewandowski 
Sent: Thursday, January 12, 2023 13:21
To: dev@cassandra.apache.org
Subject: Re: Introducing mockito-inline library among test dependencies

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.



Will it work with Java17?

czw., 12 sty 2023, 12:56 użytkownik Brandon Williams 
mailto:dri...@gmail.com>> napisał:
+1

Kind Regards,
Brandon

On Wed, Jan 11, 2023 at 2:02 PM Miklosovic, Stefan
mailto:stefan.mikloso...@netapp.com>> wrote:
>
> Hi list,
>
> the test for (1) is using mockito-inline dependency for mocking static 
> methods as mockito-core is not able to do that on its own. mockito-inline was 
> not part of our test dependencies prior this work. I want to ask if we are 
> all OK with being able to mock static methods from now on with the help of 
> this library.
>
> Please tell me if we are mocking static methods already by some other (to me 
> yet unknown) mean so we do not include this unnecessarily.
>
> G:A:V is org.mockito:mockito-inline:4.7.0
>
> (1) https://issues.apache.org/jira/browse/CASSANDRA-14361
>
> Thanks

Re: Should we change 4.1 to G1 and offheap_objects ?

[Aleksey Yeshchenko]

Switching a major default in a minor release is way worse than doing it in a GA 
- less notice and visibility, many folks don’t even read minor version NEWS.txt 
before upgrading.

Trunk is fine by me though.

> On 12 Jan 2023, at 13:14, Mick Semb Wever  wrote:
> 
>> Ok, wrt G1 default, this is won't go ahead for 4.1-rc1
>> 
>> We can revisit it for 4.1.x
>> 
>> We have a lot of voices here adamantly positive for it, and those of us that 
>> have done the performance testing over the years know why. But being called 
>> to prove it is totally valid, if you have data to any such tests please add 
>> them to the ticket 18027
> 
> 
> Revisiting. Are there any vetoes to making G1 the default (and
> updating the G1 settings, see the patch on
> https://issues.apache.org/jira/browse/CASSANDRA-18027 ) for 4.1.1 ?
> 
> IIUC , the summary of this thread till now was: there were no vetoes
> to the change in trunk, but there were vetoes to 4.1.0 (because we
> were inside the beta to GA window), and there was a desire to have
> benchmarking data presented.
> 
> WRT benchmarking, we have a separate thread for performance testing in
> the project.  The ticket admittedly does not do its due diligence on
> data presentation and analysis of smaller heaps: a precedent we should
> be creating; but instead relies upon experience from many. Are we ok
> with this this time around, or shall the patch only be applied to
> trunk (where we have no choice w/ jdk17 landing)?

Re: Should we change 4.1 to G1 and offheap_objects ?

[Paulo Motta]

I tend to agree with Aleksey's sentiment. Why do we need to change the
default in a minor release if we already provide G1 options for users that
want to opt-in?

On Thu, Jan 12, 2023 at 9:46 AM Aleksey Yeshchenko 
wrote:

> Switching a major default in a minor release is way worse than doing it in
> a GA - less notice and visibility, many folks don’t even read minor version
> NEWS.txt before upgrading.
>
> Trunk is fine by me though.
>
> > On 12 Jan 2023, at 13:14, Mick Semb Wever  wrote:
> >
> >> Ok, wrt G1 default, this is won't go ahead for 4.1-rc1
> >>
> >> We can revisit it for 4.1.x
> >>
> >> We have a lot of voices here adamantly positive for it, and those of us
> that have done the performance testing over the years know why. But being
> called to prove it is totally valid, if you have data to any such tests
> please add them to the ticket 18027
> >
> >
> > Revisiting. Are there any vetoes to making G1 the default (and
> > updating the G1 settings, see the patch on
> > https://issues.apache.org/jira/browse/CASSANDRA-18027 ) for 4.1.1 ?
> >
> > IIUC , the summary of this thread till now was: there were no vetoes
> > to the change in trunk, but there were vetoes to 4.1.0 (because we
> > were inside the beta to GA window), and there was a desire to have
> > benchmarking data presented.
> >
> > WRT benchmarking, we have a separate thread for performance testing in
> > the project.  The ticket admittedly does not do its due diligence on
> > data presentation and analysis of smaller heaps: a precedent we should
> > be creating; but instead relies upon experience from many. Are we ok
> > with this this time around, or shall the patch only be applied to
> > trunk (where we have no choice w/ jdk17 landing)?
>
>

Add to slack workspace

[kamalesh palanisamy]

Hi,
I am new and looking to contribute to the Cassandra project. Can someone
send me an invite to the cassandra-dev channel? My email address is
kamalesh...@gmail.com .
Thanks,
Kamalesh P

Re: Add to slack workspace

[Brandon Williams]

You have been invited.

Kind Regards,
Brandon

On Thu, Jan 12, 2023 at 11:31 AM kamalesh palanisamy
 wrote:
>
> Hi,
> I am new and looking to contribute to the Cassandra project. Can someone send 
> me an invite to the cassandra-dev channel? My email address is 
> kamalesh...@gmail.com .
> Thanks,
> Kamalesh P

[DISCUSS] CEP-22: Drivers Donation Status

[Abe Ratnofsky]

What's the current status of CEP-22?

It looks like the CEP draft on Confluence [1] hasn't been updated since Aug 
2022 and mailing list search [2] shows no results, so it never made it to a 
vote.

--
Abe

[1]: 
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-22%3A+Datastax+Drivers+Donation
[2]: https://lists.apache.org/list?*@cassandra.apache.org:lte=240M:CEP-22

Re: [DISCUSS] CEP-22: Drivers Donation Status

[Jeremy Hanna]

At DataStax, we're trying to make sure we have everything in order from a CLA 
perspective before moving forward with the process.  The drivers have always 
been Apache-2.0 licensed but we just want to make sure everything is in order.  
We're really close on the Java driver to move forward.  Once that's done, my 
understanding is that it will go through the next phases of the process and I 
know Josh and others are looking further into how we want to organize 
committers for the drivers.  We're doing the work for all of the drivers but 
will start with Java and then Python because of project dependencies and to 
learn from that process for the others.

> On Jan 12, 2023, at 12:36 PM, Abe Ratnofsky  wrote:
> 
> What's the current status of CEP-22?
> 
> It looks like the CEP draft on Confluence [1] hasn't been updated since Aug 
> 2022 and mailing list search [2] shows no results, so it never made it to a 
> vote.
> 
> --
> Abe
> 
> [1]: 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-22%3A+Datastax+Drivers+Donation
> [2]: https://lists.apache.org/list?*@cassandra.apache.org:lte=240M:CEP-22
> 
> 

Re: Should we change 4.1 to G1 and offheap_objects ?

[Josh McKenzie]

Potential compromise: We change it in trunk, and we NEWS.txt in the minor about 
that change in trunk, why, and recommend users consider qualifying the same 
change on their 4.1 release.

In case it's not clear from me:
+1 to changing on trunk for 5.0 here
-1 to changing on minor release given how little (i.e. nonexistent) perf 
testing we have on the OSS project right now.

On Thu, Jan 12, 2023, at 11:47 AM, Paulo Motta wrote:
> I tend to agree with Aleksey's sentiment. Why do we need to change the 
> default in a minor release if we already provide G1 options for users that 
> want to opt-in?
> 
> On Thu, Jan 12, 2023 at 9:46 AM Aleksey Yeshchenko  wrote:
>> Switching a major default in a minor release is way worse than doing it in a 
>> GA - less notice and visibility, many folks don’t even read minor version 
>> NEWS.txt before upgrading.
>> 
>> Trunk is fine by me though.
>> 
>> > On 12 Jan 2023, at 13:14, Mick Semb Wever  wrote:
>> > 
>> >> Ok, wrt G1 default, this is won't go ahead for 4.1-rc1
>> >> 
>> >> We can revisit it for 4.1.x
>> >> 
>> >> We have a lot of voices here adamantly positive for it, and those of us 
>> >> that have done the performance testing over the years know why. But being 
>> >> called to prove it is totally valid, if you have data to any such tests 
>> >> please add them to the ticket 18027
>> > 
>> > 
>> > Revisiting. Are there any vetoes to making G1 the default (and
>> > updating the G1 settings, see the patch on
>> > https://issues.apache.org/jira/browse/CASSANDRA-18027 ) for 4.1.1 ?
>> > 
>> > IIUC , the summary of this thread till now was: there were no vetoes
>> > to the change in trunk, but there were vetoes to 4.1.0 (because we
>> > were inside the beta to GA window), and there was a desire to have
>> > benchmarking data presented.
>> > 
>> > WRT benchmarking, we have a separate thread for performance testing in
>> > the project.  The ticket admittedly does not do its due diligence on
>> > data presentation and analysis of smaller heaps: a precedent we should
>> > be creating; but instead relies upon experience from many. Are we ok
>> > with this this time around, or shall the patch only be applied to
>> > trunk (where we have no choice w/ jdk17 landing)?
>> 

Re: Should we change 4.1 to G1 and offheap_objects ?

[David Capwell]

I am cool with updating NEWS in 4.1.1 to recommend the change and change it in 
4.2/5.0

> On Jan 12, 2023, at 10:56 AM, Josh McKenzie  wrote:
> 
> Potential compromise: We change it in trunk, and we NEWS.txt in the minor 
> about that change in trunk, why, and recommend users consider qualifying the 
> same change on their 4.1 release.
> 
> In case it's not clear from me:
> +1 to changing on trunk for 5.0 here
> -1 to changing on minor release given how little (i.e. nonexistent) perf 
> testing we have on the OSS project right now.
> 
> On Thu, Jan 12, 2023, at 11:47 AM, Paulo Motta wrote:
>> I tend to agree with Aleksey's sentiment. Why do we need to change the 
>> default in a minor release if we already provide G1 options for users that 
>> want to opt-in?
>> 
>> On Thu, Jan 12, 2023 at 9:46 AM Aleksey Yeshchenko > > wrote:
>> Switching a major default in a minor release is way worse than doing it in a 
>> GA - less notice and visibility, many folks don’t even read minor version 
>> NEWS.txt before upgrading.
>> 
>> Trunk is fine by me though.
>> 
>> > On 12 Jan 2023, at 13:14, Mick Semb Wever > > > wrote:
>> > 
>> >> Ok, wrt G1 default, this is won't go ahead for 4.1-rc1
>> >> 
>> >> We can revisit it for 4.1.x
>> >> 
>> >> We have a lot of voices here adamantly positive for it, and those of us 
>> >> that have done the performance testing over the years know why. But being 
>> >> called to prove it is totally valid, if you have data to any such tests 
>> >> please add them to the ticket 18027
>> > 
>> > 
>> > Revisiting. Are there any vetoes to making G1 the default (and
>> > updating the G1 settings, see the patch on
>> > https://issues.apache.org/jira/browse/CASSANDRA-18027 
>> >  ) for 4.1.1 ?
>> > 
>> > IIUC , the summary of this thread till now was: there were no vetoes
>> > to the change in trunk, but there were vetoes to 4.1.0 (because we
>> > were inside the beta to GA window), and there was a desire to have
>> > benchmarking data presented.
>> > 
>> > WRT benchmarking, we have a separate thread for performance testing in
>> > the project.  The ticket admittedly does not do its due diligence on
>> > data presentation and analysis of smaller heaps: a precedent we should
>> > be creating; but instead relies upon experience from many. Are we ok
>> > with this this time around, or shall the patch only be applied to
>> > trunk (where we have no choice w/ jdk17 landing)?

Re: Should we change 4.1 to G1 and offheap_objects ?

[guo Maxwell]

same with David Capwell，+1 on updating NEWS in 4.1.x and really change in
4.x /5.0

David Capwell 于2023年1月13日 周五上午3:11写道：

> I am cool with updating NEWS in 4.1.1 to recommend the change and change
> it in 4.2/5.0
>
>
> On Jan 12, 2023, at 10:56 AM, Josh McKenzie  wrote:
>
> Potential compromise: We change it in trunk, and we NEWS.txt in the minor
> about that change in trunk, why, and recommend users consider qualifying
> the same change on their 4.1 release.
>
> In case it's not clear from me:
> +1 to changing on trunk for 5.0 here
> -1 to changing on minor release given how little (i.e. nonexistent) perf
> testing we have on the OSS project right now.
>
> On Thu, Jan 12, 2023, at 11:47 AM, Paulo Motta wrote:
>
> I tend to agree with Aleksey's sentiment. Why do we need to change the
> default in a minor release if we already provide G1 options for users that
> want to opt-in?
>
> On Thu, Jan 12, 2023 at 9:46 AM Aleksey Yeshchenko 
> wrote:
>
> Switching a major default in a minor release is way worse than doing it in
> a GA - less notice and visibility, many folks don’t even read minor version
> NEWS.txt before upgrading.
>
> Trunk is fine by me though.
>
> > On 12 Jan 2023, at 13:14, Mick Semb Wever  wrote:
> >
> >> Ok, wrt G1 default, this is won't go ahead for 4.1-rc1
> >>
> >> We can revisit it for 4.1.x
> >>
> >> We have a lot of voices here adamantly positive for it, and those of us
> that have done the performance testing over the years know why. But being
> called to prove it is totally valid, if you have data to any such tests
> please add them to the ticket 18027
> >
> >
> > Revisiting. Are there any vetoes to making G1 the default (and
> > updating the G1 settings, see the patch on
> > https://issues.apache.org/jira/browse/CASSANDRA-18027 ) for 4.1.1 ?
> >
> > IIUC , the summary of this thread till now was: there were no vetoes
> > to the change in trunk, but there were vetoes to 4.1.0 (because we
> > were inside the beta to GA window), and there was a desire to have
> > benchmarking data presented.
> >
> > WRT benchmarking, we have a separate thread for performance testing in
> > the project.  The ticket admittedly does not do its due diligence on
> > data presentation and analysis of smaller heaps: a precedent we should
> > be creating; but instead relies upon experience from many. Are we ok
> > with this this time around, or shall the patch only be applied to
> > trunk (where we have no choice w/ jdk17 landing)?
>
>
> --
you are the apple of my eye !

Re: Should we change 4.1 to G1 and offheap_objects ?

[Brad]

*+1* to changing to G1 on trunk for 5.0 and 4.1.1.  We have over a thousand
clusters and over 10K nodes running on J8 and 11 with G1GC and memory
management is excellent. Excellent. Two observations: first we
reverted MaxGCPauseMillis=200,
which is the JVM default. Cassandra's jvm{8,11}-server.options has 500
(commented out) for some reason. Second on some clusters with 'humongous
allocations' we've had to increase G1HeapRegionSize in a few cases on
clusters with very large partitions.

CMS was deprecated in Java 9, so I don't know why Cassandra would still use
it as the default.

JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector
https://openjdk.org/jeps/291


The change to off-heap memory sounds good, but maybe change on trunk (5.0)
not 4.1.

On Thu, Jan 12, 2023 at 8:16 AM Mick Semb Wever  wrote:

> > Ok, wrt G1 default, this is won't go ahead for 4.1-rc1
> >
> > We can revisit it for 4.1.x
> >
> > We have a lot of voices here adamantly positive for it, and those of us
> that have done the performance testing over the years know why. But being
> called to prove it is totally valid, if you have data to any such tests
> please add them to the ticket 18027
>
>
> Revisiting. Are there any vetoes to making G1 the default (and
> updating the G1 settings, see the patch on
> https://issues.apache.org/jira/browse/CASSANDRA-18027 ) for 4.1.1 ?
>
> IIUC , the summary of this thread till now was: there were no vetoes
> to the change in trunk, but there were vetoes to 4.1.0 (because we
> were inside the beta to GA window), and there was a desire to have
> benchmarking data presented.
>
> WRT benchmarking, we have a separate thread for performance testing in
> the project.  The ticket admittedly does not do its due diligence on
> data presentation and analysis of smaller heaps: a precedent we should
> be creating; but instead relies upon experience from many. Are we ok
> with this this time around, or shall the patch only be applied to
> trunk (where we have no choice w/ jdk17 landing)?
>