Re: Request to review feature-freeze proposed tickets

[Jonathan Haddad]

If nobody has any objections to CASSANDRA-14303 (default RF) being merged
in I can take care of it.  It's a significant usability improvement, looks
well tested and will prevent a number of headaches.

I'll try to get to it tomorrow.

Thanks for bringing these up, Vinay.

Jon

On Tue, Nov 20, 2018 at 5:59 PM kurt greaves  wrote:

> Thanks Vinay. While I suspect this will be subject to heated debate, I'm
> also for this. The time to review for this project is incredibly
> demotivating, and it stems from a lack of contributors that are interested
> in the general health of the project. I think this can be quite easily
> remedied by making more committers/PMC, however there is a catch-22 that to
> achieve this our existing set of committers needs to be dedicated to
> reviewing contributions from non-committers.
>
> If we can get dedicated reviewers for the listed tickets I'll take on some
> of the work to get the tickets up to scratch.
>
> On Wed, 21 Nov 2018 at 02:12, Ariel Weisberg  wrote:
>
> > Hi,
> >
> > I would like to get as many of these as is feasible in. Before the
> feature
> > freeze started 1 out of 17 JIRAs that were patch available were reviewed
> > and committed.
> >
> > If you didn’t have access reviewers and committers, as the one out of the
> > 17 did, it has been essentially impossible to get your problems with
> > Cassandra fixed in 4.0.
> >
> > This is basically the same as saying that despite the fact Cassandra is
> > open source it does you no good because it will be years before the
> issues
> > impacting you get fixed even if you contribute the fixes yourself.
> >
> > Pulling up the ladder after getting “your own” fixes in is a sure fire
> way
> > to fracture the community into a collection of private forks containing
> the
> > fixes people can’t live without, and pushing people to look at
> alternatives.
> >
> > Private forks are a serious threat to the project. The people on them are
> > at risk of getting left behind and Cassandra stagnates for them and
> becomes
> > uncompetitive. Those with the resources to maintain a seriously diverged
> > fork are also the ones better positioned to be active contributors.
> >
> > Regards,
> > Ariel
> >
> > > On Nov 18, 2018, at 9:18 PM, Vinay Chella 
> > wrote:
> > >
> > > Hi,
> > >
> > > We still have 15 Patch Available/ open tickets which were requested for
> > > reviews before the Sep 1, 2018 freeze. I am starting this email thread
> to
> > > resurface and request a review of community tickets as most of these
> > > tickets address vital correctness, performance, and usability bugs that
> > > help avoid critical production issues. I tried to provide context on
> why
> > we
> > > feel these tickets are important to get into 4.0. If you would like to
> > > discuss the technical details of a particular ticket, let's try to do
> > that
> > > in JIRA.
> > >
> > > CASSANDRA-14525: Cluster enters an inconsistent state after bootstrap
> > > failures. (Correctness bug, Production impact, Ready to Commit)
> > >
> > > CASSANDRA-14459: DES sends requests to the wrong nodes routinely. (SLA
> > > breaking latencies, Production impact, Review in progress)
> > >
> > > CASSANDRA-14303 and CASSANDRA-14557: Currently production 3.0+ clusters
> > > cannot be rebuilt after node failure due to 3.0’s introduction of the
> > > system_auth keyspace with rf of 1. These tickets both fix the
> regression
> > > introduced in 3.0 by letting operators configure rf=3 and prevent
> future
> > > outages (Usability bug, Production impact, Patch Available).
> > >
> > > CASSANDRA-14096: Cassandra 3.11.1 Repair Causes Out of Memory. We
> believe
> > > this may also impact 3.0 (Title says it all, Production impact, Patch
> > > Available)
> > >
> > > CASSANDRA-10023: It is impossible to accurately determine local
> > read/write
> > > calls on C*. This patch allows users to detect when they are choosing
> > > incorrect coordinators. (Usability bug (troubleshoot), Review in
> > progress)
> > >
> > > CASSANDRA-10789: There is no way to safely stop bad clients bringing
> down
> > > C* nodes. This patch would give operators a very important tool to use
> > > during production incidents to mitigate impact. (Usability bug,
> > Production
> > > Impact (recovery), Patch Available)
> > >
> > > CASSANDRA-13010: No visibility into which disk is being compacted to.
> > > (Usability bug, Production Impact (troubleshoot), Review in progress)
> > >
> > > CASSANDRA-12783 - Break up large MV mutations to prevent OOMs (Title
> says
> > > it all, Production Impact, Patch InProgress/ Awaiting Feedback)
> > >
> > > CASSANDRA-14319 - nodetool rebuild from DC lets you pass invalid
> > > datacenters (Usability bug, Production impact, Patch available)
> > >
> > > CASSANDRA-13841 - Smarter nodetool rebuild. Kind of a bug but would be
> > nice
> > > to get it in 4.0. (Production Impact (recovery), Patch Available)
> > >
> > > CASSANDRA-9452: Cleanup of old configuration, confusing to new C*
> > > 

