Re: sstableloader from java

[J. D. Jordan]

Yeah. I wouldn't use that class, I was just pointing it out as an example of 
code doing a similar thing.

> On Sep 21, 2016, at 8:16 PM, Paul Weiss  wrote:
> 
> Great will try out.   I noticed the code is within the hadoop folder,  I am
> using local disk so hopefully it will work without hadoop.
> 
> Thanks,
> -paul
> 
> On Sep 21, 2016 8:56 PM, "Jeremiah D Jordan" 
> wrote:
> 
>> Yes using the SSTableLoader class.  You can see the CqlBulkRecordWriter
>> class for an example of writing out sstables to disk and then using the
>> SSTableLoader class to stream them to a cluster.
>> 
>> -Jeremiah
>> 
>>> On Sep 21, 2016, at 7:18 PM, Paul Weiss  wrote:
>>> 
>>> Hi,
>>> 
>>> Is it possible to call the sstableloader from java instead using the
>>> command line program? I have a process that uses the CQLSSTableWriter and
>>> generates the sstable files but am looking for an end to end process that
>>> bulk loads without any manual intervention.
>>> 
>>> Ideally would like to avoid forking another process so I can properly
>> check
>>> for errors.
>>> 
>>> Thanks,
>>> -paul
>> 
>> 

Re: sstableloader from java

[Paul Weiss]

Great will try out.   I noticed the code is within the hadoop folder,  I am
using local disk so hopefully it will work without hadoop.

Thanks,
-paul

On Sep 21, 2016 8:56 PM, "Jeremiah D Jordan" 
wrote:

> Yes using the SSTableLoader class.  You can see the CqlBulkRecordWriter
> class for an example of writing out sstables to disk and then using the
> SSTableLoader class to stream them to a cluster.
>
> -Jeremiah
>
> > On Sep 21, 2016, at 7:18 PM, Paul Weiss  wrote:
> >
> > Hi,
> >
> > Is it possible to call the sstableloader from java instead using the
> > command line program? I have a process that uses the CQLSSTableWriter and
> > generates the sstable files but am looking for an end to end process that
> > bulk loads without any manual intervention.
> >
> > Ideally would like to avoid forking another process so I can properly
> check
> > for errors.
> >
> > Thanks,
> > -paul
>
>

Re: sstableloader from java

[Jeremiah D Jordan]

Yes using the SSTableLoader class.  You can see the CqlBulkRecordWriter class 
for an example of writing out sstables to disk and then using the SSTableLoader 
class to stream them to a cluster.

-Jeremiah

> On Sep 21, 2016, at 7:18 PM, Paul Weiss  wrote:
> 
> Hi,
> 
> Is it possible to call the sstableloader from java instead using the
> command line program? I have a process that uses the CQLSSTableWriter and
> generates the sstable files but am looking for an end to end process that
> bulk loads without any manual intervention.
> 
> Ideally would like to avoid forking another process so I can properly check
> for errors.
> 
> Thanks,
> -paul

sstableloader from java

[Paul Weiss]

Hi,

Is it possible to call the sstableloader from java instead using the
command line program? I have a process that uses the CQLSSTableWriter and
generates the sstable files but am looking for an end to end process that
bulk loads without any manual intervention.

Ideally would like to avoid forking another process so I can properly check
for errors.

Thanks,
-paul

Re: Guidelines for test coverage

[Nate McCall]

We have these already written down in from both the reviewing and
development perspective:
http://cassandra.apache.org/doc/latest/development/how_to_review.html
http://cassandra.apache.org/doc/latest/development/testing.html

My takeaway from recent in-person discussions the other week about this
topic, is that it's really just a matter of making this less of a
chore/sharing the burden of reviews when the whole dtest suite has to be
run.

Thanks for bringing this up, though.

On Tue, Sep 20, 2016 at 6:42 AM, sankalp kohli 
wrote:

> Hi,
> I wanted to know if there are any guidelines for contributors to give
> out unit and integration tests along with the patches. If not, we should
> discuss and have them in place.
>
> I know we are making good progress with test coverage but we should add
> guidelines around adding unit and integration tests with every patch.
> Thoughts on this?
>
> Thanks,
> Sankalp
>



-- 
-
Nate McCall
Wellington, NZ
@zznate

CTO
Apache Cassandra Consulting
http://www.thelastpickle.com

Re: Question on assert

[DuyHai Doan]

I found that SO question very interesting to fuel the discussion about
assert vs exception :
http://stackoverflow.com/questions/1957645/when-to-use-an-assertion-and-when-to-use-an-exception

On Wed, Sep 21, 2016 at 8:20 PM, Michael Kjellman <
mkjell...@internalcircle.com> wrote:

> Yeah, I understand what you're saying, don't get me wrong.
>
> However, I just spent close to a year total working and writing
> CASSANDRA-9754 and when you're dealing with IO, sometimes asserts are the
> right way to go. I found putting them there are sanity checks mostly to
> ensure that code changes to other parts of the code don't have unexpected
> interactions with the input bounds expected by a method. I think asserts
> are fine (and correct) in these cases.
>
>
> > On Sep 21, 2016, at 11:16 AM, Edward Capriolo 
> wrote:
> >
> > You are essentially arguing, "if you turn off -ea your screwed" which is
> a
> > symptom of a larger problem that I am pointing out.
> >
> > Forget the "5%" thing. I am having a discussion about use of assert.
> >
> > You have:
> > 1) checked exceptions
> > 2) unchecked exceptions
> > 3) Error (like ioError which we sometime have to track)
> >
> > The common case for assert is to only be used in testing. This is why -ea
> > is off by default.
> >
> > My point is that using assert as a Apache Cassandra specific "psuedo
> > exception" seems problematic. I can point at tickets in the Cassandra
> Jira
> > where the this is not trapped properly. It appears to me that having deal
> > with a 4th "pseudo exception" is code smell.
> >
> > Sometimes you see assert in place of a bounds check or a null check that
> > you would never want to turn off. Other times it is uses as a quasi
> > IllegalStateException. Other times an class named "estimator" asserts
> when
> > the "estimate" "overflows". This seem far away from the defined purpose
> of
> > assert.
> >
> > The glaring issue is that it bubbles through try catch so it hardly makes
> > me feel "safe" either on or off.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Wed, Sep 21, 2016 at 1:34 PM, Michael Kjellman <
> > mkjell...@internalcircle.com> wrote:
> >
> >> Asserts have their place as sanity checks. Just like exceptions have
> their
> >> place.
> >>
> >> They can both live in harmony and they both serve a purpose.
> >>
> >> What doesn't serve a purpose is that comment encouraging n00b users to
> get
> >> a mythical 5% performance increase and then get silent corruption when
> >> their disk/io goes sideways and the asserts might have caught things
> before
> >> it went really wrong.
> >>
> >> Sent from my iPhone
> >>
> >> On Sep 21, 2016, at 10:31 AM, Edward Capriolo  >> > wrote:
> >>
> >> " potential 5% performance win when you've corrupted all their data."
> >> This is somewhat of my point. Why do assertions that sometimes are
> trapped
> >> "protect my data" better then a checked exception?
> >>
> >> On Wed, Sep 21, 2016 at 1:24 PM, Michael Kjellman <
> >> mkjell...@internalcircle.com>
> wrote:
> >>
> >> I hate that comment with a passion. Please please please please do
> >> yourself a favor and *always* run with asserts on. `-ea` for life. In
> >> practice I'd be surprised if you actually got a reliable 5% performance
> win
> >> and I doubt your customers will care about a potential 5% performance
> win
> >> when you've corrupted all their data.
> >>
> >> best,
> >> kjellman
> >>
> >> On Sep 21, 2016, at 10:21 AM, Edward Capriolo  >> >
> >> wrote:
> >>
> >> There are a variety of assert usages in the Cassandra. You can find
> >> several
> >> tickets like mine.
> >>
> >> https://issues.apache.org/jira/browse/CASSANDRA-12643
> >>
> >> https://issues.apache.org/jira/browse/CASSANDRA-11537
> >>
> >> Just to prove that I am not the only one who runs into these:
> >>
> >> https://issues.apache.org/jira/browse/CASSANDRA-12484
> >>
> >> To paraphrase another ticket that I read today and can not find,
> >> "The problem is X throws Assertion which is not caught by the Exception
> >> handler and it bubbles over and creates a thread death."
> >>
> >> The jvm.properties file claims this:
> >>
> >> # enable assertions.  disabling this in production will give a modest
> >> # performance benefit (around 5%).
> >> -ea
> >>
> >> If assertions incur a "5% penalty" but are not always trapped what value
> >> do
> >> they add?
> >>
> >> These are common sentiments about how assert should be used: (not trying
> >> to
> >> make this a this is what the internet says type debate)
> >>
> >> http://stackoverflow.com/questions/2758224/what-does-
> >> the-java-assert-keyword-do-and-when-should-it-be-used
> >>
> >> "Assertions
> >>  >
> >> (by
> >> way of the *assert* keyword) were added in Java 1.4. They are used to
> >> verify the 

