Re: [VOTE] CEP-8 Datastax Drivers Donation

[Jorge Bay Gondra]

+1 nb

On Wed, Jun 14, 2023 at 9:13 AM Sam Tunnicliffe  wrote:

> +1
>
> On 13 Jun 2023, at 15:14, Jeremy Hanna  wrote:
>
> Calling for a vote on CEP-8 [1].
>
> To clarify the intent, as Benjamin said in the discussion thread [2], the
> goal of this vote is simply to ensure that the community is in favor of
> the donation. Nothing more.
> The plan is to introduce the drivers, one by one. Each driver donation
> will need to be accepted first by the PMC members, as it is the case for
> any donation. Therefore the PMC should have full control on the pace at
> which new drivers are accepted.
>
> If this vote passes, we can start this process for the Java driver under
> the direction of the PMC.
>
> Jeremy
>
> 1.
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+Datastax+Drivers+Donation
> 2. https://lists.apache.org/thread/opt630do09phh7hlt28odztxdv6g58dp
>
>
>

Re: [VOTE] Release Apache Cassandra 4.0-beta3

[Jorge Bay Gondra]

Driver smoke tests look good:
https://ci.appveyor.com/project/DataStax/cassandra-drivers-smoke-test/builds/36049940

+1 (non-binding)

On Thu, Oct 29, 2020 at 1:29 PM Mick Semb Wever  wrote:

> Proposing the test build of Cassandra 4.0-beta3 for release.
>
> sha1: be716b46f2cb3b2d1f01dc225396c6284d5a35de
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta3-tentative
> Maven Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1224/org/apache/cassandra/cassandra-all/4.0-beta3/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.0-beta3/
>
> The vote will be open for 72 hours (longer if needed). Everyone who
> has tested the build is invited to vote. Votes by PMC members are
> considered binding. A vote passes if there are at least three binding
> +1s and no -1's.
>
> [1]: CHANGES.txt:
>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-beta3-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-beta3-tentative
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Project governance wiki doc

[Jorge Bay Gondra]

+1 nb

On Wed, Jun 17, 2020 at 7:41 AM Mick Semb Wever  wrote:

> +1 (binding)
>
> On Tue, 16 Jun 2020 at 18:19, Joshua McKenzie 
> wrote:
>
> > Added unratified draft to the wiki here:
> >
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> >
> > I propose the following:
> >
> >1. We leave the vote open for 1 week (close at end of day 6/23/20)
> >unless there's a lot of feedback on the wiki we didn't get on gdoc
> >2. pmc votes are considered binding
> >3. committer and community votes are considered advisory / non-binding
> >
> > Any objections / revisions to the above?
> >
> > Thanks!
> >
> > ~Josh
> >
>

Re: [VOTE] Release Apache Cassandra 4.0-alpha4

[Jorge Bay Gondra]

+1 (non-binding)

I've run the drivers smoke test suite and build jobs look good:
- Node.js Driver:
https://ci.appveyor.com/project/DataStax/cassandra-drivers-smoke-test/build/job/gwm95nu4w5017jix
- Java Driver:
https://ci.appveyor.com/project/DataStax/cassandra-drivers-smoke-test/build/job/rcf9epp9qvc5br1x
(test
failures not related to the server build)
- C++ Driver:
https://ci.appveyor.com/project/DataStax/cassandra-drivers-smoke-test/build/job/em594sokbi0lf2uu
- C# Driver:
https://ci.appveyor.com/project/DataStax/cassandra-drivers-smoke-test/build/job/rcf9epp9qvc5br1x
(test
failures not related to the server build)

On Sat, Apr 11, 2020 at 8:40 AM Yuji Ito  wrote:

> +1 (non-binding)
>
> It has passed brief Jepsen tests.
> https://github.com/scalar-labs/scalar-jepsen
>
> 2020年4月11日(土) 8:29 Mick Semb Wever :
>
> > Proposing the test build of Cassandra 4.0-alpha4 for release.
> >
> > sha1: d00c004cc10986fc41c2070f9c5d0007e03a45c3
> > Git:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-alpha4-tentative
> > Maven Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1202/org/apache/cassandra/cassandra-all/4.0-alpha4/
> >
> > The Source and Build Artifacts, and the Debian and RPM packages and
> > repositories, are available here:
> > https://dist.apache.org/repos/dist/dev/cassandra/4.0-alpha4/
> >
> > The vote will be open for at least 96 hours (longer than normal,
> > because of Easter holidays for many). Everyone who has tested the
> > build is invited to vote. Votes by PMC members are considered binding.
> > A vote passes if there are at least three binding +1s.
> >
> > [1]: CHANGES.txt:
> >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-alpha4-tentative
> > [2]: NEWS.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-alpha4-tentative
> >
> >
> > regards,
> > Mick
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: [DISCUSS] Client protocol changes (Was: 20200217 4.0 Status Update)

