Re: [DISCUSSION] Cassandra-17515 - course of action

[David Capwell]

I am good with making >= 0 valid in both setters and config parsing, negatives 
should error or produce defaults

> On Apr 4, 2022, at 10:45 AM, Caleb Rackliffe  wrote:
> 
> I'm for making >= 0 valid in both the setters and on startup. In the setters, 
> I'm fine with either translating negative values to the default calculated 
> value based on heap size or simply rejecting negative values. If we really 
> want to override that value, we had better have a really good idea of why...
> 
> Given this has always been an advanced feature, I'm neutral on adding 
> anything to NEWS.txt.
> 
> On Mon, Apr 4, 2022 at 8:46 AM Ekaterina Dimitrova  > wrote:
> Hi everyone,
> While working on CASSANDRA-17431 to move the advanced Config parameters we 
> don't advertise in cassandra.yaml to the new types created in 
> CASSANDRA-15234, we ran into some concerns around 
> native_transport_max_concurrent_requests_in_bytes and 
> native_transport_max_concurrent_requests_in_bytes_per_ip.
> While on startup if those parameters are set to something <= 0, they will get 
> a default value, their setters are not guarded in the same way, we just set 
> any long value. 
> I checked and this is actually something going on all currently supported 
> Cassandra versions. From there Caleb raised the question that 0 actually can 
> be a valid value and the check needs to cover possibly only < 0.
> As these are advanced and non-documented parameters, I thought it is valuable 
> to confirm the course of action here. Especially, if we are willing to do a 
> change to all released versions. 
> So the proposal is to:
> 1) change the check on startup from <=0 to <0 and make 0 a valid value, for 
> all versions?
> 2) Add the same checks&assignment to the respective setters
> 3) Update NEWS.txt explicitly (this part is a bit weird to me as we keep it 
> not advertised in cassandra.yaml but we want whoever uses it to know about 
> such changes...)
> 
> Looking forward to your feedback, thanks in advance.
> 
> Best regards,
> Ekaterina

Re: [DISCUSSION] Cassandra-17515 - course of action

[Caleb Rackliffe]

I'm for making >= 0 valid in both the setters and on startup. In the
setters, I'm fine with either translating negative values to the default
calculated value based on heap size or simply rejecting negative values. If
we really want to override that value, we had better have a really good
idea of why...

Given this has always been an advanced feature, I'm neutral on adding
anything to NEWS.txt.

On Mon, Apr 4, 2022 at 8:46 AM Ekaterina Dimitrova 
wrote:

> Hi everyone,
> While working on CASSANDRA-17431 to move the advanced Config parameters we
> don't advertise in cassandra.yaml to the new types created in
> CASSANDRA-15234, we ran into some concerns around 
> native_transport_max_concurrent_requests_in_bytes
> and native_transport_max_concurrent_requests_in_bytes_per_ip.
> While on startup if those parameters are set to something <= 0, they will
> get a default value, their setters are not guarded in the same way, we just
> set any long value.
> I checked and this is actually something going on all currently supported
> Cassandra versions. From there Caleb raised the question that 0 actually
> can be a valid value and the check needs to cover possibly only < 0.
> As these are advanced and non-documented parameters, I thought it is
> valuable to confirm the course of action here. Especially, if we are
> willing to do a change to all released versions.
> So the proposal is to:
> 1) change the check on startup from <=0 to <0 and make 0 a valid value,
> for all versions?
> 2) Add the same checks&assignment to the respective setters
> 3) Update NEWS.txt explicitly (this part is a bit weird to me as we keep
> it not advertised in cassandra.yaml but we want whoever uses it to know
> about such changes...)
>
> Looking forward to your feedback, thanks in advance.
>
> Best regards,
> Ekaterina
>

Re: [DISCUSSION] Shall we update Constants.KEY_DTEST_API_CONFIG_CHECK to true by default for in-jvm upgrade tests?

[David Capwell]

I am cool with checking by default and disabling for tests that need it, it may 
also make more sense to add an allow list so tests can explicitly say which 
configs to ignore (though this sounds painful to implement).

