Reputation: 345
We observe following error consistently in CentOS while trying to drop JanusGraph graph. We are using Janusgraph version 0.2.0 and 3 node Cassandra cluster as backend. However the same command works in Ubuntu.
NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="7"
gremlin> JanusGraphFactory.drop(g);
13:55:59 WARN com.datastax.driver.core.RequestHandler - Not retrying statement because it is not idempotent (this message will be logged only once).
Note that this version of the driver changes the default retry behavior for non-idempotent statements: they won't be automatically retried anymore.
The driver marks statements non-idempotent by default, so you should explicitly call setIdempotent(true) if your statements are safe to retry.
com.datastax.driver.core.exceptions.OperationTimedOutException: [/xxx.xxx.xxx.x:9042] Timed out waiting for server response
at com.datastax.driver.core.exceptions.OperationTimedOutException.copy(OperationTimedOutException.java:44)
at com.datastax.driver.core.exceptions.OperationTimedOutException.copy(OperationTimedOutException.java:26)
at com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:37)
at com.datastax.driver.core.DefaultResultSetFuture.getUninterruptibly(DefaultResultSetFuture.java:245)
at com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:68)
at org.janusgraph.diskstorage.cql.CQLStoreManager.clearStorage(CQLStoreManager.java:334)
at org.janusgraph.diskstorage.Backend.clearStorage(Backend.java:589)
at org.janusgraph.core.JanusGraphFactory.drop(JanusGraphFactory.java:216)
at org.janusgraph.core.JanusGraphFactory$drop$0.call(Unknown Source)
Any help is highly appreciated.
Thanks
Upvotes: 1
Views: 498
Reputation: 2932
While performing Cassandra operations (Batch execution- insert and update operations on two tables) using spark job I am getting "All host(s) tried for query failed - com. datastax. driver. core. OperationTimedOutException" error.
The most common cause of this is that Spark is able to issue write requests much more quickly than Cassandra can handle them. This can lead to GC issues and build up of hints. If this is the case with your application, try lowering the number of concurrent writes and the current batch size using the following options.
spark.cassandra.output.batch.size.rows spark.cassandra.output.concurrent.writes
or in versions of the Spark Cassandra Connector greater than or equal to 1.2.0 set
spark.cassandra.output.throughput_mb_per_sec
which will allow you to control the amount of data written to C* per Spark core per second.
you should not use BATCHES
This is not always true, the connector uses local token aware batches for faster reads and writes but this is tricky to get right in a custom app. In many cases async queries are better or just as good.
setReadTimeout
This is a DataStax java driver method. The connector takes care of this for you, no need to change it.
Upvotes: 2