Re: chronicles

[Julien Bertozzi]

?

2016-09-21 7:09 GMT+02:00 Codarren Velvindron :

>
>

Re: Question on assert

[Michael Kjellman]

Yeah, I understand what you're saying, don't get me wrong.

However, I just spent close to a year total working and writing CASSANDRA-9754 
and when you're dealing with IO, sometimes asserts are the right way to go. I 
found putting them there are sanity checks mostly to ensure that code changes 
to other parts of the code don't have unexpected interactions with the input 
bounds expected by a method. I think asserts are fine (and correct) in these 
cases.


> On Sep 21, 2016, at 11:16 AM, Edward Capriolo  wrote:
> 
> You are essentially arguing, "if you turn off -ea your screwed" which is a
> symptom of a larger problem that I am pointing out.
> 
> Forget the "5%" thing. I am having a discussion about use of assert.
> 
> You have:
> 1) checked exceptions
> 2) unchecked exceptions
> 3) Error (like ioError which we sometime have to track)
> 
> The common case for assert is to only be used in testing. This is why -ea
> is off by default.
> 
> My point is that using assert as a Apache Cassandra specific "psuedo
> exception" seems problematic. I can point at tickets in the Cassandra Jira
> where the this is not trapped properly. It appears to me that having deal
> with a 4th "pseudo exception" is code smell.
> 
> Sometimes you see assert in place of a bounds check or a null check that
> you would never want to turn off. Other times it is uses as a quasi
> IllegalStateException. Other times an class named "estimator" asserts when
> the "estimate" "overflows". This seem far away from the defined purpose of
> assert.
> 
> The glaring issue is that it bubbles through try catch so it hardly makes
> me feel "safe" either on or off.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Wed, Sep 21, 2016 at 1:34 PM, Michael Kjellman <
> mkjell...@internalcircle.com> wrote:
> 
>> Asserts have their place as sanity checks. Just like exceptions have their
>> place.
>> 
>> They can both live in harmony and they both serve a purpose.
>> 
>> What doesn't serve a purpose is that comment encouraging n00b users to get
>> a mythical 5% performance increase and then get silent corruption when
>> their disk/io goes sideways and the asserts might have caught things before
>> it went really wrong.
>> 
>> Sent from my iPhone
>> 
>> On Sep 21, 2016, at 10:31 AM, Edward Capriolo > > wrote:
>> 
>> " potential 5% performance win when you've corrupted all their data."
>> This is somewhat of my point. Why do assertions that sometimes are trapped
>> "protect my data" better then a checked exception?
>> 
>> On Wed, Sep 21, 2016 at 1:24 PM, Michael Kjellman <
>> mkjell...@internalcircle.com> wrote:
>> 
>> I hate that comment with a passion. Please please please please do
>> yourself a favor and *always* run with asserts on. `-ea` for life. In
>> practice I'd be surprised if you actually got a reliable 5% performance win
>> and I doubt your customers will care about a potential 5% performance win
>> when you've corrupted all their data.
>> 
>> best,
>> kjellman
>> 
>> On Sep 21, 2016, at 10:21 AM, Edward Capriolo > >
>> wrote:
>> 
>> There are a variety of assert usages in the Cassandra. You can find
>> several
>> tickets like mine.
>> 
>> https://issues.apache.org/jira/browse/CASSANDRA-12643
>> 
>> https://issues.apache.org/jira/browse/CASSANDRA-11537
>> 
>> Just to prove that I am not the only one who runs into these:
>> 
>> https://issues.apache.org/jira/browse/CASSANDRA-12484
>> 
>> To paraphrase another ticket that I read today and can not find,
>> "The problem is X throws Assertion which is not caught by the Exception
>> handler and it bubbles over and creates a thread death."
>> 
>> The jvm.properties file claims this:
>> 
>> # enable assertions.  disabling this in production will give a modest
>> # performance benefit (around 5%).
>> -ea
>> 
>> If assertions incur a "5% penalty" but are not always trapped what value
>> do
>> they add?
>> 
>> These are common sentiments about how assert should be used: (not trying
>> to
>> make this a this is what the internet says type debate)
>> 
>> http://stackoverflow.com/questions/2758224/what-does-
>> the-java-assert-keyword-do-and-when-should-it-be-used
>> 
>> "Assertions
>> 
>> (by
>> way of the *assert* keyword) were added in Java 1.4. They are used to
>> verify the correctness of an invariant in the code. They should never be
>> triggered in production code, and are indicative of a bug or misuse of a
>> code path. They can be activated at run-time by way of the -eaoption on
>> the
>> java command, but are not turned on by default."
>> 
>> http://stackoverflow.com/questions/1957645/when-to-use-
>> an-assertion-and-when-to-use-an-exception
>> 
>> "An assertion would stop the program from running, but an exception would
>> let the program continue running."
>> 
>> I look at how 