> On Apr 4, 2022, at 9:11 AM, Jon Meredith  wrote:
> 
> I think checking the validation rules as part of testing is important, but 
> making that a per-test concern for handling it may be frustrating.
> 
> What do you think about extending in-JVM with a method that provides the 
> previous config and version and expects the Instance implementation to 
> upgrade it, and then leave the validation on? That would provide some 
> documentation of how deprecated/removed options are expected to be migrated.
> 
> It might also be worthwhile extending the upgrade tests so that we can also 
> specify new configuration in addition to migrated configurated as the 
> instance is upgraded.
> 
> On Mon, Apr 4, 2022 at 8:43 AM Ekaterina Dimitrova  > wrote:
> Hi everyone,
> In In-jvm tests there is a flag Constants.KEY_DTEST_API_CONFIG_CHECK to 
> opt-in/out from config checks done in YamlConfigurationLoader#check().
> The upgrade tests are currently set to ignore that check in order to work 
> around dealing with new properties in newer versions. What does this mean? My 
> understanding is that the lowest version from which we start an upgrade test 
> will load Config and use it for all versions. This means that our checks will 
> fail because in newer versions we set new config in InstanceConfig that 
> doesn't exist in the old version Config. If we opt in, the tests will start 
> failing because we need to remove parameters.  
> 
> I suggest we opt in by default to the checks so people consciously add their 
> config. What do I mean? Currently with the new types and names in trunk, we 
> exercise the backward compatibility and we set the old config names and 
> values that work with the previous versions and exercise the backward 
> compatibility but If I add a new name to set for config, this will just be 
> ignored silently and default Config is used. Test might even pass...This is 
> risky. 
> This was documented but I think the right course of action is to opt in for 
> checks and people ignore the checks in upgrade tests when they are sure they 
> add the right config and no typos, etc and they understand the implications. 
> The situation since that check was added has changed and if we keep on adding 
> more tests, I think this is important so we are sure we test properly.
> 
> Please let me know if I am wrong in my understanding and what you think. 
> 
> Best regards,
> Ekaterina

Re: [DISCUSSION] Shall we update Constants.KEY_DTEST_API_CONFIG_CHECK to true by default for in-jvm upgrade tests?

[Jon Meredith]

I think checking the validation rules as part of testing is important, but
making that a per-test concern for handling it may be frustrating.

What do you think about extending in-JVM with a method that provides the
previous config and version and expects the Instance implementation to
upgrade it, and then leave the validation on? That would provide some
documentation of how deprecated/removed options are expected to be migrated.

It might also be worthwhile extending the upgrade tests so that we can also
specify new configuration in addition to migrated configurated as the
instance is upgraded.

On Mon, Apr 4, 2022 at 8:43 AM Ekaterina Dimitrova 
wrote:

> Hi everyone,
> In In-jvm tests there is a flag Constants.KEY_DTEST_API_CONFIG_CHECK to
> opt-in/out from config checks done in YamlConfigurationLoader#check().
> The upgrade tests are currently set to ignore that check in order to work
> around dealing with new properties in newer versions. What does this mean?
> My understanding is that the lowest version from which we start an upgrade
> test will load Config and use it for all versions. This means that our
> checks will fail because in newer versions we set new config in
> InstanceConfig that doesn't exist in the old version Config. If we opt in,
> the tests will start failing because we need to remove parameters.
>
> I suggest we opt in by default to the checks so people consciously add
> their config. What do I mean? Currently with the new types and names in
> trunk, we exercise the backward compatibility and we set the old config
> names and values that work with the previous versions and exercise the
> backward compatibility but If I add a new name to set for config, this will
> just be ignored silently and default Config is used. Test might even
> pass...This is risky.
> This was documented but I think the right course of action is to opt in
> for checks and people ignore the checks in upgrade tests when they are sure
> they add the right config and no typos, etc and they understand the
> implications. The situation since that check was added has changed and if
> we keep on adding more tests, I think this is important so we are sure we
> test properly.
>
> Please let me know if I am wrong in my understanding and what you think.
>
> Best regards,
> Ekaterina
>

Re: UDF: adding custom jar to classpath

[Sébastien Rebecchi]

Hi!
Do you have any more ideas for me?
Cordially,
Sébastien.

Le lun. 28 mars 2022 à 16:39, Sébastien Rebecchi 
a écrit :