[Jorge Bay Gondra]

There were some discussions on Slack whether CASSANDRA-2848 should be in
scope for 4.0 or not, given that its an enhancement.

I'm +1 on descoping it and leave it for a later 4.x

As it involves a change in the protocol, we could use non-breaking changes
to add these types of features to protocol_v5 in 4.x without a protocol
version bump (new flag + new SUPPORTED option), like I've proposed above.

On Thu, Feb 20, 2020 at 2:52 PM Aleksey Yeshchenko
 wrote:

> For what it’s worth, we could trivially implement support for passing down
> the timeout in 4.0.0, so that both the server and the client are able to
> parse the frames with and without them, but delay implementation of the
> server side logic necessary for terminating requests early until a further
> minor (4.1/4.0.1).
>
> > On 19 Feb 2020, at 15:39, Jorge Bay Gondra 
> wrote:
> >
> > Also worth mentioning that, from the driver's perspective, it has to
> > support a protocol version during the lifetime of the C* version line.
> For
> > example, the drivers should drop support for protocol v3 after C* 2.1
> goes
> > EOL, somewhere this year, a protocol that was released back in 2014.
> >
> > We _could_ establish looser restrictions on whats a breaking change in a
> > protocol version (needing a version bump), that way the driver can
> support
> > a protocol version partially and a protocol version could evolve within
> > those limits.
> >
> > Back to the query timeout, a new query flag that can only be set by the
> > client is not a breaking change for the driver. The driver could ask
> > whether that feature of the protocol v5 is supported (OPTIONS/SUPPORTED
> > messages), without having to identify the server version.
> >
> > On Wed, Feb 19, 2020 at 12:24 AM Benedict Elliott Smith <
> bened...@apache.org>
> > wrote:
> >
> >> Behaviours don't have to be switched only with a new protocol version;
> >> it's possible to support optional feature/modifier flags, the support
> for
> >> which is negotiated with a client on connection.
> >>
> >> A protocol version change seems reasonable to limit to major releases,
> but
> >> a protocol feature seems perfectly reasonable to introduce in a minor, I
> >> think?  Ideally a version change would only be necessary for forced
> >> deprecation/standardisation of features, behaviour and stream encodings.
> >>
> >>
> >> On 18/02/2020, 21:53, "Jeff Jirsa"  wrote:
> >>
> >>A few notes:
> >>
> >>- Protocol changes add work to the rest of the ecosystem. Drivers
> have
> >> to
> >>update, etc.
> >>- Nobody expects protocol changes in minors, though it's less of a
> >> concern
> >>if we don't deprecate out the older version. E.g. if 4.0 launches
> with
> >>protocol v4 and protocol v5, and then 4.0.2 adds protocol v6, do we
> >>deprecate out v4? If yes, you potentially break clients that only
> >> supported
> >>v3 and v4 in a minor version upgrade, which is unexpected. If not,
> how
> >> many
> >>protocol versions are you willing to support at any given time?
> >>- Having protocol changes introduces risk. Paging behavior across
> >> protocol
> >>versions is the site of a number of different bugs recently.
> >>
> >>
> >>On Tue, Feb 18, 2020 at 1:46 PM Tolbert, Andrew  >
> >> wrote:
> >>
> >>> I don't know the technical answer, but I suspect two motivations for
> >>> doing new protocol versions in major releases could include:
> >>>
> >>> * protocol changes can be tied to feature changes that typically come
> >>> in a major release.
> >>> * protocol changes should be as infrequent as major releases.  Each
> >>> new protocol version is another thing in the test matrix that needs
> >> to
> >>> be tested.
> >>>
> >>> That last point can make it hard to get new changes in. If something
> >>> doesn't make the upcoming protocol version, it might be years before
> >>> another one, but I also think it's worth it to do this infrequently
> >> as
> >>> it makes maintaining client and server code easier if there are less
> >>> protocol versions to worry about.
> >>>
> >>> On the client-side, libraries themselves should be avoiding making
> >>> Cassandra version checks when detecting capabilities.  There are a
> >> few
> &

Smoke tests using the drivers

[Jorge Bay Gondra]

Hi,
We've setup a repository to launch smoke tests for Cassandra release
candidates using the drivers.

https://github.com/datastax/cassandra-drivers-smoke-test