Re: Question on assert

[Jonathan Ellis]

That sounds to me like we have some asserts that should be turned into
actual exceptions.  (I'm definitely not arguing that ALL our asserts are in
this category.)

On Wed, Sep 21, 2016 at 12:34 PM, Michael Kjellman <
mkjell...@internalcircle.com> wrote:

> Asserts have their place as sanity checks. Just like exceptions have their
> place.
>
> They can both live in harmony and they both serve a purpose.
>
> What doesn't serve a purpose is that comment encouraging n00b users to get
> a mythical 5% performance increase and then get silent corruption when
> their disk/io goes sideways and the asserts might have caught things before
> it went really wrong.
>
> Sent from my iPhone
>
> On Sep 21, 2016, at 10:31 AM, Edward Capriolo  > wrote:
>
> " potential 5% performance win when you've corrupted all their data."
> This is somewhat of my point. Why do assertions that sometimes are trapped
> "protect my data" better then a checked exception?
>
> On Wed, Sep 21, 2016 at 1:24 PM, Michael Kjellman <
> mkjell...@internalcircle.com> wrote:
>
> I hate that comment with a passion. Please please please please do
> yourself a favor and *always* run with asserts on. `-ea` for life. In
> practice I'd be surprised if you actually got a reliable 5% performance win
> and I doubt your customers will care about a potential 5% performance win
> when you've corrupted all their data.
>
> best,
> kjellman
>
> On Sep 21, 2016, at 10:21 AM, Edward Capriolo  >
> wrote:
>
> There are a variety of assert usages in the Cassandra. You can find
> several
> tickets like mine.
>
> https://issues.apache.org/jira/browse/CASSANDRA-12643
>
> https://issues.apache.org/jira/browse/CASSANDRA-11537
>
> Just to prove that I am not the only one who runs into these:
>
> https://issues.apache.org/jira/browse/CASSANDRA-12484
>
> To paraphrase another ticket that I read today and can not find,
> "The problem is X throws Assertion which is not caught by the Exception
> handler and it bubbles over and creates a thread death."
>
> The jvm.properties file claims this:
>
> # enable assertions.  disabling this in production will give a modest
> # performance benefit (around 5%).
> -ea
>
> If assertions incur a "5% penalty" but are not always trapped what value
> do
> they add?
>
> These are common sentiments about how assert should be used: (not trying
> to
> make this a this is what the internet says type debate)
>
> http://stackoverflow.com/questions/2758224/what-does-
> the-java-assert-keyword-do-and-when-should-it-be-used
>
> "Assertions
> 
> (by
> way of the *assert* keyword) were added in Java 1.4. They are used to
> verify the correctness of an invariant in the code. They should never be
> triggered in production code, and are indicative of a bug or misuse of a
> code path. They can be activated at run-time by way of the -eaoption on
> the
> java command, but are not turned on by default."
>
> http://stackoverflow.com/questions/1957645/when-to-use-
> an-assertion-and-when-to-use-an-exception
>
> "An assertion would stop the program from running, but an exception would
> let the program continue running."
>
> I look at how Cassandra uses assert and how it manifests in how the code
> operates in production. Assert is something like semi-unchecked
> exception.
> All types of internal Util classes might throw it, downstream code is
> essentially unaware and rarely specifically handles it. They do not
> always
> result in the hard death one would expect from an assert.
>
> I know this is a ballpark type figure, but would "5% performance penalty"
> be in the ballpark of a checked exception? Being that they tend to bubble
> through things uncaught do they do more danger than good?
>
>
>


