Re: Cassandra 2.1: replace running node without streaming

[Jürgen Albersdorfer]

Cool, good to know. Do you know this is still true for 3.11.1?

> Am 03.02.2018 um 08:19 schrieb Oleksandr Shulgin 
> :
> 
> On 3 Feb 2018 02:42, "Kyrylo Lebediev"  wrote:
> Thanks, Oleksandr, 
> In my case I'll need to replace all nodes in the cluster (one-by-one), so 
> streaming will introduce perceptible overhead.
> My question is not about data movement/copy itself, but more about all this 
> token magic. 
> 
> Okay, let's say we stopped old node, moved data to new node.
> Once it's started with auto_bootstrap=false it will be added to the cluster 
> like an usual node, just skipping streaming stage, right?
> For a cluster with vnodes enabled, during addition of new node its token 
> ranges are calculated automatically by C* on startup.
> 
> So, how will C* know that this new node must be responsible for exactly the 
> same token ranges as the old node was?
> How would the rest of nodes in the cluster ('peers') figure out that old node 
> should be replaced in ring by the new one?
> Do you know about some  limitation for this process in case of C* 2.1.x with 
> vnodes enabled?
> 
> A node stores its tokens and host id in the system.local table. Next time it 
> starts up, it will use the same tokens as previously and the host id allows 
> the rest of the cluster to see that it is the same node and ignore the IP 
> address change. This happens regardless of auto_bootstrap setting.
> 
> Try "select * from system.local" to see what is recorded for the old node. 
> When the new node starts up it should log "Using saved tokens" with the list 
> of numbers. Other nodes should log something like "ignoring IP address 
> change" for the affected node addresses.
> 
> Be careful though, to make sure that you put the data directory exactly where 
> the new node expects to find it: otherwise it might just join as a brand new 
> one, allocating new tokens. As a precaution it helps to ensure that the 
> system user running the Cassandra process has no permission to create the 
> data directory: this should stop the startup in case of misconfiguration.
> 
> Cheers,
> --
> Alex
> 

Re: Cassandra 2.1: replace running node without streaming

[Oleksandr Shulgin]

On 3 Feb 2018 02:42, "Kyrylo Lebediev"  wrote:

Thanks, Oleksandr,
In my case I'll need to replace all nodes in the cluster (one-by-one), so
streaming will introduce perceptible overhead.
My question is not about data movement/copy itself, but more about all this
token magic.

Okay, let's say we stopped old node, moved data to new node.
Once it's started with auto_bootstrap=false it will be added to the cluster
like an usual node, just skipping streaming stage, right?

For a cluster with vnodes enabled, during addition of new node its token
ranges are calculated automatically by C* on startup.

So, how will C* know that this new node must be responsible for exactly the
same token ranges as the old node was?
How would the rest of nodes in the cluster ('peers') figure out that old
node should be replaced in ring by the new one?

Do you know about some  limitation for this process in case of C* 2.1.x
with vnodes enabled?


A node stores its tokens and host id in the system.local table. Next time
it starts up, it will use the same tokens as previously and the host id
allows the rest of the cluster to see that it is the same node and ignore
the IP address change. This happens regardless of auto_bootstrap setting.

Try "select * from system.local" to see what is recorded for the old node.
When the new node starts up it should log "Using saved tokens" with the
list of numbers. Other nodes should log something like "ignoring IP address
change" for the affected node addresses.

Be careful though, to make sure that you put the data directory exactly
where the new node expects to find it: otherwise it might just join as a
brand new one, allocating new tokens. As a precaution it helps to ensure
that the system user running the Cassandra process has no permission to
create the data directory: this should stop the startup in case of
misconfiguration.

Cheers,
--
Alex

Re: Cassandra 2.1: replace running node without streaming

[Kyrylo Lebediev]

Thanks, Oleksandr,
In my case I'll need to replace all nodes in the cluster (one-by-one), so 
streaming will introduce perceptible overhead.
My question is not about data movement/copy itself, but more about all this 
token magic.

Okay, let's say we stopped old node, moved data to new node.
Once it's started with auto_bootstrap=false it will be added to the cluster 
like an usual node, just skipping streaming stage, right?

For a cluster with vnodes enabled, during addition of new node its token ranges 
are calculated automatically by C* on startup.

So, how will C* know that this new node must be responsible for exactly the 
same token ranges as the old node was?
How would the rest of nodes in the cluster ('peers') figure out that old node 
should be replaced in ring by the new one?

Do you know about some  limitation for this process in case of C* 2.1.x with 
vnodes enabled?

