from:"Steinmaurer, Thomas"

RE: Recent log4j vulnerability

2021-12-14 Thread Steinmaurer, Thomas

Would 3.11 be considered as well? This would also then keep (stupid/static) sec 
scans silent in regard to https://nvd.nist.gov/vuln/detail/CVE-2017-5929

Thanks

-Original Message-
From: J. D. Jordan 
Sent: Dienstag, 14. Dezember 2021 16:27
To: dev@cassandra.apache.org
Subject: Re: Recent log4j vulnerability

Doesn’t hurt to upgrade. But no exploit there as far as I can see?  If someone 
can update your config files to point them to JNDI, you have worse problems 
than that.  Like they can probably update your config files to just completely 
open up JMX access or what ever also.

> On Dec 14, 2021, at 9:17 AM, Brandon Williams  wrote:
>
> The POC seems to require the attacker be able to upload a file that
> overwrites the configuration, with hot reloading enabled.  We do have
> hot reloading enabled but there's no inherent way to overwrite the
> config.
>
> That said with logback currently at 1.2.3 (in trunk), perhaps we
> should consider an upgrade for safety.
>
>> On Tue, Dec 14, 2021 at 8:50 AM Steinmaurer, Thomas
>>  wrote:
>>
>> Any thoughts what the logback folks have been filed here?
>> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjir
>> a.qos.ch%2Fbrowse%2FLOGBACK-1591data=04%7C01%7Cthomas.steinmaure
>> r%40dynatrace.com%7C3c8fc229b1ae41d67d3908d9bf177d1a%7C70ebe3a35b3043
>> 5d9d677716d74ca190%7C1%7C0%7C637750929883113638%7CUnknown%7CTWFpbGZsb
>> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
>> %7C3000sdata=Y2uKdA2lBJui3eOgv6NxDsA4P3knHmQnKDQfHbJXjPY%3D
>> reserved=0
>>
>> Thanks!
>>
>> -Original Message-
>> From: Brandon Williams 
>> Sent: Sonntag, 12. Dezember 2021 18:56
>> To: dev@cassandra.apache.org
>> Subject: Recent log4j vulnerability
>>
>> I replied to a user- post about this, but thought it was worth repeating it 
>> here.
>>
>> In 
>> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCASSANDRA-5883data=04%7C01%7Cthomas.steinmaurer%40dynatrace.com%7C3c8fc229b1ae41d67d3908d9bf177d1a%7C70ebe3a35b30435d9d677716d74ca190%7C1%7C0%7C637750929883113638%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=xNXgCyJwyqNmNQ375upcg5JK4cv%2F6up25btbVyqxqp8%3Dreserved=0
>>  you can see where Apache Cassandra never chose to use log4j2 (preferring 
>> logback instead), and thus is not, and has never been, vulnerable to this 
>> RCE.
>>
>> Kind Regards,
>> Brandon
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>
>> This email may contain confidential information. If it appears this message 
>> was sent to you by mistake, please let us know of the error. In this case, 
>> we also ask that you do not further forward the content and delete it. Thank 
>> you for your cooperation and understanding. Dynatrace Austria GmbH 
>> (registration number FN 91482h) is a company registered in Linz whose 
>> registered office is at 4020 Linz, Austria, Am Fünfundzwanziger Turm 20.
>>
>> -
>> 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

This email may contain confidential information. If it appears this message was 
sent to you by mistake, please let us know of the error. In this case, we also 
ask that you do not further forward the content and delete it. Thank you for 
your cooperation and understanding. Dynatrace Austria GmbH (registration number 
FN 91482h) is a company registered in Linz whose registered office is at 4020 
Linz, Austria, Am Fünfundzwanziger Turm 20.

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

RE: Recent log4j vulnerability

2021-12-14 Thread Steinmaurer, Thomas

Any thoughts what the logback folks have been filed here?
https://jira.qos.ch/browse/LOGBACK-1591

Thanks!

-Original Message-
From: Brandon Williams 
Sent: Sonntag, 12. Dezember 2021 18:56
To: dev@cassandra.apache.org
Subject: Recent log4j vulnerability

I replied to a user- post about this, but thought it was worth repeating it 
here.

In 
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCASSANDRA-5883data=04%7C01%7Cthomas.steinmaurer%40dynatrace.com%7C8016a1aeed8c4589cbe408d9bd9a0920%7C70ebe3a35b30435d9d677716d74ca190%7C1%7C0%7C637749291586596208%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=0klDN4WmFkt876OCsXL%2FX%2FUXa%2FrsxmwCKFgmnP4Lctw%3Dreserved=0
 you can see where Apache Cassandra never chose to use log4j2 (preferring 
logback instead), and thus is not, and has never been, vulnerable to this RCE.

Kind Regards,
Brandon

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

This email may contain confidential information. If it appears this message was 
sent to you by mistake, please let us know of the error. In this case, we also 
ask that you do not further forward the content and delete it. Thank you for 
your cooperation and understanding. Dynatrace Austria GmbH (registration number 
FN 91482h) is a company registered in Linz whose registered office is at 4020 
Linz, Austria, Am Fünfundzwanziger Turm 20.

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

RE: [DISCUSS] Java support roadmap

2021-08-31 Thread Steinmaurer, Thomas

Good to hear that discussion moves forward in this regard! Java11 got quite 
some improvements in G1, especially for mixed collections.

Are there any plans to allow 3.11 running with Java 11 as well? We are 
currently on Cassandra 3.11 and it’s the only Java process in our deployment 
stack which requires Java 8, thus we need to ship two JRE versions.

Thanks,
Thomas



-Original Message-
From: Ekaterina Dimitrova 
Sent: Donnerstag, 26. August 2021 16:35
To: dev@cassandra.apache.org
Subject: [DISCUSS] Java support roadmap

Hi everyone,
I had a few people asking me recently about the Java 11 support.
I came across this thread we had last year -
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread.html%2Fr38f6beaa22e247cb38212f476f5f79efdc6587f83af0397406c06d7c%2540%253Cdev.cassandra.apache.org%253Edata=04%7C01%7Cthomas.steinmaurer%40dynatrace.com%7Cb993ecb1e58f43bb64b908d9689f8db2%7C70ebe3a35b30435d9d677716d74ca190%7C1%7C0%7C637655856882625326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=mtFTn45In8LwXVLRU%2FRG8k5q66E1Ut3iGtBw5%2FJiYt8%3Dreserved=0
.
I think we have all tests running in both Java 8 and Java 11 for trunk and
cassandra-4.0 in both Jenkins and CircleCI.
Does anyone know about any Java 11 specific bugs discovered? I personally 
haven't heard of any in the past year. What is the plan of the community for 
moving Java 11 support out of experimental?
Also, Java 17 LTS GA is planned for Sepember 2021 and I can try to test it with 
trunk.
Any thoughts?
Last but not least, do we know  anyone running Java 11 in production?
This thread was really opened as a stage to share our thoughts and hopefully 
come up with a plan as a community.

Looking forward to seeing what people think here.

Thank you,
Ekaterina
This email may contain confidential information. If it appears this message was 
sent to you by mistake, please let us know of the error. In this case, we also 
ask that you do not further forward the content and delete it. Thank you for 
your cooperation and understanding. Dynatrace Austria GmbH (registration number 
FN 91482h) is a company registered in Linz whose registered office is at 4020 
Linz, Austria, Am Fünfundzwanziger Turm 20.