Re: Request to review feature-freeze proposed tickets

[kurt greaves]

Thanks Vinay. While I suspect this will be subject to heated debate, I'm
also for this. The time to review for this project is incredibly
demotivating, and it stems from a lack of contributors that are interested
in the general health of the project. I think this can be quite easily
remedied by making more committers/PMC, however there is a catch-22 that to
achieve this our existing set of committers needs to be dedicated to
reviewing contributions from non-committers.

If we can get dedicated reviewers for the listed tickets I'll take on some
of the work to get the tickets up to scratch.

On Wed, 21 Nov 2018 at 02:12, Ariel Weisberg  wrote:

> Hi,
>
> I would like to get as many of these as is feasible in. Before the feature
> freeze started 1 out of 17 JIRAs that were patch available were reviewed
> and committed.
>
> If you didn’t have access reviewers and committers, as the one out of the
> 17 did, it has been essentially impossible to get your problems with
> Cassandra fixed in 4.0.
>
> This is basically the same as saying that despite the fact Cassandra is
> open source it does you no good because it will be years before the issues
> impacting you get fixed even if you contribute the fixes yourself.
>
> Pulling up the ladder after getting “your own” fixes in is a sure fire way
> to fracture the community into a collection of private forks containing the
> fixes people can’t live without, and pushing people to look at alternatives.
>
> Private forks are a serious threat to the project. The people on them are
> at risk of getting left behind and Cassandra stagnates for them and becomes
> uncompetitive. Those with the resources to maintain a seriously diverged
> fork are also the ones better positioned to be active contributors.
>
> Regards,
> Ariel
>
> > On Nov 18, 2018, at 9:18 PM, Vinay Chella 
> wrote:
> >
> > Hi,
> >
> > We still have 15 Patch Available/ open tickets which were requested for
> > reviews before the Sep 1, 2018 freeze. I am starting this email thread to
> > resurface and request a review of community tickets as most of these
> > tickets address vital correctness, performance, and usability bugs that
> > help avoid critical production issues. I tried to provide context on why
> we
> > feel these tickets are important to get into 4.0. If you would like to
> > discuss the technical details of a particular ticket, let's try to do
> that
> > in JIRA.
> >
> > CASSANDRA-14525: Cluster enters an inconsistent state after bootstrap
> > failures. (Correctness bug, Production impact, Ready to Commit)
> >
> > CASSANDRA-14459: DES sends requests to the wrong nodes routinely. (SLA
> > breaking latencies, Production impact, Review in progress)
> >
> > CASSANDRA-14303 and CASSANDRA-14557: Currently production 3.0+ clusters
> > cannot be rebuilt after node failure due to 3.0’s introduction of the
> > system_auth keyspace with rf of 1. These tickets both fix the regression
> > introduced in 3.0 by letting operators configure rf=3 and prevent future
> > outages (Usability bug, Production impact, Patch Available).
> >
> > CASSANDRA-14096: Cassandra 3.11.1 Repair Causes Out of Memory. We believe
> > this may also impact 3.0 (Title says it all, Production impact, Patch
> > Available)
> >
> > CASSANDRA-10023: It is impossible to accurately determine local
> read/write
> > calls on C*. This patch allows users to detect when they are choosing
> > incorrect coordinators. (Usability bug (troubleshoot), Review in
> progress)
> >
> > CASSANDRA-10789: There is no way to safely stop bad clients bringing down
> > C* nodes. This patch would give operators a very important tool to use
> > during production incidents to mitigate impact. (Usability bug,
> Production
> > Impact (recovery), Patch Available)
> >
> > CASSANDRA-13010: No visibility into which disk is being compacted to.
> > (Usability bug, Production Impact (troubleshoot), Review in progress)
> >
> > CASSANDRA-12783 - Break up large MV mutations to prevent OOMs (Title says
> > it all, Production Impact, Patch InProgress/ Awaiting Feedback)
> >
> > CASSANDRA-14319 - nodetool rebuild from DC lets you pass invalid
> > datacenters (Usability bug, Production impact, Patch available)
> >
> > CASSANDRA-13841 - Smarter nodetool rebuild. Kind of a bug but would be
> nice
> > to get it in 4.0. (Production Impact (recovery), Patch Available)
> >
> > CASSANDRA-9452: Cleanup of old configuration, confusing to new C*
> > operators. (Cleanup, Patch Available)
> >
> > CASSANDRA-14309: Hint window persistence across the record. This way
> hints
> > that are accumulated over a period of time when nodes are creating are
> less
> > likely to take down the entire cluster. (Potential Production Impact,
> Patch
> > Available)
> >
> > CASSANDRA-14291: Bug from CASSANDRA-11163? (Usability Bug, Patch
> Available)
> >
> > CASSANDRA-10540: RangeAware compaction. 256 vnode clusters really need
> this
> > to be able to do basic things like repair. The patch needs some rework
> > after 