-- 
Jonathan Ellis
co-founder, http://www.datastax.com
@spyced

Re: Question on assert

[Michael Kjellman]

Asserts have their place as sanity checks. Just like exceptions have their 
place.

They can both live in harmony and they both serve a purpose.

What doesn't serve a purpose is that comment encouraging n00b users to get a 
mythical 5% performance increase and then get silent corruption when their 
disk/io goes sideways and the asserts might have caught things before it went 
really wrong.

Sent from my iPhone

On Sep 21, 2016, at 10:31 AM, Edward Capriolo 
> wrote:

" potential 5% performance win when you've corrupted all their data."
This is somewhat of my point. Why do assertions that sometimes are trapped
"protect my data" better then a checked exception?

On Wed, Sep 21, 2016 at 1:24 PM, Michael Kjellman <
mkjell...@internalcircle.com> wrote:

I hate that comment with a passion. Please please please please do
yourself a favor and *always* run with asserts on. `-ea` for life. In
practice I'd be surprised if you actually got a reliable 5% performance win
and I doubt your customers will care about a potential 5% performance win
when you've corrupted all their data.

best,
kjellman

On Sep 21, 2016, at 10:21 AM, Edward Capriolo 
>
wrote:

There are a variety of assert usages in the Cassandra. You can find
several
tickets like mine.

https://issues.apache.org/jira/browse/CASSANDRA-12643

https://issues.apache.org/jira/browse/CASSANDRA-11537

Just to prove that I am not the only one who runs into these:

https://issues.apache.org/jira/browse/CASSANDRA-12484

To paraphrase another ticket that I read today and can not find,
"The problem is X throws Assertion which is not caught by the Exception
handler and it bubbles over and creates a thread death."

The jvm.properties file claims this:

# enable assertions.  disabling this in production will give a modest
# performance benefit (around 5%).
-ea

If assertions incur a "5% penalty" but are not always trapped what value
do
they add?

These are common sentiments about how assert should be used: (not trying
to
make this a this is what the internet says type debate)

http://stackoverflow.com/questions/2758224/what-does-
the-java-assert-keyword-do-and-when-should-it-be-used

"Assertions

