Re: AbstractMethodError from JMXServerUtils after update from Java 1.8.0_112 to 1.8.0_162

[Edward Ribeiro]

FYI, there's a patch coming soon to address this:
https://issues.apache.org/jira/browse/CASSANDRA-14173

Cheers,
Ed

On Thu, Jan 18, 2018 at 7:46 PM, Michael Shuler 
wrote:

> https://issues.apache.org/jira/browse/CASSANDRA-14173
>
> On 01/18/2018 03:29 PM, Stephen Rosenthal wrote:
> > Hi,
> >
> >
> >
> > I got the following error after updating my Cassandra system from Java
> > 1.8.0_112 to 1.8.0_162:
> >
> >
> >
> > 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;
> >
> >
> >
> > I did the usual Googling and here’s what I’ve concluded:
> >
> >   * Between Java 1.8.0_152 and 1.8.0_162, the interface
> > com.sun.jmx.remote.internal.RMIExporter was changed to add a 5^th
> > argument to the exportObject method. The class in a Sun “internal”
> > package so it probably wasn’t intended for use outside of the JDK.
> >   * Cassandra references RMIExporter in
> > org.apache.cassandra.utils.JMXServerUtils but uses only 4 arguments
> > in the exportObject method:
> > https://github.com/apache/cassandra/blob/cassandra-3.11/
> src/java/org/apache/cassandra/utils/JMXServerUtils.java
> >   * I was running on Cassandra 3.11 but I also tried 3.11.1 and the
> > problem remained.
> >
> >
> >
> > I couldn’t find anyone else reporting this bug so I must be doing
> > something different. Have others seen this bug? Or is it something
> > obvious, i.e. does Cassandra not support running on Java 1.8.0_162 yet?
> >
> >
> >
> > Thanks!
> >
> > Stephen
> >
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: user-h...@cassandra.apache.org
>
>

Re: Cassandra 3.11 fails to start with JDK8u162

[Edward Ribeiro]

Hello,

I have uploaded a couple of patches (targeting 3.6 to trunk) to address
https://issues.apache.org/jira/browse/CASSANDRA-14173 so that C* compiles
and runs on both JDK8u152 and JDK8u162. This patch still lacks review and
throughfully testing! So it can be fundamentally flawed and the best option
is just to really  avoid migrating to JDK8u162, as Sam correctly pointed
out, or a better solution pops up in the meantime.

Please, whenever you have time, let me know if it's incorrect or flawed so
that I can remove the attachments from the JIRA issue asap. Finally,
quoting Sam again: "we should identify a more stable solution & apply that
to both 3.11 and 4.0." Therefore, even if the patches make any sense, it's
a temporary workaround.

Regards,
Edward

On Fri, Jan 19, 2018 at 4:08 AM, Steinmaurer, Thomas <
thomas.steinmau...@dynatrace.com> wrote:

> Ben,
>
>
>
> at least 3.0.14 starts up fine for me with 8u162.
>
>
>
> Regards,
>
> Thomas
>
>
>
> *From:* Ben Wood [mailto:bw...@mesosphere.io]
> *Sent:* Donnerstag, 18. Jänner 2018 23:24
>
> *To:* user@cassandra.apache.org
> *Subject:* Re: Cassandra 3.11 fails to start with JDK8u162
>
>
>
> I'm correct in assuming 10091 didn't go into 3.0?
>
>
>
> On Thu, Jan 18, 2018 at 2:32 AM, Steinmaurer, Thomas <
> thomas.steinmau...@dynatrace.com> wrote:
>
> Sam,
>
>
>
> thanks for the confirmation. Going back to u152 then.
>
>
>
> Thomas
>
>
>
> *From:* li...@beobal.com [mailto:li...@beobal.com] *On Behalf Of *Sam
> Tunnicliffe
> *Sent:* Donnerstag, 18. Jänner 2018 10:16
> *To:* user@cassandra.apache.org
> *Subject:* Re: Cassandra 3.11 fails to start with JDK8u162
>
>
>
> This isn't (wasn't) a known issue, but the way that CASSANDRA-10091 was
> implemented using internal JDK classes means it was always possible that a
> minor JVM version change could introduce incompatibilities (CASSANDRA-2967
> is also relevant).
>
> We did already know that we need to revisit the way this works in 4.0 for
> JDK9 support (CASSANDRA-9608), so we should identify a more stable solution
> & apply that to both 3.11 and 4.0.
>
> In the meantime, downgrading to 152 is the only real option.
>
>
>
> I've opened https://issues.apache.org/jira/browse/CASSANDRA-14173 for
> this.
>
>
>
> Thanks,
>
> Sam
>
>
>
>
>
> On 18 January 2018 at 08:43, Nicolas Guyomar 
> wrote:
>
> Thank you Thomas for starting this thread, I'm having exactly the same
> issue on AWS EC2 RHEL-7.4_HVM-20180103-x86_64-2-Hourly2-GP2
> (ami-dc13a4a1)  I was starting to bang my head on my desk !
>
>
>
> So I'll try to downgrade back to 152 then !
>
>
>
>
>
>
>
> On 18 January 2018 at 08:34, Steinmaurer, Thomas <
> thomas.steinmau...@dynatrace.com> wrote:
>
> Hello,
>
>
>
> after switching from JDK8u152 to JDK8u162, Cassandra fails with the
> following stack trace upon startup.
>
>
>
> ERROR [main] 2018-01-18 07:33:18,804 CassandraDaemon.java:706 - 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.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
>
> at 
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
>
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
>
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
>
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
>
>
>
> Is this a known issue?
>
>
>
>
>
> 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
> 