Re: RES: RES: Implicit Casts for Arithmetic Operators

[Michael Shuler]

On 11/20/18 10:15 AM, Versátil wrote:
> 
> I already requested as you said and it did not help. And I NEVER asked to 
> enter into this discussion. Please request to withdraw my email 

 | | | | | | | | | |
\/\/\/\/\/\/\/\/\/\/

> 
> -
> 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

RES: RES: Implicit Casts for Arithmetic Operators

[Versátil]

I already requested as you said and it did not help. And I NEVER asked to enter 
into this discussion. Please request to withdraw my email 

-Mensagem original-
De: Michael Shuler [mailto:mshu...@pbandjelly.org] Em nome de Michael Shuler
Enviada em: terça-feira, 20 de novembro de 2018 14:12
Para: dev@cassandra.apache.org
Cc: dev-unsubscribe-versatil=versatilengenharia.com...@cassandra.apache.org
Assunto: Re: RES: Implicit Casts for Arithmetic Operators

On 11/20/18 9:53 AM, Versátil wrote:
> 
> PLEASE TAKE MY EMAIL FROM THIS SHIT !!

FYI, mailing list subscriptions (and unsubscriptions) are self-serve. In 
general, you subscribed yourself, so you are responsible to unsubscribe.
The email address to do so is appended to every plain text message to the list.

You will still have to follow the approval link you'll get from the list 
moderation removal CC here, sent on your behalf...

--
Kind regards,
Michael

-
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: RES: Implicit Casts for Arithmetic Operators

[Michael Shuler]

On 11/20/18 9:53 AM, Versátil wrote:
> 
> PLEASE TAKE MY EMAIL FROM THIS SHIT !!

FYI, mailing list subscriptions (and unsubscriptions) are self-serve. In
general, you subscribed yourself, so you are responsible to unsubscribe.
The email address to do so is appended to every plain text message to
the list.

You will still have to follow the approval link you'll get from the list
moderation removal CC here, sent on your behalf...

-- 
Kind regards,
Michael

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

Re: Implicit Casts for Arithmetic Operators

[Benedict Elliott Smith]

FWIW, my meaning of arithmetic in this context extends to any features we have 
already released (such as aggregates, and perhaps other built-in functions) 
that operate on the same domain.  We should be consistent, after all.

Whether or not we need to revisit any existing functionality we can figure out 
after the fact, once we have agreed what our behaviour should be.

I will make this more explicit for the vote, but just to clarify the intention 
so that we are all discussing the same thing.


> On 20 Nov 2018, at 14:18, Ariel Weisberg  wrote:
> 
> Hi,
> 
> +1
> 
> This is a public API so we will be much better off if we get it right the 
> first time.
> 
> Ariel
> 
>> On Nov 16, 2018, at 10:36 AM, Jonathan Haddad  wrote:
>> 
>> Sounds good to me.
>> 
>> On Fri, Nov 16, 2018 at 5:09 AM Benedict Elliott Smith 
>> wrote:
>> 
>>> So, this thread somewhat petered out.
>>> 
>>> There are still a number of unresolved issues, but to make progress I
>>> wonder if it would first be helpful to have a vote on ensuring we are ANSI
>>> SQL 92 compliant for our arithmetic?  This seems like a sensible baseline,
>>> since we will hopefully minimise surprise to operators this way.
>>> 
>>> If people largely agree, I will call a vote, and we can pick up a couple
>>> of more focused discussions afterwards on how we interpret the leeway it
>>> gives.
>>> 
>>> 
 On 12 Oct 2018, at 18:10, Ariel Weisberg  wrote:
 
 Hi,
 
 From reading the spec. Precision is always implementation defined. The