Regards,
Kyrill


From: Oleksandr Shulgin 
Sent: Friday, February 2, 2018 4:26:30 PM
To: User
Subject: Re: Cassandra 2.1: replace running node without streaming

On Fri, Feb 2, 2018 at 3:15 PM, Kyrylo Lebediev 
mailto:kyrylo_lebed...@epam.com>> wrote:

Hello All!

I've got a pretty standard task - to replace a running C* node [version 2.1.15, 
vnodes=256, Ec2Snitch] (IP address will change after replacement, have no 
control over it).

There are 2 ways stated in C* documentation how this can be done:

1) Add a new node, than 'nodetool decommission' [ = 2 data streaming + 2 token 
range recalculations],

2) Stop the node then replace it by setting -Dcassandra.replace_address [ = 1 
data streaming]
Unfortunately, both these methods imply data streaming.

Is there a supported solution how to replace a live healthy node without data 
streaming / bootstrapping?
Something like: "Stop old node, copy data to new node, start new node with 
auto_bootstrap=false etc..."

On EC2, if you're using EBS it's pretty easy: drain and stop the old node, 
attach the volume to the new one and start it.
If not using EBS, then you have to copy the data to the new node before it is 
started.


I was able to find a couple manuals on the Internet, like this one: 
http://engineering.mydrivesolutions.com/posts/cassandra_nodes_replacement/, but 
not having understanding of C* internals, I don't know if such hacks are safe.

More or less like that: rsync while the old node is still running, then stop 
the node and rsync again.

But given all the hassle, streaming with replace_address doesn't sound too 
costly to me.

Cheers,
--
Alex

Re: unable to start cassandra 3.11.1

[Jon Haddad]

Java 9 is a significantly larger issue, see CASSANDRA-9608.