Re: Cassandra - Spark - Flume: best architecture for log analytics.

[Edward Ribeiro]

Disclaimer: I have worked for DataStax.

Cassandra is fairly good for log analytics and has been used many places
for that (
https://www.usenix.org/conference/lisa14/conference-program/presentation/josephsen
). Of course, requirements vary from place to place, but it has been a good
fit. Spark and Cassandra have very nice integration, so a Spark worker will
usually read C* rows from a local node instead of bulk loading from remote
nodes, for example (see: https://www.youtube.com/watch?v=_gFgU3phogQ *)*

A third solution, as you asked for, would be:

3)  Aggregating logs using Flume and send the aggregations to one or more
topics on Kafka. Have Spark workers read from the topics, make some
computations and write the results in distinct tables in Cassandra. ( see
https://www.youtube.com/watch?v=GBOk7vh8OgU and
http://blog.sematext.com/2015/04/22/monitoring-stream-processing-tools-cassandra-kafka-and-spark/
 )

In fact, I guess 1) and 3) are good candidates for an architecture, so try
and see what fits best.

Regards,
Ed

On Thu, Jul 23, 2015 at 4:51 AM, Ipremyadav ipremya...@gmail.com wrote:

 Though DSE cassandra comes with hadoop integration, this is clearly is use
 case for hadoop.
 Any reason why cassandra is your first choice?



 On 23 Jul 2015, at 6:12 a.m., Pierre Devops pierredev...@gmail.com
 wrote:

 Cassandra is not very good at massive read/bulk read if you need to
 retrieve and compute a large amount of data on multiple machines using
 something like spark or hadoop (or you'll need to hack and process the
 sstable directly, something which is not natively supported, you'll have
 to hack your way)

 However, it's very good to store and retrieve them once they have been
 processed and sorted. That's why I would opt for solution 2) or for another
 solution which process data before inserting them in cassandra, and doesn't
 use cassandra as a temporary store.

 2015-07-23 2:04 GMT+02:00 Renato Perini renato.per...@gmail.com:

 Problem: Log analytics.

 Solutions:
1) Aggregating logs using Flume and storing the aggregations into
 Cassandra. Spark reads data from Cassandra, make some computations
 and write the results in distinct tables, still in Cassandra.
2) Aggregating logs using Flume to a sink, streaming data directly
 into Spark. Spark make some computations and store the results in Cassandra.
3) *** your solution ***

 Which is the best workflow for this task?
 I would like to setup something flexible enough to allow me to use batch
 processing and realtime streaming without major fuss.

 Thank you in advance.

Re: Second Cassandra users survey

[Edward Ribeiro]

+1 on co-processors.


Edward

Re: Facebook messaging and choice of HBase over Cassandra - what can we learn?

[Edward Ribeiro]

 Also I believe saying HBASE is consistent is not true. This can happen:
 Write to region server. - Region Server acknowledges client- write
 to WAL - region server fails = write lost

 I wonder how facebook will reconcile that. :)


Are you sure about that? Client writes to WAL before ack user?

According to these posts[1][2], if writing the record to the WAL fails the
whole operation must be considered a failure., so it would be nonsense
acknowledge clients before writing the lifeline. I hope any cloudera guy
explain this...

Besides that, you know that WAL is written to HDFS that takes care of
replication and fault tolerance, right? Of course, even so, there's a
window of inconsistency before the HLog is flushed to disk, but I don't
think you can dismiss this as not consistent. At most, you may classify it
as eventual consistent. :)

[1] http://www.larsgeorge.com/2009/10/hbase-architecture-101-storage.html
[2]
http://www.larsgeorge.com/2010/01/hbase-architecture-101-write-ahead-log.html

E. Ribeiro

Re: Implementing queues in Cassandra

[Edward Ribeiro]

Qsandra project aims to use Cassandra as a back-end to ActiveMQ (
http://github.com/ticktock/qsandra ).

On Sat, Jul 10, 2010 at 1:34 PM, Dodong Juan dodongj...@gmail.com wrote:

 Hi,


 Has anyone tried implementing queues in Cassandra?