>>> spec specifies scale in several cases, but never precision for any type or
>>> operation (addition/subtraction, multiplication, division).
 
 So we don't implement anything remotely approaching precision and scale
>>> in CQL when it comes to numbers I think? So we aren't going to follow the
>>> spec for scale. We are already pretty far down that road so I would leave
>>> it alone.
 
 I don't think the spec is asking for the most approximate type. It's
>>> just saying the result is approximate, and the precision is implementation
>>> defined. We could return either float or double. I think if one of the
>>> operands is a double we should return a double because clearly the schema
>>> thought a double was required to represent that number. I would also be in
>>> favor of returning a double all the time so that people can expect a
>>> consistent type from expressions involving approximate numbers.
 
 I am a big fan of widening for arithmetic expressions in a database to
>>> avoid having to error on overflow. You can go to the trouble of only
>>> widening the minimum amount, but I think it's simpler if we always widen to
>>> bigint and double. This would be something the spec allows.
 
 Definitely if we can make overflow not occur we should and the spec
>>> allows that. We should also not return different types for the same operand
>>> types just to work around overflow if we detect we need more precision.
 
 Ariel
> On Fri, Oct 12, 2018, at 12:45 PM, Benedict Elliott Smith wrote:
> If it’s in the SQL spec, I’m fairly convinced.  Thanks for digging this
> out (and Mike for getting some empirical examples).
> 
> We still have to decide on the approximate data type to return; right
> now, we have float+bigint=double, but float+int=float.  I think this is
> fairly inconsistent, and either the approximate type should always win,
> or we should always upgrade to double for mixed operands.
> 
> The quoted spec also suggests that decimal+float=float, and decimal
> +double=double, whereas we currently have decimal+float=decimal, and
> decimal+double=decimal
> 
> If we’re going to go with an approximate operand implying an
>>> approximate
> result, I think we should do it consistently (and consistent with the
> SQL92 spec), and have the type of the approximate operand always be the
> return type.
> 
> This would still leave a decision for float+double, though.  The most
> consistent behaviour with that stated above would be to always take the
> most approximate type to return (i.e. float), but this would seem to me
> to be fairly unexpected for the user.
> 
> 
>> On 12 Oct 2018, at 17:23, Ariel Weisberg  wrote:
>> 
>> Hi,
>> 
>> I agree with what's been said about expectations regarding expressions
>>> involving floating point numbers. I think that if one of the inputs is
>>> approximate then the result should be approximate.
>> 
>> One thing we could look at for inspiration is the SQL spec. Not to
>>> follow dogmatically necessarily.
>> 
>> From the SQL 92 spec regarding assignment
>>> http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt section 4.6:
>> "
>>  Values of the data types NUMERIC, DECIMAL, INTEGER, SMALLINT,
>>  FLOAT, REAL, and DOUBLE PRECISION are numbers and are all
>>> mutually
>>  comparable and mutually 

RES: Implicit Casts for Arithmetic Operators

[Versátil]

PLEASE TAKE MY EMAIL FROM THIS SHIT !!


-Mensagem original-
De: Michael Burman [mailto:y...@iki.fi] 
Enviada em: terça-feira, 20 de novembro de 2018 13:51
Para: dev@cassandra.apache.org
Assunto: Re: Implicit Casts for Arithmetic Operators

Yep, that's a good approach.

  - Micke

On Tue, Nov 20, 2018 at 5:12 PM Ariel Weisberg  wrote:

> Hi,
>
> +1
>
> This is a public API so we will be much better off if we get it right 
> the first time.
>
> Ariel
>
> > On Nov 16, 2018, at 10:36 AM, Jonathan Haddad  wrote:
> >
> > Sounds good to me.
> >
> > On Fri, Nov 16, 2018 at 5:09 AM Benedict Elliott Smith <
> bened...@apache.org>
> > wrote:
> >
> >> So, this thread somewhat petered out.
> >>
> >> There are still a number of unresolved issues, but to make progress 
> >> I wonder if it would first be helpful to have a vote on ensuring we 
> >> are
> ANSI
> >> SQL 92 compliant for our arithmetic?  This seems like a sensible
> baseline,
> >> since we will hopefully minimise surprise to operators this way.
> >>
> >> If people largely agree, I will call a vote, and we can pick up a 
> >> couple of more focused discussions afterwards on how we interpret 
> >> the leeway it gives.
> >>
> >>
> >>> On 12 Oct 2018, at 18:10, Ariel Weisberg  wrote:
> >>>
> >>> Hi,
> >>>
> >>> From reading the spec. Precision is always implementation defined. 
> >>> The
> >> spec specifies scale in several cases, but never precision for any 
> >> type
> or
> >> operation (addition/subtraction, multiplication, division).
> >>>
> >>> So we don't implement anything remotely approaching precision and 
> >>> scale
> >> in CQL when it comes to numbers I think? So we aren't going to 
> >> follow
> the
> >> spec for scale. We are already pretty far down that road so I would
> leave
> >> it alone.
> >>>
> >>> I don't think the spec is asking for the most approximate type. 
> >>> It's
> >> just saying the result is approximate, and the precision is
> implementation
> >> defined. We could return either float or double. I think if one of 
> >> the operands is a double we should return a double because clearly 
> >> the
> schema
> >> thought a double was required to represent that number. I would 
> >> also be
> in
> >> favor of returning a double all the time so that people can expect 
> >> a consistent type from expressions involving approximate numbers.
> >>>
> >>> I am a big fan of widening for arithmetic expressions in a 
> >>> database to
> >> avoid having to error on overflow. You can go to the trouble of 
> >> only widening the minimum amount, but I think it's simpler if we 
> >> always
> widen to
> >> bigint and double. This would be something the spec allows.
> >>>
> >>> Definitely if we can make overflow not occur we should and the 
> >>> spec
> >> allows that. We should also not return different types for the same
> operand
> >> types just to work around overflow if we detect we need more precision.
> >>>
> >>> Ariel
>  On Fri, Oct 12, 2018, at 12:45 PM, Benedict Elliott Smith wrote:
>  If it’s in the SQL spec, I’m fairly convinced.  Thanks for 
>  digging
> this
>  out (and Mike for getting some empirical examples).
> 
>  We still have to decide on the approximate data type to return; 
>  right now, we have float+bigint=double, but float+int=float.  I 
>  think this
> is
>  fairly inconsistent, and either the approximate type should 
>  always
> win,
>  or we should always upgrade to double for mixed operands.
> 
>  The quoted spec also suggests that decimal+float=float, and 
>  decimal
>  +double=double, whereas we currently have decimal+float=decimal, 
>  +and
>  decimal+double=decimal
> 
>  If we’re going to go with an approximate operand implying an
> >> approximate
>  result, I think we should do it consistently (and consistent with 
>  the
>  SQL92 spec), and have the type of the approximate operand always 
>  be
> the
>  return type.
> 
>  This would still leave a decision for float+double, though.  The 
>  most consistent behaviour with that stated above would be to 
>  always take
> the
>  most approximate type to return (i.e. float), but this would seem 
>  to
> me
>  to be fairly unexpected for the user.
> 
> 
> > On 12 Oct 2018, at 17:23, Ariel Weisberg  wrote:
> >
> > Hi,
> >
> > I agree with what's been said about expectations regarding
> expressions
> >> involving floating point numbers. I think that if one of the inputs 
> >> is approximate then the result should be approximate.
> >
> > One thing we could look at for inspiration is the SQL spec. Not 
> > to
> >> follow dogmatically necessarily.
> >
> > From the SQL 92 spec regarding assignment
> >> http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt section 4.6:
> > "
> >   Values of the data types NUMERIC, DECIMAL, INTEGER, SMALLINT,
> >   FLOAT, REAL, and DOUBLE PRECISION 

Re: Implicit Casts for Arithmetic Operators

[Michael Burman]

Yep, that's a good approach.

  - Micke

On Tue, Nov 20, 2018 at 5:12 PM Ariel Weisberg  wrote:

> Hi,
>
> +1
>
> This is a public API so we will be much better off if we get it right the
> first time.
>
> Ariel
>
> > On Nov 16, 2018, at 10:36 AM, Jonathan Haddad  wrote:
> >
> > Sounds good to me.
> >
> > On Fri, Nov 16, 2018 at 5:09 AM Benedict Elliott Smith <
> bened...@apache.org>
> > wrote:
> >
> >> So, this thread somewhat petered out.
> >>
> >> There are still a number of unresolved issues, but to make progress I
> >> wonder if it would first be helpful to have a vote on ensuring we are
> ANSI
> >> SQL 92 compliant for our arithmetic?  This seems like a sensible
> baseline,
> >> since we will hopefully minimise surprise to operators this way.
> >>
> >> If people largely agree, I will call a vote, and we can pick up a couple
> >> of more focused discussions afterwards on how we interpret the leeway it
> >> gives.
> >>
> >>
> >>> On 12 Oct 2018, at 18:10, Ariel Weisberg  wrote:
> >>>
> >>> Hi,
> >>>
> >>> From reading the spec. Precision is always implementation defined. The
> >> spec specifies scale in several cases, but never precision for any type
> or
> >> operation (addition/subtraction, multiplication, division).
> >>>
> >>> So we don't implement anything remotely approaching precision and scale
> >> in CQL when it comes to numbers I think? So we aren't going to follow
> the
> >> spec for scale. We are already pretty far down that road so I would
> leave
> >> it alone.
> >>>
> >>> I don't think the spec is asking for the most approximate type. It's
> >> just saying the result is approximate, and the precision is
> implementation
> >> defined. We could return either float or double. I think if one of the
> >> operands is a double we should return a double because clearly the
> schema
> >> thought a double was required to represent that number. I would also be
> in
> >> favor of returning a double all the time so that people can expect a
> >> consistent type from expressions involving approximate numbers.
> >>>
> >>> I am a big fan of widening for arithmetic expressions in a database to
> >> avoid having to error on overflow. You can go to the trouble of only
> >> widening the minimum amount, but I think it's simpler if we always
> widen to
> >> bigint and double. This would be something the spec allows.
> >>>
> >>> Definitely if we can make overflow not occur we should and the spec
> >> allows that. We should also not return different types for the same
> operand
> >> types just to work around overflow if we detect we need more precision.
> >>>
> >>> Ariel
>  On Fri, Oct 12, 2018, at 12:45 PM, Benedict Elliott Smith wrote:
>  If it’s in the SQL spec, I’m fairly convinced.  Thanks for digging
> this
>  out (and Mike for getting some empirical examples).
> 
>  We still have to decide on the approximate data type to return; right
>  now, we have float+bigint=double, but float+int=float.  I think this
> is
>  fairly inconsistent, and either the approximate type should always
> win,
>  or we should always upgrade to double for mixed operands.
> 
>  The quoted spec also suggests that decimal+float=float, and decimal
>  +double=double, whereas we currently have decimal+float=decimal, and
>  decimal+double=decimal
> 
>  If we’re going to go with an approximate operand implying an
> >> approximate
>  result, I think we should do it consistently (and consistent with the
>  SQL92 spec), and have the type of the approximate operand always be
> the
>  return type.
> 
>  This would still leave a decision for float+double, though.  The most
>  consistent behaviour with that stated above would be to always take
> the
>  most approximate type to return (i.e. float), but this would seem to
> me
>  to be fairly unexpected for the user.
> 
> 
> > On 12 Oct 2018, at 17:23, Ariel Weisberg  wrote:
> >
> > Hi,
> >
> > I agree with what's been said about expectations regarding
> expressions
> >> involving floating point numbers. I think that if one of the inputs is
> >> approximate then the result should be approximate.
> >
> > One thing we could look at for inspiration is the SQL spec. Not to
> >> follow dogmatically necessarily.
> >
> > From the SQL 92 spec regarding assignment
> >> http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt section 4.6:
> > "
> >   Values of the data types NUMERIC, DECIMAL, INTEGER, SMALLINT,
> >   FLOAT, REAL, and DOUBLE PRECISION are numbers and are all
> >> mutually
> >   comparable and mutually assignable. If an assignment would
> >> result
> >   in a loss of the most significant digits, an exception
> condition
> >   is raised. If least significant digits are lost,
> implementation-
> >   defined rounding or truncating occurs with no exception
> >> condition
> >   being raised. The rules for 

Re: Request to review feature-freeze proposed tickets

[Ariel Weisberg]

Hi,

I would like to get as many of these as is feasible in. Before the feature 
freeze started 1 out of 17 JIRAs that were patch available were reviewed and 
committed.