RE: Enable running Cassandra 3.11 on Java 11

2021-06-21 Thread Steinmaurer, Thomas

Java 11 support in Cassandra 3.11 would be fantastic. Is this something the 
Cassandra project will follow-up or is this a dead-end in favor of Cassandra 
4.0, although Java 11 is marked as "experimental" there. Not sure what this 
means for production usage. 

Thanks,
Thomas


-Original Message-
From: Kornel Pal 
Sent: Sonntag, 23. Mai 2021 20:45
To: dev@cassandra.apache.org
Subject: Enable running Cassandra 3.11 on Java 11

Hi,

As an experiment, I tried to backport part of CASSANDRA-9608 and 
CASSANDRA-14607 that are needed to run Cassandra 3.11 on Java 11. For the most 
part it was quite straightforward; the results are available at 
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fcassandra%2Fcompare%2Fcassandra-3.11...kornelpal%3Acassandra-3.11-java11data=04%7C01%7Cthomas.steinmaurer%40dynatrace.com%7C906d5dac19614ee93a2308d91e1ba1c5%7C70ebe3a35b30435d9d677716d74ca190%7C1%7C0%7C637573926313720862%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=mCCV2zkph7Wc36oX3HnDGvZ%2FlZI3%2BAVuEuEhasvA%2Bxg%3Dreserved=0

To minimize the scope and risk, I only backported code changes needed to run on 
Java 11, not changes needed to compile on Java 11. I also did not update 
library versions and did not backport the script and config changes. Those 
might be higher risk, and Cassandra administrators should be able to manually 
replace library binaries and apply config changes from 4.0 for Java 11 support.

Both "ant test" and "ant long-test" had the same results with and without the 
changes on Java 8 that is very promising.

AtomicBTreePartition was somewhat challenging; CASSANDRA-14607 replaced all the 
relevant changes made in CASSANDRA-9608 and CASSANDRA-15367 has a 4.0 specific 
version. I changed CommitLogReader - that is not present in 4.0 - to use 
FileUtils.createTempFile for consistency. I did not apply the UFSecurityTest 
changes as those were failing, probably because are dependent on a newer 
library version.

I believe that these changes could enable Cassandra 3.11 to run on modern Java 
versions with reasonable effort and with no code changes, while also would 
bring the shared code base closer to 4.0 that would reduce the risk and 
complexity of future code changes on the 3.11 branch.

Could you please comment on whether this or a similar change could be accepted 
to the mainline Cassandra 3.11 source code.

Thank you,
Kornel

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

This email may contain confidential information. If it appears this message was 
sent to you by mistake, please let us know of the error. In this case, we also 
ask that you do not further forward the content and delete it. Thank you for 
your cooperation and understanding. Dynatrace Austria GmbH (registration number 
FN 91482h) is a company registered in Linz whose registered office is at 4020 
Linz, Austria, Am Fünfundzwanziger Turm 20.

RE: Next round of releases…

2020-01-28 Thread Steinmaurer, Thomas

I think there is also an issue with 3.0.19+ which prevents starting up 
Cassandra on Windows at all, thus ideally some sort of fix in that area would 
be nice to be included as well.

Regards,
Thomas

-Original Message-
From: Mick Semb Wever 
Sent: Dienstag, 28. Jänner 2020 07:40
To: dev@cassandra.apache.org
Subject: Next round of releases…


Jeff brought up yesterday on #cassandra-dev the need for a round of releases, 
because of CASSANDRA-15400.

Does anyone object, or knows of anything in the works that needs to go into the 
next releases of 2.2, 3.0, 3.11, or trunk?

regards,
Mick

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

The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a 
company registered in Linz whose registered office is at 4020 Linz, Austria, Am 
Fünfundzwanziger Turm 20


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

Cassandra 3.0.20 ETA?

2019-12-16 Thread Steinmaurer, Thomas

Hello,

as we are periodically hit in production by the following memory leak with 
3.0.18: https://issues.apache.org/jira/browse/CASSANDRA-15400

Is there any ETA for 3.0.20?

Thanks,
Thomas
The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a 
company registered in Linz whose registered office is at 4020 Linz, Austria, Am 
F?nfundzwanziger Turm 20

Cassandra 4.0 on Windows 10 crashing upon startup with Java 11

2018-11-12 Thread Steinmaurer, Thomas

Hello,

on Windows 10, Cassandra 4.0 (trunk Nov 12) is crashing upon startup with Java 
11, SIGAR related. Startup with Java8 works fine. Is this a known issue?

First part of the hs_err_pid file.

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x10014ed4, pid=14472, 
tid=13316
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13, mixed mode, tiered, compressed 
oops, concurrent mark sweep gc, windows-amd64)
# Problematic frame:
# C  [sigar-amd64-winnt.dll+0x14ed4]
#
# No core dump will be written. Minidumps are not enabled by default on client 
versions of Windows
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---  S U M M A R Y 

...

Host: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 4 cores, 15G,  Windows 10 , 64 
bit Build 14393 (10.0.14393.2189)
Time: Mon Nov 12 10:49:20 2018 W. Europe Standard Time elapsed time: 9 seconds 
(0d 0h 0m 9s)

---  T H R E A D  ---

Current thread (0x0239eed02ad0):  JavaThread "main" [_thread_in_native, 
id=13316, stack(0x00a44790,0x00a44794)]