(by
way of the *assert* keyword) were added in Java 1.4. They are used to
verify the correctness of an invariant in the code. They should never be
triggered in production code, and are indicative of a bug or misuse of a
code path. They can be activated at run-time by way of the -eaoption on
the
java command, but are not turned on by default."

http://stackoverflow.com/questions/1957645/when-to-use-
an-assertion-and-when-to-use-an-exception

"An assertion would stop the program from running, but an exception would
let the program continue running."

I look at how Cassandra uses assert and how it manifests in how the code
operates in production. Assert is something like semi-unchecked
exception.
All types of internal Util classes might throw it, downstream code is
essentially unaware and rarely specifically handles it. They do not
always
result in the hard death one would expect from an assert.

I know this is a ballpark type figure, but would "5% performance penalty"
be in the ballpark of a checked exception? Being that they tend to bubble
through things uncaught do they do more danger than good?

Re: Question on assert

[Edward Capriolo]

" potential 5% performance win when you've corrupted all their data."
This is somewhat of my point. Why do assertions that sometimes are trapped
"protect my data" better then a checked exception?

On Wed, Sep 21, 2016 at 1:24 PM, Michael Kjellman <
mkjell...@internalcircle.com> wrote:

> I hate that comment with a passion. Please please please please do
> yourself a favor and *always* run with asserts on. `-ea` for life. In
> practice I'd be surprised if you actually got a reliable 5% performance win
> and I doubt your customers will care about a potential 5% performance win
> when you've corrupted all their data.
>
> best,
> kjellman
>
> > On Sep 21, 2016, at 10:21 AM, Edward Capriolo 
> wrote:
> >
> > There are a variety of assert usages in the Cassandra. You can find
> several
> > tickets like mine.
> >
> > https://issues.apache.org/jira/browse/CASSANDRA-12643
> >
> > https://issues.apache.org/jira/browse/CASSANDRA-11537
> >
> > Just to prove that I am not the only one who runs into these:
> >
> > https://issues.apache.org/jira/browse/CASSANDRA-12484
> >
> > To paraphrase another ticket that I read today and can not find,
> > "The problem is X throws Assertion which is not caught by the Exception
> > handler and it bubbles over and creates a thread death."
> >
> > The jvm.properties file claims this:
> >
> > # enable assertions.  disabling this in production will give a modest
> > # performance benefit (around 5%).
> > -ea
> >
> > If assertions incur a "5% penalty" but are not always trapped what value
> do
> > they add?
> >
> > These are common sentiments about how assert should be used: (not trying
> to
> > make this a this is what the internet says type debate)
> >
> > http://stackoverflow.com/questions/2758224/what-does-
> the-java-assert-keyword-do-and-when-should-it-be-used
> >
> > "Assertions
> > 
> (by
> > way of the *assert* keyword) were added in Java 1.4. They are used to
> > verify the correctness of an invariant in the code. They should never be
> > triggered in production code, and are indicative of a bug or misuse of a
> > code path. They can be activated at run-time by way of the -eaoption on
> the
> > java command, but are not turned on by default."
> >
> > http://stackoverflow.com/questions/1957645/when-to-use-
> an-assertion-and-when-to-use-an-exception
> >
> > "An assertion would stop the program from running, but an exception would
> > let the program continue running."
> >
> > I look at how Cassandra uses assert and how it manifests in how the code
> > operates in production. Assert is something like semi-unchecked
> exception.
> > All types of internal Util classes might throw it, downstream code is
> > essentially unaware and rarely specifically handles it. They do not
> always
> > result in the hard death one would expect from an assert.
> >
> > I know this is a ballpark type figure, but would "5% performance penalty"
> > be in the ballpark of a checked exception? Being that they tend to bubble
> > through things uncaught do they do more danger than good?
>
>

Re: Question on assert

[Michael Kjellman]

I hate that comment with a passion. Please please please please do yourself a 
favor and *always* run with asserts on. `-ea` for life. In practice I'd be 
surprised if you actually got a reliable 5% performance win and I doubt your 
customers will care about a potential 5% performance win when you've corrupted 
all their data.