> Unfortunately, it is not working even with
> "enable_user_defined_functions_threads: false" in cassandra.yaml :/
> Is there any way to check the running configuration?
>
> Le lun. 28 mars 2022 à 15:35, Benjamin Lerer  a écrit :
>
>> I do not think that allowing to customize UDF classes whitelist has been
>> discussed before. Feel free to open a JIRA ticket :-)
>> I have some plans to revisit how we securise UDFs as the current
>> threading approach has some impact in terms of latency. That can be a good
>> opportunity to look into providing more flexibility.
>>
>> Le lun. 28 mars 2022 à 15:00, Sébastien Rebecchi 
>> a écrit :
>>
>>> Thanks you very much! I will try that.
>>> As you know, would it be a long-terms solution? Or is there any plan to
>>> add the possibility to customize UDF classes whitelist?
>>>
>>> Le lun. 28 mars 2022 à 14:31, Benjamin Lerer  a
>>> écrit :
>>>
 Is there a way to customize that default behaviour?


 Looking at JavaBasedUDFunction quickly it seems that the ClassLoader
 is only used when you use the UDFExecutorService to execute your UDFs.
 You can try to disable it using "enable_user_defined_functions_threads:
 false" and see if it works.
 Now that also means that you have to ensure that only trusted persons
 can create UDF or UDA as it removes all safety mechanisms.

 Le lun. 28 mars 2022 à 13:23, Sébastien Rebecchi <
 srebec...@kameleoon.com> a écrit :

> Hi Benjamin,
>
> Thanks for the answer.
> Is there a way to customize that default behaviour? If no, could you
> indicate where to find this class loader in the github of Cassandra 
> please?
>
> Le lun. 28 mars 2022 à 12:40, Benjamin Lerer  a
> écrit :
>
>> Hi Sébastien,
>>
>> Cassandra uses a special classloader for UDFs that limit which
>> classes can be used.
>> You cannot rely on non-JDK classes for UDFs and some of the JDK
>> packages like the IO package for example cannot be used.
>> The goal is simply to ensure that UDFs cannot compromise the server
>> security.
>>
>> Le lun. 28 mars 2022 à 11:31, Sébastien Rebecchi <
>> srebec...@kameleoon.com> a écrit :
>>
>>> Hello,
>>>
>>> I am trying to create a UDF based on custom methods.
>>> So I set enable_user_defined_functions to true and added a jar in
>>> "/usr/share/cassandra/lib/" folder on every node, restarted the nodes 
>>> and I
>>> can see from the command line that the jar is indeed used (in the 
>>> classpath
>>> with -cp).
>>>
>>> But when i create the UDF I got that error:
>>>
>>> CREATE OR REPLACE FUNCTION blobToJson (input blob) RETURNS NULL ON
>>> NULL INPUT RETURNS text LANGUAGE java AS 'return
>>> com.kameleoon.visit.Visit.writeToJson(com.kameleoon.visit.Visit.readFromByteBuffer(input));';
>>> InvalidRequest: Error from server: code=2200 [Invalid query]
>>> message="Java source compilation failed:
>>> Line 1: com.kameleoon.visit.Visit cannot be resolved to a type
>>> Line 1: com.kameleoon.visit.Visit cannot be resolved to a type
>>>
>>> Of course the class com.kameleoon.visit.Visit does exist in the jar
>>> and the jar has read rights to every user (chmod 444). So I can not find
>>> the reason.
>>>
>>> versions are: [cqlsh 6.0.0 | Cassandra 4.0.1 | CQL spec 3.4.5 |
>>> Native protocol v5]
>>>
>>> Any help would be appreciated!
>>>
>>> Thanks!
>>>
>>> Sébastien.
>>>
>>

[DISCUSSION] Shall we update Constants.KEY_DTEST_API_CONFIG_CHECK to true by default for in-jvm upgrade tests?

[Ekaterina Dimitrova]

Hi everyone,
In In-jvm tests there is a flag Constants.KEY_DTEST_API_CONFIG_CHECK to
opt-in/out from config checks done in YamlConfigurationLoader#check().
The upgrade tests are currently set to ignore that check in order to work
around dealing with new properties in newer versions. What does this mean?
My understanding is that the lowest version from which we start an upgrade
test will load Config and use it for all versions. This means that our
checks will fail because in newer versions we set new config in
InstanceConfig that doesn't exist in the old version Config. If we opt in,
the tests will start failing because we need to remove parameters.

I suggest we opt in by default to the checks so people consciously add
their config. What do I mean? Currently with the new types and names in
trunk, we exercise the backward compatibility and we set the old config
names and values that work with the previous versions and exercise the
backward compatibility but If I add a new name to set for config, this will
just be ignored silently and default Config is used. Test might even
pass...This is risky.
This was documented but I think the right course of action is to opt in for
checks and people ignore the checks in upgrade tests when they are sure
they add the right config and no typos, etc and they understand the
implications. The situation since that check was added has changed and if
we keep on adding more tests, I think this is important so we are sure we
test properly.