If you didn’t have access reviewers and committers, as the one out of the 17 
did, it has been essentially impossible to get your problems with Cassandra 
fixed in 4.0.

This is basically the same as saying that despite the fact Cassandra is open 
source it does you no good because it will be years before the issues impacting 
you get fixed even if you contribute the fixes yourself.

Pulling up the ladder after getting “your own” fixes in is a sure fire way to 
fracture the community into a collection of private forks containing the fixes 
people can’t live without, and pushing people to look at alternatives.

Private forks are a serious threat to the project. The people on them are at 
risk of getting left behind and Cassandra stagnates for them and becomes 
uncompetitive. Those with the resources to maintain a seriously diverged fork 
are also the ones better positioned to be active contributors.

Regards,
Ariel

> On Nov 18, 2018, at 9:18 PM, Vinay Chella  wrote:
> 
> Hi,
> 
> We still have 15 Patch Available/ open tickets which were requested for
> reviews before the Sep 1, 2018 freeze. I am starting this email thread to
> resurface and request a review of community tickets as most of these
> tickets address vital correctness, performance, and usability bugs that
> help avoid critical production issues. I tried to provide context on why we
> feel these tickets are important to get into 4.0. If you would like to
> discuss the technical details of a particular ticket, let's try to do that
> in JIRA.
> 
> CASSANDRA-14525: Cluster enters an inconsistent state after bootstrap
> failures. (Correctness bug, Production impact, Ready to Commit)
> 
> CASSANDRA-14459: DES sends requests to the wrong nodes routinely. (SLA
> breaking latencies, Production impact, Review in progress)
> 
> CASSANDRA-14303 and CASSANDRA-14557: Currently production 3.0+ clusters
> cannot be rebuilt after node failure due to 3.0’s introduction of the
> system_auth keyspace with rf of 1. These tickets both fix the regression
> introduced in 3.0 by letting operators configure rf=3 and prevent future
> outages (Usability bug, Production impact, Patch Available).
> 
> CASSANDRA-14096: Cassandra 3.11.1 Repair Causes Out of Memory. We believe
> this may also impact 3.0 (Title says it all, Production impact, Patch
> Available)
> 
> CASSANDRA-10023: It is impossible to accurately determine local read/write
> calls on C*. This patch allows users to detect when they are choosing
> incorrect coordinators. (Usability bug (troubleshoot), Review in progress)
> 
> CASSANDRA-10789: There is no way to safely stop bad clients bringing down
> C* nodes. This patch would give operators a very important tool to use
> during production incidents to mitigate impact. (Usability bug, Production
> Impact (recovery), Patch Available)
> 
> CASSANDRA-13010: No visibility into which disk is being compacted to.
> (Usability bug, Production Impact (troubleshoot), Review in progress)
> 
> CASSANDRA-12783 - Break up large MV mutations to prevent OOMs (Title says
> it all, Production Impact, Patch InProgress/ Awaiting Feedback)
> 
> CASSANDRA-14319 - nodetool rebuild from DC lets you pass invalid
> datacenters (Usability bug, Production impact, Patch available)
> 
> CASSANDRA-13841 - Smarter nodetool rebuild. Kind of a bug but would be nice
> to get it in 4.0. (Production Impact (recovery), Patch Available)
> 
> CASSANDRA-9452: Cleanup of old configuration, confusing to new C*
> operators. (Cleanup, Patch Available)
> 
> CASSANDRA-14309: Hint window persistence across the record. This way hints
> that are accumulated over a period of time when nodes are creating are less
> likely to take down the entire cluster. (Potential Production Impact, Patch
> Available)
> 
> CASSANDRA-14291: Bug from CASSANDRA-11163? (Usability Bug, Patch Available)
> 
> CASSANDRA-10540: RangeAware compaction. 256 vnode clusters really need this
> to be able to do basic things like repair. The patch needs some rework
> after transient replication (Production impact, needs contributor time)
> 
> URL for all the tickets: JIRA
> 
> 
> 
> Let me know.
> Thanks,
> Vinay Chella


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: 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."
>

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

[Vishal1.Sharma]

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."

Re: I/O threads busy error

[dinesh.jo...@yahoo.com.INVALID]

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."
B�CB��[��X��ܚX�KK[XZ[�]�][��X��ܚX�P�\��[��K�\X�K�ܙ�B��܈Y][ۘ[��[X[��K[XZ[�]�Z[�\��[��K�\X�K�ܙ�B�B