It runs a subset of the integration test suite of Node.js, Java and C#
drivers (Python and C++ drivers should be added soon). It currently uses
AppVeyor
 for
Linux but we could easily switch CI service providers in the future if
needed. It uses environment variables to set the C* tarball url and version.


Thanks,
Jorge

Re: [DISCUSS] Client protocol changes (Was: 20200217 4.0 Status Update)

[Jorge Bay Gondra]

Also worth mentioning that, from the driver's perspective, it has to
support a protocol version during the lifetime of the C* version line. For
example, the drivers should drop support for protocol v3 after C* 2.1 goes
EOL, somewhere this year, a protocol that was released back in 2014.

We _could_ establish looser restrictions on whats a breaking change in a
protocol version (needing a version bump), that way the driver can support
a protocol version partially and a protocol version could evolve within
those limits.

Back to the query timeout, a new query flag that can only be set by the
client is not a breaking change for the driver. The driver could ask
whether that feature of the protocol v5 is supported (OPTIONS/SUPPORTED
messages), without having to identify the server version.

On Wed, Feb 19, 2020 at 12:24 AM Benedict Elliott Smith 
wrote:

> Behaviours don't have to be switched only with a new protocol version;
> it's possible to support optional feature/modifier flags, the support for
> which is negotiated with a client on connection.
>
> A protocol version change seems reasonable to limit to major releases, but
> a protocol feature seems perfectly reasonable to introduce in a minor, I
> think?  Ideally a version change would only be necessary for forced
> deprecation/standardisation of features, behaviour and stream encodings.
>
>
> On 18/02/2020, 21:53, "Jeff Jirsa"  wrote:
>
> A few notes:
>
> - Protocol changes add work to the rest of the ecosystem. Drivers have
> to
> update, etc.
> - Nobody expects protocol changes in minors, though it's less of a
> concern
> if we don't deprecate out the older version. E.g. if 4.0 launches with
> protocol v4 and protocol v5, and then 4.0.2 adds protocol v6, do we
> deprecate out v4? If yes, you potentially break clients that only
> supported
> v3 and v4 in a minor version upgrade, which is unexpected. If not, how
> many
> protocol versions are you willing to support at any given time?
> - Having protocol changes introduces risk. Paging behavior across
> protocol
> versions is the site of a number of different bugs recently.
>
>
> On Tue, Feb 18, 2020 at 1:46 PM Tolbert, Andrew 
> wrote:
>
> > I don't know the technical answer, but I suspect two motivations for
> > doing new protocol versions in major releases could include:
> >
> > * protocol changes can be tied to feature changes that typically come
> > in a major release.
> > * protocol changes should be as infrequent as major releases.  Each
> > new protocol version is another thing in the test matrix that needs
> to
> > be tested.
> >
> > That last point can make it hard to get new changes in. If something
> > doesn't make the upcoming protocol version, it might be years before
> > another one, but I also think it's worth it to do this infrequently
> as
> > it makes maintaining client and server code easier if there are less
> > protocol versions to worry about.
> >
> > On the client-side, libraries themselves should be avoiding making
> > Cassandra version checks when detecting capabilities.  There are a
> few
> > exceptions, such as system table parsing for schema & peers,
> > but those aren't related to the protocol.
> >
> > Thanks,
> > Andy
> >
> >
> >
> >
> >
> > On Tue, Feb 18, 2020 at 1:22 PM Nate McCall 
> wrote:
> > >
> > > [Moving to new message thread]
> > >
> > > Thanks for bringing this up, Jordan.
> > >
> > > IIRC, this was more a convention than a technical reason. Though I
> could
> > be
> > > completely misremembering this.
> > >
> > > -- Forwarded message -
> > > From: Jordan West 
> > > Date: Wed, Feb 19, 2020 at 10:13 AM
> > > Subject: Re: 20200217 4.0 Status Update
> > > To: 
> > >
> > >
> > > On Mon, Feb 17, 2020 at 12:52 PM Jeff Jirsa 
> wrote:
> > >
> > > >
> > > > beyond the client proto change being painful for anything other
> than
> > major
> > > > releases
> > > >
> > > >
> > > This came up during the community meeting today and I wanted to
> bring a
> > > question about it to the list: could someone who is *very*
> familiar with
> > > the client proto share w/ the list why changing the proto in
> anything
> > other
> > > than a major release is so difficult? I hear this a lot and it
> seems to
> > be
> > > fact. So that all of us don't have to go read the code, a brief
> summary
> > > would be super helpful. Or if there is a ticket that already
> covers this
> > > even better! I'd also be curious if there have ever been any
> thoughts to
> > > address it as it seems to be a consistent hurdle during the
> release cycle
> > > and one that tends to further increase scope.
> > >
> > > Thanks,
> > > Jordan
> > >
> > > >
> > > >
> > > > > O