Please let me know if I am wrong in my understanding and what you think.

Best regards,
Ekaterina

[DISCUSSION] Cassandra-17515 - course of action

[Ekaterina Dimitrova]

Hi everyone,
While working on CASSANDRA-17431 to move the advanced Config parameters we
don't advertise in cassandra.yaml to the new types created in
CASSANDRA-15234, we ran into some concerns around
native_transport_max_concurrent_requests_in_bytes
and native_transport_max_concurrent_requests_in_bytes_per_ip.
While on startup if those parameters are set to something <= 0, they will
get a default value, their setters are not guarded in the same way, we just
set any long value.
I checked and this is actually something going on all currently supported
Cassandra versions. From there Caleb raised the question that 0 actually
can be a valid value and the check needs to cover possibly only < 0.
As these are advanced and non-documented parameters, I thought it is
valuable to confirm the course of action here. Especially, if we are
willing to do a change to all released versions.
So the proposal is to:
1) change the check on startup from <=0 to <0 and make 0 a valid value, for
all versions?
2) Add the same checks&assignment to the respective setters
3) Update NEWS.txt explicitly (this part is a bit weird to me as we keep it
not advertised in cassandra.yaml but we want whoever uses it to know about
such changes...)

Looking forward to your feedback, thanks in advance.

Best regards,
Ekaterina

Re: Call for Volunteers - Build Lead

[Mick Semb Wever]

We went last week without a Build Lead. We have one for this week, but we
are looking for volunteers for next week and the weeks ahead.

This is an important activity to get us to green - once we are green it
opens new possibilities for us.
So please sign up :-)



On Fri, 25 Mar 2022 at 19:50, Andrés de la Peña 
wrote:

> Hi all,
>
> 9 people have already participated on the Build Lead rotation, now we need
> a brave volunteer for the next week.
>
> Thanks for your help,
>
> On Wed, 2 Mar 2022 at 17:10, Ekaterina Dimitrova 
> wrote:
>
>> Hi everyone,
>>
>> It's been a month and a half since we started the Build Lead rotation.
>> 6 people already participated. (Thank you!) Most failures in Butler have
>> respective tickets linked to them, many tickets were even already closed.
>>
>> This email is to remind you about this initiative. Don't be shy to
>> volunteer participation in the rotation. :-) Josh and Brandon did the heavy
>> lifting with opening the most tickets during  the first two weeks so now
>> primarily brand new failures need attention. Also, I should acknowledge
>> that many people worked on failures, thank you for doing it!
>>
>> Feel free to add yourself to the rotation schedule here -
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199527692
>> We don't have any names populated after this week.
>>
>> Thank you in advance for all your help!
>>
>> Ekaterina Dimitrova
>>
>>
>>

Re: [DISCUSS] Next release cut

[Mick Semb Wever]

> * Freeze cassandra-4.1 on may 1st
>


A feature freeze on the release branch is always implied.

And repeating, because it bugs me (and I just need to air it): we're
talking about this because we have not achieved a stable trunk this dev
cycle.

The 4.0 branch has remained very close, but trunk not so. Reporting (with
the help of Butler) and the Build Lead role has made significant
improvements, and if you look through the tests reported as flakey in
trunk, many cannot be blamed on the infrastructure problems or higher
saturation levels of ci-cassandra.a.o (a higher rate of flakey still means
they're flakey).

I hope this helps reinforce and remind us about our efforts to get to a
green CI. This includes both CI systems and all tests that run on each.

Re: [DISCUSS] List Apache Cassandra as a "company" on LinkedIn

[Benjamin Lerer]

I created a company page for Apache Cassandra with the same admin as the
group.
I will update the page over the coming days to give it a nicer look. :-)

Le mer. 30 mars 2022 à 23:46, Patrick McFadin  a écrit :