best,
kjellman

> On Sep 21, 2016, at 10:21 AM, Edward Capriolo  wrote:
> 
> There are a variety of assert usages in the Cassandra. You can find several
> tickets like mine.
> 
> https://issues.apache.org/jira/browse/CASSANDRA-12643
> 
> https://issues.apache.org/jira/browse/CASSANDRA-11537
> 
> Just to prove that I am not the only one who runs into these:
> 
> https://issues.apache.org/jira/browse/CASSANDRA-12484
> 
> To paraphrase another ticket that I read today and can not find,
> "The problem is X throws Assertion which is not caught by the Exception
> handler and it bubbles over and creates a thread death."
> 
> The jvm.properties file claims this:
> 
> # enable assertions.  disabling this in production will give a modest
> # performance benefit (around 5%).
> -ea
> 
> If assertions incur a "5% penalty" but are not always trapped what value do
> they add?
> 
> These are common sentiments about how assert should be used: (not trying to
> make this a this is what the internet says type debate)
> 
> http://stackoverflow.com/questions/2758224/what-does-the-java-assert-keyword-do-and-when-should-it-be-used
> 
> "Assertions
>  (by
> way of the *assert* keyword) were added in Java 1.4. They are used to
> verify the correctness of an invariant in the code. They should never be
> triggered in production code, and are indicative of a bug or misuse of a
> code path. They can be activated at run-time by way of the -eaoption on the
> java command, but are not turned on by default."
> 
> http://stackoverflow.com/questions/1957645/when-to-use-an-assertion-and-when-to-use-an-exception
> 
> "An assertion would stop the program from running, but an exception would
> let the program continue running."
> 
> I look at how Cassandra uses assert and how it manifests in how the code
> operates in production. Assert is something like semi-unchecked exception.
> All types of internal Util classes might throw it, downstream code is
> essentially unaware and rarely specifically handles it. They do not always
> result in the hard death one would expect from an assert.
> 
> I know this is a ballpark type figure, but would "5% performance penalty"
> be in the ballpark of a checked exception? Being that they tend to bubble
> through things uncaught do they do more danger than good?

Question on assert

[Edward Capriolo]

There are a variety of assert usages in the Cassandra. You can find several
tickets like mine.

https://issues.apache.org/jira/browse/CASSANDRA-12643

https://issues.apache.org/jira/browse/CASSANDRA-11537

Just to prove that I am not the only one who runs into these:

https://issues.apache.org/jira/browse/CASSANDRA-12484

To paraphrase another ticket that I read today and can not find,
"The problem is X throws Assertion which is not caught by the Exception
handler and it bubbles over and creates a thread death."

The jvm.properties file claims this:

# enable assertions.  disabling this in production will give a modest
# performance benefit (around 5%).
-ea

If assertions incur a "5% penalty" but are not always trapped what value do
they add?

These are common sentiments about how assert should be used: (not trying to
make this a this is what the internet says type debate)

http://stackoverflow.com/questions/2758224/what-does-the-java-assert-keyword-do-and-when-should-it-be-used

"Assertions
 (by
way of the *assert* keyword) were added in Java 1.4. They are used to
verify the correctness of an invariant in the code. They should never be
triggered in production code, and are indicative of a bug or misuse of a
code path. They can be activated at run-time by way of the -eaoption on the
java command, but are not turned on by default."

http://stackoverflow.com/questions/1957645/when-to-use-an-assertion-and-when-to-use-an-exception

"An assertion would stop the program from running, but an exception would
let the program continue running."

I look at how Cassandra uses assert and how it manifests in how the code
operates in production. Assert is something like semi-unchecked exception.
All types of internal Util classes might throw it, downstream code is
essentially unaware and rarely specifically handles it. They do not always
result in the hard death one would expect from an assert.

I know this is a ballpark type figure, but would "5% performance penalty"
be in the ballpark of a checked exception? Being that they tend to bubble
through things uncaught do they do more danger than good?