Re: [VOTE] Release Apache Cassandra 3.11.6

[Jorge Bay Gondra]

> Do you have a link to the results?

No, I haven't used a public env. I hope I can have something setup on a
public environment (travis/appveyor) for future releases.

On Fri, Feb 14, 2020 at 11:39 AM Mick Semb Wever  wrote:

>
> > Proposing the test build of Cassandra 3.11.6 for release.
>
>
> This vote has passed after 3 days, with 3 binding votes and 4 non-binding
> votes.
>
> Thanks Jorge for running the node.js driver integration test suite. Do you
> have a link to the results?
>
> regards,
> Mick
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Release Apache Cassandra 3.11.6

[Jorge Bay Gondra]

I've run part of the node.js driver integration test suite against it,
looks good.

+1 (non-binding)

On Thu, Feb 13, 2020 at 1:18 PM Tommy Stendahl
 wrote:

> +1 NB
>
> On tis, 2020-02-11 at 09:38 +0100, Mick Semb Wever wrote:
>
> Proposing the test build of Cassandra 3.11.6 for release.
>
> sha1: cb779ab9a631c13a245926f55320392c4468c6f0
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.6-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1194/org/apache/cassandra/cassandra-all/3.11.6/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/3.11.6/
>
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s.
>
> Again note the release process is undergoing improvements to deal with
> sha256|512 checksums and to use the ASF dev dist staging location. Please
> be extra critical. The deb and rpm repositories are also now available to
> verify before the vote.
>
>
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.6-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.6-tentative
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org dev-unsubscr...@cassandra.apache.org>
> For additional commands, e-mail: dev-h...@cassandra.apache.org dev-h...@cassandra.apache.org>
>
>
>

Re: [External]Re: I/O threads busy error

[Jorge Bay Gondra]

Hi Vishal,
This might be an indication that you are sending several requests in
parallel without waiting for a response and you need to introduce
throttling in your application, as Dinesh mentioned.

This issue is related to the usage of the DataStax C++ driver, you should
consider starting a new mail thread on the driver mailing list:
https://groups.google.com/a/lists.datastax.com/forum/#!forum/cpp-driver-user

Regards,
Jorge

El mar., 20 nov. 2018 a las 13:42,  escribió:

> This issue is mainly being observed when the table whose data is being
> fetched contains a column which stores a very large text(12.5 KB). Could
> this be a possible reason? How can I solve the issue? Which settings do I
> have to change?
>
> -Original Message-
> From: dinesh.jo...@yahoo.com.INVALID [mailto:
> dinesh.jo...@yahoo.com.INVALID]
> Sent: Tuesday, November 20, 2018 3:15 PM
> To: dev@cassandra.apache.org
> Subject: [External]Re: I/O threads busy error
>
> You're probably hitting this -
> https://github.com/datastax/cpp-driver/blob/2.0/src/session.cpp#L740
> From my reading it feels you may want to throttle your queries or play
> around with the driver settings. Essentially it seems the number of queries
> you're issuing is greater than what the cluster can handle and therefore
> they're queuing up in the driver.
> Dinesh
>
> On Monday, November 19, 2018, 10:24:10 PM PST, vishal1.sha...@ril.com
>  wrote:
>
>  Dear all,
> I've got a 2 node Cassandra cluster(3.11.2). I'm using Datastax's c++
> driver(ver 2.7) in my application to fetch/add data from the cluster(RHEL
> 6.9). Sometimes I'm getting the error "All connections on all I/O threads
> are busy" in my application.  I'm unable to figure out why I am getting
> this error infrequently and not everytime.
>
> Has anyone faced such errors before? Please let me know any possible
> reasons behind the issue.
>
> Thanks and regards,
> Vishal Sharma
>
> P.S. I don't really know whether this is a Datastax driver's issue or
> Cassandra's issue that's why I'm posting this query here.
> "Confidentiality Warning: This message and any attachments are intended
> only for the use of the intended recipient(s).
> are confidential and may be privileged. If you are not the intended
> recipient. you are hereby notified that any
> review. re-transmission. conversion to hard copy. copying. circulation or
> other use of this message and any attachments is
> strictly prohibited. If you are not the intended recipient. please notify
> the sender immediately by return email.
> and delete this message and any attachments from your system.
>
> Virus Warning: Although the company has taken reasonable precautions to
> ensure no viruses are present in this email.
> The company cannot accept responsibility for any loss or damage arising
> from the use of this email or attachment."
>