> Oh and +1 to the idea of making Apache Cassandra a company on LinkedIn.
> Same energy as the Twitter handle. Outgoing updates from the project.
>
> On Wed, Mar 30, 2022 at 2:41 PM Patrick McFadin 
> wrote:
>
>> I agree that is a problem. In the past, I have tried to make these as
>> inclusive as possible by offering multiple time zones, recording every
>> meeting, and posting it on YouTube with an email sent to dev@. What we
>> can't substitute in a mailing list is the energy that comes from
>> brainstorming, which is kind of a feature of people interested in this sort
>> of thing for the project. Just like meeting once or twice a year at
>> ApacheCon. It's part of an overall package of community vibrancy and none
>> of it is exclusive.
>>
>> One thing that occurred to me is that everything is getting dumped on dev@.
>> Is it time for a marketing@ list for Cassandra?
>>
>> Patrick
>>
>> On Wed, Mar 30, 2022 at 12:00 PM Eric Evans  wrote:
>>
>>>
>>>
>>> On Wed, Mar 30, 2022 at 3:35 AM Benjamin Lerer 
>>> wrote:
>>>
 Thank Erick for raising the discussion.
 My apologies for not responding before. The original thread raised
 several questions for me and I needed time to think about them.
 One question is the Linkedin Company vs Group one. I must admit that it
 makes sense but the whole story made me realize my lack of understanding of
 how Linkedin works and wanted to explore that more deeply than I did before
 creating the group.
 Another thing that the thread made me realize is that there are several
 people interested in being involved in C* marketing/Public Relations and
 that we probably need to do the things in a more mature and open way.
 Partick and I would like to organize a contributor meeting focused on
 Apache Cassandra marketing to give a chance to everybody to join and
 discuss how we could do things better if people are interested.
 I feel that it would help us to evolve in this area

>>>
>>> Please bear in mind that contributor meetings like these are exclusive
>>> by nature; There is no time suitable for every timezone, not everyone has
>>> equal connectivity, and those who don't natively speak English might
>>> struggle to keep pace in real time (to name just a few reasons).  This is
>>> probably why the ASF is so adamant about the use of email.
>>>
>>> --
>>> Eric Evans
>>> eev...@apache.org
>>>
>>

Re: [GitHub] [cassandra-website] ossarga commented on a diff in pull request #121: move and prepare files for content folder

[bened...@apache.org]

I just did the same for cassandra-accord, I guess some config was lost in the 
upgrade

https://issues.apache.org/jira/projects/INFRA/issues/INFRA-23074


From: Mick Semb Wever 
Date: Monday, 4 April 2022 at 08:55
To: dev@cassandra.apache.org 
Subject: Re: [GitHub] [cassandra-website] ossarga commented on a diff in pull 
request #121: move and prepare files for content folder

these notifications should be going to pr@

have created https://issues.apache.org/jira/browse/INFRA-23073

On Mon, 4 Apr 2022 at 03:09, GitBox mailto:g...@apache.org>> 
wrote:

ossarga commented on code in PR #121:
URL: https://github.com/apache/cassandra-website/pull/121#discussion_r841307662