Stack: [0x00a44790,0x00a44794],  sp=0x00a44793e170,  free 
space=248k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [sigar-amd64-winnt.dll+0x14ed4]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  
org.hyperic.sigar.Sigar.getFileSystemListNative()[Lorg/hyperic/sigar/FileSystem;+0
j  org.hyperic.sigar.Sigar.getFileSystemList()[Lorg/hyperic/sigar/FileSystem;+1
j  
org.hyperic.sigar.Sigar.getFileSystemMap()Lorg/hyperic/sigar/FileSystemMap;+19
j  org.apache.cassandra.utils.SigarLibrary.()V+79
j  org.apache.cassandra.utils.SigarLibrary.()V+4
v  ~StubRoutines::call_stub
j  org.apache.cassandra.service.StartupChecks$7.execute()V+0
j  org.apache.cassandra.service.StartupChecks.verify()V+30
j  org.apache.cassandra.service.CassandraDaemon.setup()V+41
j  org.apache.cassandra.service.CassandraDaemon.activate()V+70
j  org.apache.cassandra.service.CassandraDaemon.main([Ljava/lang/String;)V+3
v  ~StubRoutines::call_stub

siginfo: EXCEPTION_ACCESS_VIOLATION (0xc005), reading address 
0xff701d78

Register to memory mapping:

RIP=0x10014ed4 sigar-amd64-winnt.dll
RAX=0xff701c40 is an unknown value
RBX={method} {0x0239ff927e00} 'getFileSystemListNative' 
'()[Lorg/hyperic/sigar/FileSystem;' in 'org/hyperic/sigar/Sigar'
RCX=0x0239eed02e10 points into unknown readable memory
RDX=0x00a44793e358 is pointing into the stack for thread: 0x0239eed02ad0
RSP=0x00a44793e170 is pointing into the stack for thread: 0x0239eed02ad0
RBP=0x00a44793e338 is pointing into the stack for thread: 0x0239eed02ad0
RSI=0x0239fb2b6400 is pointing into metadata
RDI=0x0017e6e0 is an unknown value
R8 =0x0032 is an unknown value
R9 =
[error occurred during error reporting (printing register info), id 0xc005, 
EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x7ff908551e26]

The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a 
company registered in Linz whose registered office is at 4040 Linz, Austria, 
Freist?dterstra?e 313

RE: Cassandra 4.0 (Trunk) - "ant artifacts" does not create binary tarball

2018-11-12 Thread Steinmaurer, Thomas

Marcus,

that did the trick. Thx a lot.

T.

> -Original Message-
> From: Marcus Eriksson 
> Sent: Montag, 12. November 2018 10:31
> To: dev@cassandra.apache.org
> Subject: Re: Cassandra 4.0 (Trunk) - "ant artifacts" does not create binary
> tarball
>
> In trunk you need to provide JAVA_HOME to both java8 and java11, like this
> for example;
>
> $ JAVA8_HOME= JAVA_HOME= ant artifacts
>
> /Marcus
>
> On Mon, Nov 12, 2018 at 09:21:10AM +, Steinmaurer, Thomas wrote:
> > Hello,
> >
> > I'm trying to start with some first C* 4.0 experiments, thus tried to 
> > locally
> build and create binary tarball artifcats. While this has worked e.g. with 
> 3.11, I
> can't create a binary tarball for 4.0 anymore.
> >
> > What I did locally:
> > * Switched from branch cassandra-3.11 to trunk
> > * ant realclean
> > * ant artifacts
> >
> > I get the apache-cassandra-4.0-SNAPSHOT.jar created but no binary tarball.
> >
> > End of "ant artifacts" console output is:
> >
> >   [javadoc]  * the compaction strategy placement reflect most up-to-date
> disk boundaries, call {@link this#maybeReloadDiskBoundaries()}
> >   [javadoc] 
> >^
> >   [javadoc] Building index for all the packages and classes...
> >   [javadoc] Building index for all classes...
> >   [javadoc] Generating C:\workspaces\git\cassandra\build\javadoc\help-
> doc.html...
> >   [javadoc] 92 errors
> >   [javadoc] 100 warnings
> >
> > gen-doc:
> >  [exec]
> >  [exec] The 'sphinx-build' command was not found. Make sure you have
> Sphinx
> >  [exec] installed, then set the SPHINXBUILD environment variable to
> point
> >  [exec] to the full path of the 'sphinx-build' executable. 
> > Alternatively you
> >  [exec] may add the Sphinx directory to PATH.
> >  [exec]
> >  [exec] If you don't have Sphinx installed, grab it from
> >  [exec]
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsphinx-
> doc.org%2Fdata=01%7C01%7Cthomas.steinmaurer%40dynatrace.com
> %7C03eca1f6cc28486eb1b708d648828988%7C70ebe3a35b30435d9d677716d7
> 4ca190%7C1sdata=tQAjTlSRkHXB5m3760%2BmcduWkgBFKTdFBHCc7S
> RNR%2FQ%3Dreserved=0
> >  [exec] Result: 1
> >
> > artifacts:
> >
> > BUILD SUCCESSFUL
> > Total time: 3 minutes 14 seconds
> >
> >
> > Thanks,
> > Thomas
> >
> > The contents of this e-mail are intended for the named addressee only. It
> contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or disclose
> it to anyone else. If you received it in error please notify us immediately 
> and
> then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a
> company registered in Linz whose registered office is at 4040 Linz, Austria,
> Freist?dterstra?e 313
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org

The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a 
company registered in Linz whose registered office is at 4040 Linz, Austria, 
Freistädterstraße 313

Cassandra 4.0 (Trunk) - "ant artifacts" does not create binary tarball

2018-11-12 Thread Steinmaurer, Thomas

Hello,

I'm trying to start with some first C* 4.0 experiments, thus tried to locally 
build and create binary tarball artifcats. While this has worked e.g. with 
3.11, I can't create a binary tarball for 4.0 anymore.

What I did locally:
* Switched from branch cassandra-3.11 to trunk
* ant realclean
* ant artifacts

I get the apache-cassandra-4.0-SNAPSHOT.jar created but no binary tarball.

End of "ant artifacts" console output is:

  [javadoc]  * the compaction strategy placement reflect most up-to-date disk 
boundaries, call {@link this#maybeReloadDiskBoundaries()}
  [javadoc] 
   ^
  [javadoc] Building index for all the packages and classes...
  [javadoc] Building index for all classes...
  [javadoc] Generating 
C:\workspaces\git\cassandra\build\javadoc\help-doc.html...
  [javadoc] 92 errors
  [javadoc] 100 warnings

gen-doc:
 [exec]
 [exec] The 'sphinx-build' command was not found. Make sure you have Sphinx
 [exec] installed, then set the SPHINXBUILD environment variable to point
 [exec] to the full path of the 'sphinx-build' executable. Alternatively you
 [exec] may add the Sphinx directory to PATH.
 [exec]
 [exec] If you don't have Sphinx installed, grab it from
 [exec] http://sphinx-doc.org/
 [exec] Result: 1

artifacts:

BUILD SUCCESSFUL
Total time: 3 minutes 14 seconds


Thanks,
Thomas

The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a 
company registered in Linz whose registered office is at 4040 Linz, Austria, 
Freist?dterstra?e 313

Cassandra 3.11.3 compile error in Eclipse 4.8 Photon

2018-08-05 Thread Steinmaurer, Thomas

Hello,

checked out Cassandra 3.11.3 to debug something.

Eclipse 4.8.0 Photon (Build id: 20180619-1200) complains on the following 
compile error:

The method map(Function) in the type Stream is 
not applicable for the arguments (((transform != null) ? transform : ( 
cell) -> ""))  AbstractRow.java
/cassandra/src/java/org/apache/cassandra/db/rows line 183
Java Problem
Type mismatch: cannot convert from Function to FunctionAbstractRow.java
/cassandra/src/java/org/apache/cassandra/db/rows line 183
Java Problem
Type mismatch: cannot convert from String to R   AbstractRow.java   
 /cassandra/src/java/org/apache/cassandra/db/rows line 183  
  Java Problem


Source builds fine with ant and JDK8u162.

Regards,
Thomas

The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a 
company registered in Linz whose registered office is at 4040 Linz, Austria, 
Freist?dterstra?e 313

RE: Roadmap for 4.0

2018-04-06 Thread Steinmaurer, Thomas

IMHO, stability and manageability (want to have the old (2.1) full repair 
behavior back , yes I followed the repair scheduling thread here) should be 
the top priority before adding any new CQL enhancements or whatever. 
Manageability improvements even treated for backports into 3.11.x, as it seems 
4.0 is a long way ahead for production usage.

Just my 2 EUR cents. 

Thanks,
Thomas


-Original Message-
From: Nate McCall [mailto:zznat...@gmail.com]
Sent: Freitag, 06. April 2018 06:01
To: dev 
Subject: Re: Roadmap for 4.0

>>
>> So long as non-user-visible improvements, including big ones, can
>> still go in 4.0 at that stage, I’m all for it.
>
>
> My understanding is that after June 1st the 4.0 branch would be
> created and would be bugfix only. It's not really a feature freeze if
> you allow improvements after that, which is why they'd instead go to trunk.
>
> I'm also on the "too soon" train so pushing it back to August or so is
> desirable to me.
>

For those wanting to delay, are we just dancing around inclusion of some pet 
features? This is fine, I just think we need to communicate what we are after 
if so.

We can do two things:
1. Lay our cards on the table about what we want included in 4.0 and work to 
get those in 2. Agree to keep June 1 follow up a lot quicker with a 4.1

I do want to remind everyone though that each new feature is at odds with our 
stability goals for 4.0.

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

The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a 
company registered in Linz whose registered office is at 4040 Linz, Austria, 
Freistädterstraße 313

RE: Roadmap for 4.0

2018-04-04 Thread Steinmaurer, Thomas

Having https://issues.apache.org/jira/browse/CASSANDRA-12269 in mind, 3.0 was a 
noticeable step back regarding write throughput compared to what we have been 
used with 2.1 on the same infrastructure, thus for us, 3.0.x is a no-go, thus 
planning more towards the 3.11.x series in pre-production stages this year 
before deploying into production. Production-wise, we are still "stuck" and 
(more or less) happy with 2.1.

Thomas

-Original Message-
From: alek...@apple.com [mailto:alek...@apple.com]
Sent: Mittwoch, 04. April 2018 12:38
To: dev@cassandra.apache.org
Subject: Re: Roadmap for 4.0

3.0 will be the most popular release for probably at least another couple years 
- I see no good reason to cap its support window. We aren’t Oracle.

—
AY

On 3 April 2018 at 22:29:29, Michael Shuler (mich...@pbandjelly.org) wrote:

Apache Cassandra 3.0 is supported until 6 months after 4.0 release (date TBD).
The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a 
company registered in Linz whose registered office is at 4040 Linz, Austria, 
Freistädterstraße 313

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

RE: how to fix constantly getting out of memory (3.11)

2017-12-12 Thread Steinmaurer, Thomas

Hi,

if you are talking about on-heap troubles, then the following might be related 
in 3.11.x:
https://issues.apache.org/jira/browse/CASSANDRA-13929

Thomas

-Original Message-
From: Micha [mailto:mich...@fantasymail.de]
Sent: Dienstag, 12. Dezember 2017 09:24
To: dev@cassandra.apache.org
Subject: how to fix constantly getting out of memory (3.11)

Hi,

I have seven nodes, debian stretch with c*3.11, each with 2TB disk (500G free), 
32G Ram.
I have a keyspace with seven tables. At the moment the cluster doesn't work at 
all reliably. Every morning at least 2 nodes are shut down due to out of 
memory. Repair afterwards fails with "some repair failed".
I use G1 with 16G heap on 6 six nodes and cms with 8G heap on one node to see a 
difference. In munin it's easy to see a constantly rising memory consumption. 
There are no other services running. I cannot understand who is not releasing 
the memory.
Some tables have some big rows (as mentioned in my last mail to the list). Can 
this be a source of the memory consumption?

How do you track down this?  Is there memory which doesn't get released and 
accumulates over time? I have not yet debugged such gc/memory issues.

cheers
 Michael


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

The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a 
company registered in Linz whose registered office is at 4040 Linz, Austria, 
Freistädterstraße 313

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

RE: Do it need to run 'nodetool upgradesstables' when updating from 2.0.9 to 2.1.19?

2017-10-13 Thread Steinmaurer, Thomas

And extremely useful/important in the field not being a strict requirement 
immediately upgrading sstables, especially for not closely monitored 
environments, e.g. unattended deployments like development machines or even 
customer on-prem installations etc.

Cassandra's data backwards compatibility is one of the best I have seen.

Thanks a lot for that!

T.


-Original Message-
From: J. D. Jordan [mailto:jeremiah.jor...@gmail.com]
Sent: Freitag, 13. Oktober 2017 13:13
To: dev@cassandra.apache.org
Subject: Re: Do it need to run 'nodetool upgradesstables' when updating from 
2.0.9 to 2.1.19?

Old restrictions that have been lifted Jeff :) Ever since 2.0 we have supported 
streaming old sstables, see here for the 2.0 ticket:
https://issues.apache.org/jira/browse/CASSANDRA-5772

That was broken in early 3.0, but had since been fixed by the ticket Marcus 
linked https://issues.apache.org/jira/browse/CASSANDRA-10990

So it should be fine in all latest 3.x versions.

-Jeremiah


> On Oct 13, 2017, at 3:34 AM, Steinmaurer, Thomas 
> <thomas.steinmau...@dynatrace.com> wrote:
>
> Same here, regarding sincere question to know the corner cases from 2.1 => 
> 3.11.1, but Marcus already provided the JIRA ticket.
>
> Thanks!
>
>
> -Original Message-
> From: Per OtterstrÃ¶m [mailto:per.otterst...@ericsson.com]
> Sent: Freitag, 13. Oktober 2017 09:01
> To: dev@cassandra.apache.org
> Subject: RE: Do it need to run 'nodetool upgradesstables' when updating from 
> 2.0.9 to 2.1.19?
>
> Hepp!
>
> Just to be clear, I'm not claiming this to be the case, it is a sincere 
> question. My team is planning an upgrade from 2.2 to 3.0 which is why I'm 
> asking. Some initial tests indicate that repairs etc work well before running 
> upgradesstables (assuming all nodes are upgraded to 3.0). But if there are 
> known corner cases I'd be interested to know.
>
> We need to support reading old sstables in order to support rolling upgrades. 
> This seem to be a general assumption that people agree on. I'm not sure there 
> is a clear agreement on the streaming part. Would it make sense to clarify 
> this in documentation?
>
> /pelle
>
> -Original Message-
> From: Jeff Jirsa [mailto:jji...@gmail.com]
> Sent: den 13 oktober 2017 08:09
> To: dev@cassandra.apache.org
> Subject: Re: Do it need to run 'nodetool upgradesstables' when updating from 
> 2.0.9 to 2.1.19?
>
> Two people say Iâ€™m wrong, Iâ€™ll believe it - must be imagining 
> restrictions that donâ€™t exist.
>
> --
> Jeff Jirsa
>
>
>> On Oct 12, 2017, at 10:55 PM, Per OtterstrÃ¶m <per.otterst...@ericsson.com> 
>> wrote:
>>
>> Hi!
>>
>> This was news to me. I had the impression that we are maintaining backwards 
>> compatibility for streaming non-upgraded sstables. Is that not the case?
>>
>> However, I believe it is a good idea to run upgradesstables at some point 
>> _before_ upgrading Cassandra next time to make sure there are no old 
>> sstables around before you take the next step.
>>
>> /pelle
>>
>> -Original Message-
>> From: Jeff Jirsa [mailto:jji...@gmail.com]
>> Sent: den 12 oktober 2017 23:11
>> To: Cassandra DEV <dev@cassandra.apache.org>
>> Subject: Re: Do it need to run 'nodetool upgradesstables' when updating from 
>> 2.0.9 to 2.1.19?
>>
>> You won't notice any issues (all versions of cassandra are backwards 
>> compatible at least 1 version), and sstables will be slowly migrated to the 
>> new format as you compact, but you should still run it (upgradesstables) 
>> explicitly because when it comes time to run 
>> repair/boostrap/decommission/etc, you'll need all sstables on the 
>> same/current format.
>>
>>
>>
>> On Thu, Oct 12, 2017 at 1:59 PM, Li, Guangxing
>> <guangxing...@pearson.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I recently upgraded my test cluster from C* 2.0.9 to 2.1.19 and I
>>> did not run 'nodetool upgradesstables' at all. Per my confirmation
>>> afterwards, everything is fine. But according to documentation at
>>> https://support.datastax.com/hc/en-us/articles/208040036-
>>> Nodetool-upgradesstables-FAQ.
>>> I need to do that.
>>> So can someone tell me if I must do 'nodetool upgradesstables' after
>>> upgrading each node from 2.0.9 to 2.1.19?
>>>
>>> Thanks.
>>>
>>> George.
>>>
>> Bâ€¹
>> CBâ€¢Ãˆ[Å“ÃXÅ“Ã˜ÃœÅ¡Xâ„¢KK[XZ[
> Ë†]â€¹][Å“ÃXÅ“Ã˜ÃœÅ¡Xâ„¢PÃ˜\ÃœÃ˜[â„¢ËœKËœ\XÃšKâ€ºÃœâ„¢ÃƒBâ€˜â€º
> ÃœË†Y][Ã›Ëœ[Ã›Ã›[X[â„¢Ã‹K[XZ[
> Ë†]

RE: Do it need to run 'nodetool upgradesstables' when updating from 2.0.9 to 2.1.19?

2017-10-13 Thread Steinmaurer, Thomas

Same here, regarding sincere question to know the corner cases from 2.1 => 
3.11.1, but Marcus already provided the JIRA ticket.

Thanks!

-Original Message-
From: Per Otterström [mailto:per.otterst...@ericsson.com]
Sent: Freitag, 13. Oktober 2017 09:01
To: dev@cassandra.apache.org
Subject: RE: Do it need to run 'nodetool upgradesstables' when updating from 
2.0.9 to 2.1.19?

Hepp!

Just to be clear, I'm not claiming this to be the case, it is a sincere 
question. My team is planning an upgrade from 2.2 to 3.0 which is why I'm 
asking. Some initial tests indicate that repairs etc work well before running 
upgradesstables (assuming all nodes are upgraded to 3.0). But if there are 
known corner cases I'd be interested to know.

We need to support reading old sstables in order to support rolling upgrades. 
This seem to be a general assumption that people agree on. I'm not sure there 
is a clear agreement on the streaming part. Would it make sense to clarify this 
in documentation?

/pelle

-Original Message-
From: Jeff Jirsa [mailto:jji...@gmail.com]
Sent: den 13 oktober 2017 08:09
To: dev@cassandra.apache.org
Subject: Re: Do it need to run 'nodetool upgradesstables' when updating from 
2.0.9 to 2.1.19?

Two people say I’m wrong, I’ll believe it - must be imagining restrictions that 
don’t exist.

--
Jeff Jirsa

> On Oct 12, 2017, at 10:55 PM, Per Otterström  
> wrote:
>
> Hi!
>
> This was news to me. I had the impression that we are maintaining backwards 
> compatibility for streaming non-upgraded sstables. Is that not the case?
>
> However, I believe it is a good idea to run upgradesstables at some point 
> _before_ upgrading Cassandra next time to make sure there are no old sstables 
> around before you take the next step.
>
> /pelle
>
> -Original Message-
> From: Jeff Jirsa [mailto:jji...@gmail.com]
> Sent: den 12 oktober 2017 23:11
> To: Cassandra DEV 
> Subject: Re: Do it need to run 'nodetool upgradesstables' when updating from 
> 2.0.9 to 2.1.19?
>
> You won't notice any issues (all versions of cassandra are backwards 
> compatible at least 1 version), and sstables will be slowly migrated to the 
> new format as you compact, but you should still run it (upgradesstables) 
> explicitly because when it comes time to run 
> repair/boostrap/decommission/etc, you'll need all sstables on the 
> same/current format.
>
>
>
> On Thu, Oct 12, 2017 at 1:59 PM, Li, Guangxing 
> wrote:
>
>> Hi,
>>
>> I recently upgraded my test cluster from C* 2.0.9 to 2.1.19 and I did
>> not run 'nodetool upgradesstables' at all. Per my confirmation
>> afterwards, everything is fine. But according to documentation at
>> https://support.datastax.com/hc/en-us/articles/208040036-
>> Nodetool-upgradesstables-FAQ.
>> I need to do that.
>> So can someone tell me if I must do 'nodetool upgradesstables' after
>> upgrading each node from 2.0.9 to 2.1.19?
>>
>> Thanks.
>>
>> George.
>>
> B‹CB•È[œÝXœØÜšX™KK[XZ[
ˆ]‹][œÝXœØÜšX™PØ\ÜØ[™˜K˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ËK[XZ[
ˆ]‹Z[Ø\ÜØ[™˜K˜\XÚK›Ü™ÃBƒB

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

B�CB��[��X��ܚX�KK[XZ[
�]�][��X��ܚX�P�\��[��K�\X�K�ܙ�B��܈Y][ۘ[��[X[��K[XZ[
�]�Z[�\��[��K�\X�K�ܙ�B�B
The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a 
company registered in Linz whose registered office is at 4040 Linz, Austria, 
Freistädterstraße 313

RE: Do it need to run 'nodetool upgradesstables' when updating from 2.0.9 to 2.1.19?

2017-10-13 Thread Steinmaurer, Thomas

Hi Jeff,

I was under the impression that streaming in a cluster with mixed binary 
versions might be problematic, but as long as the cluster is on the same binary 
version (e.g. after a rolling upgrade), we still can have SStables in mixed 
data formats and streaming will work?

Thanks,
Thomas

-Original Message-
From: Jeff Jirsa [mailto:jji...@gmail.com]
Sent: Donnerstag, 12. Oktober 2017 23:11
To: Cassandra DEV 
Subject: Re: Do it need to run 'nodetool upgradesstables' when updating from 
2.0.9 to 2.1.19?

You won't notice any issues (all versions of cassandra are backwards compatible 
at least 1 version), and sstables will be slowly migrated to the new format as 
you compact, but you should still run it (upgradesstables) explicitly because 
when it comes time to run repair/boostrap/decommission/etc, you'll need all 
sstables on the same/current format.

On Thu, Oct 12, 2017 at 1:59 PM, Li, Guangxing 
wrote:

> Hi,
>
> I recently upgraded my test cluster from C* 2.0.9 to 2.1.19 and I did
> not run 'nodetool upgradesstables' at all. Per my confirmation
> afterwards, everything is fine. But according to documentation at
> https://support.datastax.com/hc/en-us/articles/208040036-
> Nodetool-upgradesstables-FAQ.
> I need to do that.
> So can someone tell me if I must do 'nodetool upgradesstables' after
> upgrading each node from 2.0.9 to 2.1.19?
>
> Thanks.
>
> George.
>
The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a 
company registered in Linz whose registered office is at 4040 Linz, Austria, 
Freistädterstraße 313

RE: [VOTE] Release Apache Cassandra 3.11.1

2017-10-03 Thread Steinmaurer, Thomas

Jon,

I have  created the following issue: 
https://issues.apache.org/jira/browse/CASSANDRA-13929 with what we are seeing 
memory leak wise + discussing a potential fix.

Thomas

-Original Message-
From: Jon Haddad [mailto:jonathan.had...@gmail.com] On Behalf Of Jon Haddad
Sent: Montag, 02. Oktober 2017 23:09
To: dev@cassandra.apache.org
Subject: Re: [VOTE] Release Apache Cassandra 3.11.1

Same boat as Jeff, +1 since it’s not a regression.

> On Oct 2, 2017, at 2:04 PM, Steinmaurer, Thomas 
> <thomas.steinmau...@dynatrace.com> wrote:
>
> Jeff of course, not Jon. Sorry :-)
>
>
> -Original Message-
> From: Steinmaurer, Thomas [mailto:thomas.steinmau...@dynatrace.com]
> Sent: Montag, 02. Oktober 2017 22:58
> To: dev@cassandra.apache.org
> Subject: RE: [VOTE] Release Apache Cassandra 3.11.1
>
> Jon,
>
> yes I also did see it with 3.11.0.
>
> Thomas
>
>
> -Original Message-
> From: Jeff Jirsa [mailto:jji...@gmail.com]
> Sent: Montag, 02. Oktober 2017 22:47
> To: Cassandra DEV <dev@cassandra.apache.org>
> Subject: Re: [VOTE] Release Apache Cassandra 3.11.1
>
> Thomas, did you see this on 3.11.0 as well, or have you not tried 3.11.0 (I 
> know you probably want fixes from 3.11.1, but let's just clarify that this is 
> or is not a regression).
>
> If it's not a regression, we should ship this and then hopefully we'll spin a 
> 3.11.2 as soon as this is fixed.
>
> If it is a regression, I'll flip my vote to -1.
>
>
>
> On Mon, Oct 2, 2017 at 1:29 PM, Steinmaurer, Thomas < 
> thomas.steinmau...@dynatrace.com> wrote:
>
>> Jon,
>>
>> please see my latest comment + attached screen from our monitoring here:
>> https://issues.apache.org/jira/browse/CASSANDRA-13754?
>> focusedCommentId=16188758=com.atlassian.jira.
>> plugin.system.issuetabpanels:comment-tabpanel#comment-16188758
>>
>> Thanks,
>> Thomas
>>
>> -Original Message-
>> From: Jon Haddad [mailto:jonathan.had...@gmail.com] On Behalf Of Jon
>> Haddad
>> Sent: Montag, 02. Oktober 2017 22:09
>> To: dev@cassandra.apache.org
>> Subject: Re: [VOTE] Release Apache Cassandra 3.11.1
>>
>> You’re saying the same memory leak happens under 3.11?
>>
>>> On Oct 2, 2017, at 1:04 PM, Aleksey Yeshchenko <alek...@apple.com>
>> wrote:
>>>
>>> Thomas,
>>>
>>> I would maybe agree with waiting for a while because of it, if we
>>> had a
>> proper fix at least under review - or in progress by someone.
>>>
>>> But this is not a regression, and there’s been a lot of fixes
>> accumulated and not released yet. Arguable worse to hold them back :\
>>>
>>> —
>>> AY
>>>
>>> On 2 October 2017 at 20:54:38, Steinmaurer, Thomas (
>> thomas.steinmau...@dynatrace.com) wrote:
>>>
>>> Jeff,
>>>
>>> even if it is not a strict regression, this currently forces us to
>>> do a
>> rolling restart every ~ 72hrs to be on the safe-side with -Xmx8G.
>> Luckily this is just a loadtest environment. We don't have 3.11 in 
>> production yet.
>>>
>>> I can offer to immediately deploy a snapshot build into our loadtest
>> environment, in case this issue gets attention and a fix needs
>> verification at constant load.
>>>
>>> Thanks,
>>> Thomas
>>>
>>> -Original Message-
>>> From: Jeff Jirsa [mailto:jji...@gmail.com]
>>> Sent: Montag, 02. Oktober 2017 20:04
>>> To: Cassandra DEV <dev@cassandra.apache.org>
>>> Subject: Re: [VOTE] Release Apache Cassandra 3.11.1
>>>
>>> +1
>>>
>>> ( Somewhat concerned that
>>> https://issues.apache.org/jira/browse/CASSANDRA-13754 may not be
>>> fixed,
>> but it's not a strict regression ? )
>>>
>>>
>>>
>>> On Mon, Oct 2, 2017 at 10:58 AM, Michael Shuler
>>> <mich...@pbandjelly.org>
>>> wrote:
>>>
>>>> I propose the following artifacts for release as 3.11.1.
>>>>
>>>> sha1: 983c72a84ab6628e09a78ead9e20a0c323a005af
>>>> Git:
>>>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
>>>> shortlog;h=refs/tags/3.11.1-tentative
>>>> Artifacts:
>>>> https://repository.apache.org/content/repositories/
>>>> orgapachecassandra-1151/org/apache/cassandra/apache-cassandra/3.11.
>>>> 1/
>>>> Staging repository:
>>>> https://repository.apache.org/content/repositories/
>>>> orgapachecassandra-1151/
>

RE: [VOTE] Release Apache Cassandra 3.11.1

2017-10-02 Thread Steinmaurer, Thomas

Jeff of course, not Jon. Sorry :-)


-Original Message-
From: Steinmaurer, Thomas [mailto:thomas.steinmau...@dynatrace.com]
Sent: Montag, 02. Oktober 2017 22:58
To: dev@cassandra.apache.org
Subject: RE: [VOTE] Release Apache Cassandra 3.11.1

Jon,

yes I also did see it with 3.11.0.

Thomas


-Original Message-
From: Jeff Jirsa [mailto:jji...@gmail.com]
Sent: Montag, 02. Oktober 2017 22:47
To: Cassandra DEV <dev@cassandra.apache.org>
Subject: Re: [VOTE] Release Apache Cassandra 3.11.1

Thomas, did you see this on 3.11.0 as well, or have you not tried 3.11.0 (I 
know you probably want fixes from 3.11.1, but let's just clarify that this is 
or is not a regression).

If it's not a regression, we should ship this and then hopefully we'll spin a 
3.11.2 as soon as this is fixed.

If it is a regression, I'll flip my vote to -1.



On Mon, Oct 2, 2017 at 1:29 PM, Steinmaurer, Thomas < 
thomas.steinmau...@dynatrace.com> wrote:

> Jon,
>
> please see my latest comment + attached screen from our monitoring here:
> https://issues.apache.org/jira/browse/CASSANDRA-13754?
> focusedCommentId=16188758=com.atlassian.jira.
> plugin.system.issuetabpanels:comment-tabpanel#comment-16188758
>
> Thanks,
> Thomas
>
> -Original Message-
> From: Jon Haddad [mailto:jonathan.had...@gmail.com] On Behalf Of Jon
> Haddad
> Sent: Montag, 02. Oktober 2017 22:09
> To: dev@cassandra.apache.org
> Subject: Re: [VOTE] Release Apache Cassandra 3.11.1
>
> You’re saying the same memory leak happens under 3.11?
>
> > On Oct 2, 2017, at 1:04 PM, Aleksey Yeshchenko <alek...@apple.com>
> wrote:
> >
> > Thomas,
> >
> > I would maybe agree with waiting for a while because of it, if we
> > had a
> proper fix at least under review - or in progress by someone.
> >
> > But this is not a regression, and there’s been a lot of fixes
> accumulated and not released yet. Arguable worse to hold them back :\
> >
> > —
> > AY
> >
> > On 2 October 2017 at 20:54:38, Steinmaurer, Thomas (
> thomas.steinmau...@dynatrace.com) wrote:
> >
> > Jeff,
> >
> > even if it is not a strict regression, this currently forces us to
> > do a
> rolling restart every ~ 72hrs to be on the safe-side with -Xmx8G.
> Luckily this is just a loadtest environment. We don't have 3.11 in production 
> yet.
> >
> > I can offer to immediately deploy a snapshot build into our loadtest
> environment, in case this issue gets attention and a fix needs
> verification at constant load.
> >
> > Thanks,
> > Thomas
> >
> > -Original Message-
> > From: Jeff Jirsa [mailto:jji...@gmail.com]
> > Sent: Montag, 02. Oktober 2017 20:04
> > To: Cassandra DEV <dev@cassandra.apache.org>
> > Subject: Re: [VOTE] Release Apache Cassandra 3.11.1
> >
> > +1
> >
> > ( Somewhat concerned that
> > https://issues.apache.org/jira/browse/CASSANDRA-13754 may not be
> > fixed,
> but it's not a strict regression ? )
> >
> >
> >
> > On Mon, Oct 2, 2017 at 10:58 AM, Michael Shuler
> > <mich...@pbandjelly.org>
> > wrote:
> >
> >> I propose the following artifacts for release as 3.11.1.
> >>
> >> sha1: 983c72a84ab6628e09a78ead9e20a0c323a005af
> >> Git:
> >> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> >> shortlog;h=refs/tags/3.11.1-tentative
> >> Artifacts:
> >> https://repository.apache.org/content/repositories/
> >> orgapachecassandra-1151/org/apache/cassandra/apache-cassandra/3.11.
> >> 1/
> >> Staging repository:
> >> https://repository.apache.org/content/repositories/
> >> orgapachecassandra-1151/
> >>
> >> The Debian packages are available here:
> >> http://people.apache.org/~mshuler
> >>
> >> The vote will be open for 72 hours (longer if needed).
> >>
> >> [1]: (CHANGES.txt) https://goo.gl/dZCRk8
> >> [2]: (NEWS.txt) https://goo.gl/rh24MX
> >>
> >> ---
> >> -- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>
> >>
> > The contents of this e-mail are intended for the named addressee only.
> It contains information that may be confidential. Unless you are the
> named addressee or an authorized designee, you may not copy or use it,
> or disclose it to anyone else. If you received it in error please
> notify us immediately and then destroy it. Dynatrace Austria GmbH
> (registration number FN 91482h) is a company regi

RE: [VOTE] Release Apache Cassandra 3.11.1

2017-10-02 Thread Steinmaurer, Thomas

Jon,

yes I also did see it with 3.11.0.

Thomas


-Original Message-
From: Jeff Jirsa [mailto:jji...@gmail.com]
Sent: Montag, 02. Oktober 2017 22:47
To: Cassandra DEV <dev@cassandra.apache.org>
Subject: Re: [VOTE] Release Apache Cassandra 3.11.1

Thomas, did you see this on 3.11.0 as well, or have you not tried 3.11.0 (I 
know you probably want fixes from 3.11.1, but let's just clarify that this is 
or is not a regression).

If it's not a regression, we should ship this and then hopefully we'll spin a 
3.11.2 as soon as this is fixed.

If it is a regression, I'll flip my vote to -1.



On Mon, Oct 2, 2017 at 1:29 PM, Steinmaurer, Thomas < 
thomas.steinmau...@dynatrace.com> wrote:

> Jon,
>
> please see my latest comment + attached screen from our monitoring here:
> https://issues.apache.org/jira/browse/CASSANDRA-13754?
> focusedCommentId=16188758=com.atlassian.jira.
> plugin.system.issuetabpanels:comment-tabpanel#comment-16188758
>
> Thanks,
> Thomas
>
> -Original Message-
> From: Jon Haddad [mailto:jonathan.had...@gmail.com] On Behalf Of Jon
> Haddad
> Sent: Montag, 02. Oktober 2017 22:09
> To: dev@cassandra.apache.org
> Subject: Re: [VOTE] Release Apache Cassandra 3.11.1
>
> You’re saying the same memory leak happens under 3.11?
>
> > On Oct 2, 2017, at 1:04 PM, Aleksey Yeshchenko <alek...@apple.com>
> wrote:
> >
> > Thomas,
> >
> > I would maybe agree with waiting for a while because of it, if we
> > had a
> proper fix at least under review - or in progress by someone.
> >
> > But this is not a regression, and there’s been a lot of fixes
> accumulated and not released yet. Arguable worse to hold them back :\
> >
> > —
> > AY
> >
> > On 2 October 2017 at 20:54:38, Steinmaurer, Thomas (
> thomas.steinmau...@dynatrace.com) wrote:
> >
> > Jeff,
> >
> > even if it is not a strict regression, this currently forces us to
> > do a
> rolling restart every ~ 72hrs to be on the safe-side with -Xmx8G.
> Luckily this is just a loadtest environment. We don't have 3.11 in production 
> yet.
> >
> > I can offer to immediately deploy a snapshot build into our loadtest
> environment, in case this issue gets attention and a fix needs
> verification at constant load.
> >
> > Thanks,
> > Thomas
> >
> > -Original Message-
> > From: Jeff Jirsa [mailto:jji...@gmail.com]
> > Sent: Montag, 02. Oktober 2017 20:04
> > To: Cassandra DEV <dev@cassandra.apache.org>
> > Subject: Re: [VOTE] Release Apache Cassandra 3.11.1
> >
> > +1
> >
> > ( Somewhat concerned that
> > https://issues.apache.org/jira/browse/CASSANDRA-13754 may not be
> > fixed,
> but it's not a strict regression ? )
> >
> >
> >
> > On Mon, Oct 2, 2017 at 10:58 AM, Michael Shuler
> > <mich...@pbandjelly.org>
> > wrote:
> >
> >> I propose the following artifacts for release as 3.11.1.
> >>
> >> sha1: 983c72a84ab6628e09a78ead9e20a0c323a005af
> >> Git:
> >> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> >> shortlog;h=refs/tags/3.11.1-tentative
> >> Artifacts:
> >> https://repository.apache.org/content/repositories/
> >> orgapachecassandra-1151/org/apache/cassandra/apache-cassandra/3.11.
> >> 1/
> >> Staging repository:
> >> https://repository.apache.org/content/repositories/
> >> orgapachecassandra-1151/
> >>
> >> The Debian packages are available here:
> >> http://people.apache.org/~mshuler
> >>
> >> The vote will be open for 72 hours (longer if needed).
> >>
> >> [1]: (CHANGES.txt) https://goo.gl/dZCRk8
> >> [2]: (NEWS.txt) https://goo.gl/rh24MX
> >>
> >> ---
> >> -- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>
> >>
> > The contents of this e-mail are intended for the named addressee only.
> It contains information that may be confidential. Unless you are the
> named addressee or an authorized designee, you may not copy or use it,
> or disclose it to anyone else. If you received it in error please
> notify us immediately and then destroy it. Dynatrace Austria GmbH
> (registration number FN 91482h) is a company registered in Linz whose
> registered office is at 4040 Linz, Austria, Freistädterstraße 313
> >
> > 
> > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.or

RE: [VOTE] Release Apache Cassandra 3.11.1

2017-10-02 Thread Steinmaurer, Thomas

Jon,

please see my latest comment + attached screen from our monitoring here: 
https://issues.apache.org/jira/browse/CASSANDRA-13754?focusedCommentId=16188758=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16188758

Thanks,
Thomas

-Original Message-
From: Jon Haddad [mailto:jonathan.had...@gmail.com] On Behalf Of Jon Haddad
Sent: Montag, 02. Oktober 2017 22:09
To: dev@cassandra.apache.org
Subject: Re: [VOTE] Release Apache Cassandra 3.11.1

You’re saying the same memory leak happens under 3.11?

> On Oct 2, 2017, at 1:04 PM, Aleksey Yeshchenko <alek...@apple.com> wrote:
>
> Thomas,
>
> I would maybe agree with waiting for a while because of it, if we had a 
> proper fix at least under review - or in progress by someone.
>
> But this is not a regression, and there’s been a lot of fixes accumulated and 
> not released yet. Arguable worse to hold them back :\
>
> —
> AY
>
> On 2 October 2017 at 20:54:38, Steinmaurer, Thomas 
> (thomas.steinmau...@dynatrace.com) wrote:
>
> Jeff,
>
> even if it is not a strict regression, this currently forces us to do a 
> rolling restart every ~ 72hrs to be on the safe-side with -Xmx8G. Luckily 
> this is just a loadtest environment. We don't have 3.11 in production yet.
>
> I can offer to immediately deploy a snapshot build into our loadtest 
> environment, in case this issue gets attention and a fix needs verification 
> at constant load.
>
> Thanks,
> Thomas
>
> -Original Message-
> From: Jeff Jirsa [mailto:jji...@gmail.com]
> Sent: Montag, 02. Oktober 2017 20:04
> To: Cassandra DEV <dev@cassandra.apache.org>
> Subject: Re: [VOTE] Release Apache Cassandra 3.11.1
>
> +1
>
> ( Somewhat concerned that
> https://issues.apache.org/jira/browse/CASSANDRA-13754 may not be fixed, but 
> it's not a strict regression ? )
>
>
>
> On Mon, Oct 2, 2017 at 10:58 AM, Michael Shuler <mich...@pbandjelly.org>
> wrote:
>
>> I propose the following artifacts for release as 3.11.1.
>>
>> sha1: 983c72a84ab6628e09a78ead9e20a0c323a005af
>> Git:
>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
>> shortlog;h=refs/tags/3.11.1-tentative
>> Artifacts:
>> https://repository.apache.org/content/repositories/
>> orgapachecassandra-1151/org/apache/cassandra/apache-cassandra/3.11.1/
>> Staging repository:
>> https://repository.apache.org/content/repositories/
>> orgapachecassandra-1151/
>>
>> The Debian packages are available here:
>> http://people.apache.org/~mshuler
>>
>> The vote will be open for 72 hours (longer if needed).
>>
>> [1]: (CHANGES.txt) https://goo.gl/dZCRk8
>> [2]: (NEWS.txt) https://goo.gl/rh24MX
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>
>>
> The contents of this e-mail are intended for the named addressee only. It 
> contains information that may be confidential. Unless you are the named 
> addressee or an authorized designee, you may not copy or use it, or disclose 
> it to anyone else. If you received it in error please notify us immediately 
> and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) 
> is a company registered in Linz whose registered office is at 4040 Linz, 
> Austria, Freistädterstraße 313
>
> -
> 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

The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a 
company registered in Linz whose registered office is at 4040 Linz, Austria, 
Freistädterstraße 313

RE: [VOTE] Release Apache Cassandra 3.11.1

2017-10-02 Thread Steinmaurer, Thomas

Jeff,

even if it is not a strict regression, this currently forces us to do a rolling 
restart every ~ 72hrs to be on the safe-side with -Xmx8G. Luckily this is just 
a loadtest environment. We don't have 3.11 in production yet.

I can offer to immediately deploy a snapshot build into our loadtest 
environment, in case this issue gets attention and a fix needs verification at 
constant load.

Thanks,
Thomas

-Original Message-
From: Jeff Jirsa [mailto:jji...@gmail.com]
Sent: Montag, 02. Oktober 2017 20:04
To: Cassandra DEV 
Subject: Re: [VOTE] Release Apache Cassandra 3.11.1

+1

( Somewhat concerned that
https://issues.apache.org/jira/browse/CASSANDRA-13754 may not be fixed, but 
it's not a strict regression ? )



On Mon, Oct 2, 2017 at 10:58 AM, Michael Shuler 
wrote:

> I propose the following artifacts for release as 3.11.1.
>
> sha1: 983c72a84ab6628e09a78ead9e20a0c323a005af
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> shortlog;h=refs/tags/3.11.1-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1151/org/apache/cassandra/apache-cassandra/3.11.1/
> Staging repository:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1151/
>
> The Debian packages are available here:
> http://people.apache.org/~mshuler
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: (CHANGES.txt) https://goo.gl/dZCRk8
> [2]: (NEWS.txt) https://goo.gl/rh24MX
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>
The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a 
company registered in Linz whose registered office is at 4040 Linz, Austria, 
Freistädterstraße 313

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

Cassandra 3.11.1 (snapshot build) - io.netty.util.Recycler$Stack memory leak

2017-10-01 Thread Steinmaurer, Thomas

Hello,

posted also to the users list, but possibly it is better targeted to this list, 
cause 3.11.1 is close to be released?

We were facing a memory leak with 3.11.0 
(https://issues.apache.org/jira/browse/CASSANDRA-13754) thus upgraded our 
loadtest environment to a snapshot build of 3.11.1. Having it running for > 48 
hrs now, we still see a steady increase on heap utilization.

Eclipse memory analyzer shows 147 instances of io.netty.util.Recycler$Stack 
with a total retained heap usage of ~ 1,8G, growing over time.

Should this be fixed already by CASSANDRA-13754 or is this something new?

Thanks,
Thomas


The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a 
company registered in Linz whose registered office is at 4040 Linz, Austria, 
Freist?dterstra?e 313

RE: Recent log4j vulnerability

RE: Recent log4j vulnerability

RE: [DISCUSS] Java support roadmap

RE: Enable running Cassandra 3.11 on Java 11

RE: Next round of releases…

Cassandra 3.0.20 ETA?

Cassandra 4.0 on Windows 10 crashing upon startup with Java 11

RE: Cassandra 4.0 (Trunk) - "ant artifacts" does not create binary tarball

Cassandra 4.0 (Trunk) - "ant artifacts" does not create binary tarball

Cassandra 3.11.3 compile error in Eclipse 4.8 Photon

RE: Roadmap for 4.0

RE: Roadmap for 4.0

RE: how to fix constantly getting out of memory (3.11)

RE: Do it need to run 'nodetool upgradesstables' when updating from 2.0.9 to 2.1.19?

RE: Do it need to run 'nodetool upgradesstables' when updating from 2.0.9 to 2.1.19?

RE: Do it need to run 'nodetool upgradesstables' when updating from 2.0.9 to 2.1.19?

RE: [VOTE] Release Apache Cassandra 3.11.1

RE: [VOTE] Release Apache Cassandra 3.11.1

RE: [VOTE] Release Apache Cassandra 3.11.1

RE: [VOTE] Release Apache Cassandra 3.11.1

RE: [VOTE] Release Apache Cassandra 3.11.1

Cassandra 3.11.1 (snapshot build) - io.netty.util.Recycler$Stack memory leak

22 matches

Site Navigation

Mail list logo

Footer information