> On Feb 2, 2018, at 8:49 AM, Kant Kodali  wrote:
> 
> When you say latest Java runtime you mean does it work with Java 9 as well?
> 
> On Fri, Feb 2, 2018 at 5:02 AM, Sam Tunnicliffe  > wrote:
> I've actually just committed the fix for this to the 3.11 and trunk branches, 
> so if you desperately need a compatible build you can make build from those 
> branches.
> As I mentioned on the JIRA, I expect we'll move to a release vote very soon, 
> so hopefully should have a 3.11.2 release with this fix shortly.
> 
> 
> On 2 February 2018 at 12:19, Marcus Haarmann  > wrote:
> you can try to checkout https://github.com/beobal/cassandra/tree/14173-3.11 
> 
> and compile yourself a compatible version (unreleased), in case you are bound 
> to 
> the latest java runtime for any reason.
> 
> Marcus Haarmann
> 
> Von: "Kant Kodali" mailto:k...@peernova.com>>
> An: "user" mailto:user@cassandra.apache.org>>
> Gesendet: Donnerstag, 1. Februar 2018 23:45:06
> Betreff: Re: unable to start cassandra 3.11.1
> 
> Ok I saw the ticket looks like this java version "1.8.0_162" wont work!
> 
> On Thu, Feb 1, 2018 at 2:43 PM, Kant Kodali  > wrote:
> Hi Justin,
> I am using 
> 
> java version "1.8.0_162"
> Java(TM) SE Runtime Environment (build 1.8.0_162-b12)
> 
> Thanks!
> 
> On Thu, Feb 1, 2018 at 2:40 PM, Justin Cameron  > wrote:
> Unfortunately C* 3.11.1 is incompatible with the latest version of Java. 
> You'll need to either downgrade to Java 1.8.0.151-5 or wait for C* 3.11.2 
> (see https://issues.apache.org/jira/browse/CASSANDRA-14173 
>  for details)
> 
> On Fri, 2 Feb 2018 at 09:35 Kant Kodali  > wrote:
> Hi All,
> I am unable to start cassandra 3.11.1. Below is the stack trace. 
> 
> Exception (java.lang.AbstractMethodError) encountered during startup: 
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> java.lang.AbstractMethodError: 
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at 
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> at 
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> at 
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> at 
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> at 
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> ERROR 22:33:49 Exception encountered during startup
> java.lang.AbstractMethodError: 
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at 
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
>  ~[na:1.8.0_162]
> at 
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
>  ~[na:1.8.0_162]
> at 
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
>  ~[na:1.8.0_162]
> at 
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
>  [apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188) 
> [apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
>  [apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689) 
> [apache-cassandra-3.11.1.jar:3.11.1]
> -- 
> Justin Cameron
> Senior Software Engineer
> 
> 
> 
>  
> 
> This email has been sent on behalf of Instaclustr Pty. Limited (Australia) 
> and Instaclustr Inc (USA).
> 
> This email and any attachments may contain confidential and legally 
> privileged information.  If you are not the intended recipient, do not copy 
> or disclose its content, but please reply to this email immediately an

Re: unable to start cassandra 3.11.1

[Kant Kodali]

When you say latest Java runtime you mean does it work with Java 9 as well?

On Fri, Feb 2, 2018 at 5:02 AM, Sam Tunnicliffe  wrote:

> I've actually just committed the fix for this to the 3.11 and trunk
> branches, so if you desperately need a compatible build you can make build
> from those branches.
> As I mentioned on the JIRA, I expect we'll move to a release vote very
> soon, so hopefully should have a 3.11.2 release with this fix shortly.
>
>
> On 2 February 2018 at 12:19, Marcus Haarmann 
> wrote:
>
>> you can try to checkout https://github.com/be
>> obal/cassandra/tree/14173-3.11
>> and compile yourself a compatible version (unreleased), in case you are
>> bound to
>> the latest java runtime for any reason.
>>
>> Marcus Haarmann
>>
>> --
>> *Von: *"Kant Kodali" 
>> *An: *"user" 
>> *Gesendet: *Donnerstag, 1. Februar 2018 23:45:06
>> *Betreff: *Re: unable to start cassandra 3.11.1
>>
>> Ok I saw the ticket looks like this java version "1.8.0_162" wont work!
>>
>> On Thu, Feb 1, 2018 at 2:43 PM, Kant Kodali  wrote:
>>
>>> Hi Justin,
>>> I am using
>>>
>>> java version "1.8.0_162"
>>>
>>> Java(TM) SE Runtime Environment (build 1.8.0_162-b12)
>>>
>>>
>>> Thanks!
>>>
>>> On Thu, Feb 1, 2018 at 2:40 PM, Justin Cameron 
>>> wrote:
>>>
 Unfortunately C* 3.11.1 is incompatible with the latest version of
 Java. You'll need to either downgrade to Java 1.8.0.151-5 or wait for C*
 3.11.2 (see https://issues.apache.org/jira/browse/CASSANDRA-14173 for
 details)

 On Fri, 2 Feb 2018 at 09:35 Kant Kodali  wrote:

> Hi All,
> I am unable to start cassandra 3.11.1. Below is the stack trace.
>
> Exception (java.lang.AbstractMethodError) encountered during startup: 
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> java.lang.AbstractMethodError: 
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at 
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> at 
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> at 
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> at 
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> at 
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> ERROR 22:33:49 Exception encountered during startup
> java.lang.AbstractMethodError: 
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at 
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
>  ~[na:1.8.0_162]
> at 
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
>  ~[na:1.8.0_162]
> at 
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
>  ~[na:1.8.0_162]
> at 
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
>  [apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
>  [apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
>  [apache-cassandra-3.11.1.jar:3.11.1]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
>  [apache-cassandra-3.11.1.jar:3.11.1]
>
> --


 *Justin Cameron*Senior Software Engineer


 


 This email has been sent on behalf of Instaclustr Pty. Limited
 (Australia) and Instaclustr Inc (USA).

 This email and any attachments may contain confidential and legally
 privileged information.  If you are not the intended recipient, do not copy
 or disclose its content, but please reply to this email immediately and
 highlight the error to the sender and then immediately delete the message.

>>>
>>>

Re: Cassandra 2.1: replace running node without streaming

[Oleksandr Shulgin]

On Fri, Feb 2, 2018 at 3:15 PM, Kyrylo Lebediev 
wrote:

> Hello All!
>
> I've got a pretty standard task - to replace a running C* node [version
> 2.1.15, vnodes=256, Ec2Snitch] (IP address will change after replacement,
> have no control over it).
>
> There are 2 ways stated in C* documentation how this can be done:
>
> 1) Add a new node, than 'nodetool decommission' [ = 2 data streaming + 2
> token range recalculations],
>
> 2) Stop the node then replace it by setting -Dcassandra.replace_address [
> = 1 data streaming]
> Unfortunately, both these methods imply data streaming.
>
> Is there a supported solution how to replace a live healthy node without
> data streaming / bootstrapping?
> Something like: "Stop old node, copy data to new node, start new node with
> auto_bootstrap=false etc..."
>