##
site-content/docker-entrypoint.sh:
##
@@ -196,14 +196,87 @@ generate_site_yaml() {

 render_site_content_to_html() {
   pushd "${CASSANDRA_WEBSITE_DIR}/site-content" > /dev/null
-  echo "Building the site HTML content."
+  log_message "INFO" "Building the site HTML content."
   antora --generator antora-site-generator-lunr site.yaml
-  echo "Rendering complete!"
+  log_message "INFO" "Rendering complete!"
   popd > /dev/null
 }

+
+prepare_site_html_for_publication() {
+  pushd "${CASSANDRA_WEBSITE_DIR}" > /dev/null
+
+  # copy everything to content/ directory
+  log_message "INFO" "Moving site HTML to content/"
+  mkdir -p content/doc
+  cp -r site-content/build/html/* content/
+
+  # remove hardcoded domain name, and empty domain names first before we 
duplicate and documentation
+  content_files_to_change=($(grep -rl 'https://cassandra.apache.org/' 
content/))
+  log_message "INFO" "Removing hardcoded domain names in 
${#content_files_to_change[*]} files"
+  for content_file in ${content_files_to_change[*]}
+  do
+log_message "DEBUG" "Processing file ${content_file}"
+# sed automatically uses the character following the 's' as a delimiter.
+# In this case we will use the ',' so we can avoid the need to escape the 
'/' characters
+sed -i 's,https://cassandra.apache.org/,/,g' ${content_file}
+  done
+
+  content_files_to_change=($(grep -rl 'href="//' content/))
+  log_message "INFO" "Removing empty domain names in 
${#content_files_to_change[*]} files"
+  for content_file in ${content_files_to_change[*]}
+  do
+log_message "DEBUG" "Processing file ${content_file}"
+sed -i 's,href="//,href="/,g' ${content_file}
+  done
+
+  # move around the in-tree docs if generated
+  if [ "${COMMAND_GENERATE_DOCS}" = "run" ]
+  then
+log_message "INFO" "Moving versioned documentation HTML to content/doc"
+move_intree_document_directories "3.11" "3.11.11" "3.11.12"
+move_intree_document_directories "4.0" "4.0.0" "4.0.1" "4.0.2" "4.0.3" 
"stable"
+move_intree_document_directories "trunk" "4.1" "latest"

Review Comment:
   Agreed. I have been thinking about this for some time. It will be addressed 
in [CASSANDRA-17517](https://issues.apache.org/jira/browse/CASSANDRA-17517).



--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: 
dev-unsubscr...@cassandra.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [GitHub] [cassandra-website] ossarga commented on a diff in pull request #121: move and prepare files for content folder

[Mick Semb Wever]

these notifications should be going to pr@

have created https://issues.apache.org/jira/browse/INFRA-23073

On Mon, 4 Apr 2022 at 03:09, GitBox  wrote:

>
> ossarga commented on code in PR #121:
> URL:
> https://github.com/apache/cassandra-website/pull/121#discussion_r841307662
>
>
> ##
> site-content/docker-entrypoint.sh:
> ##
> @@ -196,14 +196,87 @@ generate_site_yaml() {
>
>  render_site_content_to_html() {
>pushd "${CASSANDRA_WEBSITE_DIR}/site-content" > /dev/null
> -  echo "Building the site HTML content."
> +  log_message "INFO" "Building the site HTML content."
>antora --generator antora-site-generator-lunr site.yaml
> -  echo "Rendering complete!"
> +  log_message "INFO" "Rendering complete!"
>popd > /dev/null
>  }
>
> +
> +prepare_site_html_for_publication() {
> +  pushd "${CASSANDRA_WEBSITE_DIR}" > /dev/null
> +
> +  # copy everything to content/ directory
> +  log_message "INFO" "Moving site HTML to content/"
> +  mkdir -p content/doc
> +  cp -r site-content/build/html/* content/
> +
> +  # remove hardcoded domain name, and empty domain names first before we
> duplicate and documentation
> +  content_files_to_change=($(grep -rl 'https://cassandra.apache.org/'
> content/))
> +  log_message "INFO" "Removing hardcoded domain names in
> ${#content_files_to_change[*]} files"
> +  for content_file in ${content_files_to_change[*]}
> +  do
> +log_message "DEBUG" "Processing file ${content_file}"
> +# sed automatically uses the character following the 's' as a
> delimiter.
> +# In this case we will use the ',' so we can avoid the need to escape
> the '/' characters
> +sed -i 's,https://cassandra.apache.org/,/,g' ${content_file}
> +  done
> +
> +  content_files_to_change=($(grep -rl 'href="//' content/))
> +  log_message "INFO" "Removing empty domain names in
> ${#content_files_to_change[*]} files"
> +  for content_file in ${content_files_to_change[*]}
> +  do
> +log_message "DEBUG" "Processing file ${content_file}"
> +sed -i 's,href="//,href="/,g' ${content_file}
> +  done
> +
> +  # move around the in-tree docs if generated
> +  if [ "${COMMAND_GENERATE_DOCS}" = "run" ]
> +  then
> +log_message "INFO" "Moving versioned documentation HTML to
> content/doc"
> +move_intree_document_directories "3.11" "3.11.11" "3.11.12"
> +move_intree_document_directories "4.0" "4.0.0" "4.0.1" "4.0.2"
> "4.0.3" "stable"
> +move_intree_document_directories "trunk" "4.1" "latest"
>
> Review Comment:
>Agreed. I have been thinking about this for some time. It will be
> addressed in [CASSANDRA-17517](
> https://issues.apache.org/jira/browse/CASSANDRA-17517).
>
>
>
> --
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
>
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
>
>

[GitHub] [cassandra-accord] belliottsmith commented on a diff in pull request #2: Initial Cassandra integration

[GitBox]

belliottsmith commented on code in PR #2:
URL: https://github.com/apache/cassandra-accord/pull/2#discussion_r841458215


##
accord-core/src/main/java/accord/local/CommandStore.java:
##
@@ -228,7 +228,7 @@ public void processBlocking(Consumer 
consumer)
 }
 catch (InterruptedException e)
 {
-Thread.currentThread().interrupt();
+throw new AssertionError(e);

Review Comment:
   would be nice to have `UncheckedInterruptedException` here...



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org