On EC2, if you're using EBS it's pretty easy: drain and stop the old node,
attach the volume to the new one and start it.
If not using EBS, then you have to copy the data to the new node before it
is started.


> I was able to find a couple manuals on the Internet, like this one:
> http://engineering.mydrivesolutions.com/posts/cassandra_nodes_replacement/,
> but not having understanding of C* internals, I don't know if such hacks
> are safe.
>

More or less like that: rsync while the old node is still running, then
stop the node and rsync again.

But given all the hassle, streaming with replace_address doesn't sound too
costly to me.

Cheers,
--
Alex

Cassandra 2.1: replace running node without streaming

[Kyrylo Lebediev]

Hello All!

I've got a pretty standard task - to replace a running C* node [version 2.1.15, 
vnodes=256, Ec2Snitch] (IP address will change after replacement, have no 
control over it).

There are 2 ways stated in C* documentation how this can be done:

1) Add a new node, than 'nodetool decommission' [ = 2 data streaming + 2 token 
range recalculations],

2) Stop the node then replace it by setting -Dcassandra.replace_address [ = 1 
data streaming]
Unfortunately, both these methods imply data streaming.

Is there a supported solution how to replace a live healthy node without data 
streaming / bootstrapping?
Something like: "Stop old node, copy data to new node, start new node with 
auto_bootstrap=false etc..."

I was able to find a couple manuals on the Internet, like this one: 
http://engineering.mydrivesolutions.com/posts/cassandra_nodes_replacement/, but 
not having understanding of C* internals, I don't know if such hacks are safe.


Regards,

Kyrill

Re: unable to start cassandra 3.11.1

[Sam Tunnicliffe]

I've actually just committed the fix for this to the 3.11 and trunk
branches, so if you desperately need a compatible build you can make build
from those branches.
As I mentioned on the JIRA, I expect we'll move to a release vote very
soon, so hopefully should have a 3.11.2 release with this fix shortly.


On 2 February 2018 at 12:19, Marcus Haarmann 
wrote:

> you can try to checkout https://github.com/beobal/cassandra/tree/14173-3.
> 11
> and compile yourself a compatible version (unreleased), in case you are
> bound to
> the latest java runtime for any reason.
>
> Marcus Haarmann
>
> --
> *Von: *"Kant Kodali" 
> *An: *"user" 
> *Gesendet: *Donnerstag, 1. Februar 2018 23:45:06
> *Betreff: *Re: unable to start cassandra 3.11.1
>
> Ok I saw the ticket looks like this java version "1.8.0_162" wont work!
>
> On Thu, Feb 1, 2018 at 2:43 PM, Kant Kodali  wrote:
>
>> Hi Justin,
>> I am using
>>
>> java version "1.8.0_162"
>>
>> Java(TM) SE Runtime Environment (build 1.8.0_162-b12)
>>
>>
>> Thanks!
>>
>> On Thu, Feb 1, 2018 at 2:40 PM, Justin Cameron 
>> wrote:
>>
>>> Unfortunately C* 3.11.1 is incompatible with the latest version of Java.
>>> You'll need to either downgrade to Java 1.8.0.151-5 or wait for C* 3.11.2
>>> (see https://issues.apache.org/jira/browse/CASSANDRA-14173 for details)
>>>
>>> On Fri, 2 Feb 2018 at 09:35 Kant Kodali  wrote:
>>>
 Hi All,
 I am unable to start cassandra 3.11.1. Below is the stack trace.

 Exception (java.lang.AbstractMethodError) encountered during startup: 
 org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
 java.lang.AbstractMethodError: 
 org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
 at 
 javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
 at 
 javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
 at 
 javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
 at 
 org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
 at 
 org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
 at 
 org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
 at 
 org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
 at 
 org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
 ERROR 22:33:49 Exception encountered during startup
 java.lang.AbstractMethodError: 
 org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
 at 
 javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
  ~[na:1.8.0_162]
 at 
 javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
  ~[na:1.8.0_162]
 at 
 javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
  ~[na:1.8.0_162]
 at 
 org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
  ~[apache-cassandra-3.11.1.jar:3.11.1]
 at 
 org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
  [apache-cassandra-3.11.1.jar:3.11.1]
 at 
 org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
  [apache-cassandra-3.11.1.jar:3.11.1]
 at 
 org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
  [apache-cassandra-3.11.1.jar:3.11.1]
 at 
 org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
  [apache-cassandra-3.11.1.jar:3.11.1]

 --
>>>
>>>
>>> *Justin Cameron*Senior Software Engineer
>>>
>>>
>>> 
>>>
>>>
>>> This email has been sent on behalf of Instaclustr Pty. Limited
>>> (Australia) and Instaclustr Inc (USA).
>>>
>>> This email and any attachments may contain confidential and legally
>>> privileged information.  If you are not the intended recipient, do not copy
>>> or disclose its content, but please reply to this email immediately and
>>> highlight the error to the sender and then immediately delete the message.
>>>
>>
>>
>

Re: unable to start cassandra 3.11.1

[Marcus Haarmann]

you can try to checkout https://github.com/beobal/cassandra/tree/14173-3.11 
and compile yourself a compatible version (unreleased), in case you are bound 
to 
the latest java runtime for any reason. 

Marcus Haarmann 


Von: "Kant Kodali"  
An: "user"  
Gesendet: Donnerstag, 1. Februar 2018 23:45:06 
Betreff: Re: unable to start cassandra 3.11.1 

Ok I saw the ticket looks like this java version "1.8.0_162" wont work! 

On Thu, Feb 1, 2018 at 2:43 PM, Kant Kodali < [ mailto:k...@peernova.com | 
k...@peernova.com ] > wrote: 



Hi Justin, 
I am using 

java version "1.8.0_162" 


Java(TM) SE Runtime Environment (build 1.8.0_162-b12) 




Thanks! 

On Thu, Feb 1, 2018 at 2:40 PM, Justin Cameron < [ 
mailto:jus...@instaclustr.com | jus...@instaclustr.com ] > wrote: 

BQ_BEGIN

Unfortunately C* 3.11.1 is incompatible with the latest version of Java. You'll 
need to either downgrade to Java 1.8.0.151-5 or wait for C* 3.11.2 (see [ 
https://issues.apache.org/jira/browse/CASSANDRA-14173 | 
https://issues.apache.org/jira/browse/CASSANDRA-14173 ] for details) 

On Fri, 2 Feb 2018 at 09:35 Kant Kodali < [ mailto:k...@peernova.com | 
k...@peernova.com ] > wrote: 

BQ_BEGIN

Hi All, 
I am unable to start cassandra 3.11.1. Below is the stack trace. 

Exception (java.lang.AbstractMethodError) encountered during startup: 
org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
java.lang.AbstractMethodError: 
org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
at 
javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
at 
javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
at 
javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
at 
org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
at 
org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
at 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
at 
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
ERROR 22:33:49 Exception encountered during startup
java.lang.AbstractMethodError: 
org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
at 
javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
 ~[na:1.8.0_162]
at 
javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
 ~[na:1.8.0_162]
at 
javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
 ~[na:1.8.0_162]
at 
org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
 ~[apache-cassandra-3.11.1.jar:3.11.1]
at 
org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
 [apache-cassandra-3.11.1.jar:3.11.1]
at 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188) 
[apache-cassandra-3.11.1.jar:3.11.1]
at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600) 
[apache-cassandra-3.11.1.jar:3.11.1]
at 
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689) 
[apache-cassandra-3.11.1.jar:3.11.1] 



-- 


Justin Cameron 
Senior Software Engineer 




[ https://www.instaclustr.com/ ] 


This email has been sent on behalf of Instaclustr Pty. Limited (Australia) and 
Instaclustr Inc (USA). 

This email and any attachments may contain confidential and legally privileged 
information. If you are not the intended recipient, do not copy or disclose its 
content, but please reply to this email immediately and highlight the error to 
the sender and then immediately delete the message. 

BQ_END



BQ_END

Re: Setting min_index_interval to 1?

[Hannu Kröger]

Wouldn’t that still try to read the index on the disk? So you would just 
potentially have all keys on the memory and on the disk and reading would first 
happen in memory and then on the disk and only after that you would read the 
sstable.

So you wouldn’t gain much, right?

Hannu

> On 2 Feb 2018, at 02:25, Nate McCall  wrote:
> 
> 
> Another was the crazy idea I started with of setting min_index_interval to 1. 
> My guess was that this would cause it to read all index entries, and 
> effectively have them all cached permanently. And it would read them straight 
> out of the SSTables on every restart. Would this work? Other than probably 
> causing a really long startup time, are there issues with this?
> 
> 
> I've never tried that. It sounds like you understand the potential impact on 
> memory and startup time. If you have the data in such a way that you can 
> easily experiment, I would like to see a breakdown of the impact on response 
> time vs. memory usage as well as where the point of diminishing returns is on 
> turning this down towards 1 (I think there will be a sweet spot somewhere). 
>