cpp-driver & CONSISTENCY level settings

[Vaclav Krpec]

Hello everybody,

I've got trouble setting CONSISTENCY level via C++ driver (GitHub clone).
I'm using Cassandra 2.1.8.

I've tried to set CONSISTENCY via a separate statement "CONSISTENCY ALL;",
that gives me CassError of 0x02002000 (a syntax error).

I've also tried to set consistency per statement (a SELECT); sending such a statement
results in CassError of 0x0100000a (a protocol error).

In the driver log, I can only see TRACE-level messages announcing consumption
of CQL_OPCODE_ERROR type messages from the server.
Upon connection establishing, a WARN message informs me that protocol v3 is used.

I seem to be at my wits' end, here; thanks for any suggestions.

Regards,

vencik

[Michael Fero]

Vencik,

> I've tried to set CONSISTENCY via a separate statement "CONSISTENCY ALL;",
> that gives me CassError of 0x02002000 (a syntax error).

It looks like you are trying to use CQLSH commands (http://docs.datastax.com/en/cql/3.1/cql/cql_reference/consistency_r.html) through the C/C++ driver. What you will need to do instead is set the consistency level on the CassStatement object.

> I've also tried to set consistency per statement (a SELECT); sending such a statement
> results in CassError of 0x0100000a (a protocol error).

In this scenario I am going to assume that you are trying to set the consistency level via the SELECT statement in the USING clause (e.g. USING CONSISTENCY ALL). If that is the case then this is CQL2 syntax and is not valid in CQL3; consistency levels starting in CQL3 are set at the protocol level.

For both of the above issues you will want to create a CassStatement object and set the consistency level on the statement before it is executed on the server; http://datastax.github.io/cpp-driver/topics/basics/consistency.

> In the driver log, I can only see TRACE-level messages announcing consumption
> of CQL_OPCODE_ERROR type messages from the server.
> Upon connection establishing, a WARN message informs me that protocol v3 is used.

I am going to assume that you are using the current HEAD or 2.2.0-beta1 release of the driver. If this is the case, then the message is completely harmless since the highest protocol level for Cassandra v2.1.8 is v3 and HEAD/2.2.0-beta1 defaults to protocol v4; the driver automatically downgrades to the highest supported protocol available by the Cassandra server.

Good luck!

~Fero

[Vaclav Krpec]

Hi Fero,

thanks for your comment.
In the 2nd scenario, I DON'T use the USING clause; I just call cass_statement_set_consistency function to set the consist. level for a particular CassStatement object; with the result described... :-(

I suppose that's the way it should be done (I tried the 1st scenario out of desperation when I found out that the above doesn't work).

Thanks,

vencik



Dne úterý 20. října 2015 15:14:58 UTC+2 Michael Fero napsal(a):

[Alex Popescu]

On Tuesday, October 20, 2015 at 7:33:56 AM UTC-7, Vaclav Krpec wrote:
> Hi Fero,
>
> thanks for your comment.
> In the 2nd scenario, I DON'T use the USING clause; I just call cass_statement_set_consistency function to set the consist. level for a particular CassStatement object; with the result described... :-(
>

Can you share the code snippet you are using for setting the consistency on a statement?

thanks

Alex Popescu | @al3xandru
Sen. Product Manager @ DataStax

[Vaclav Krpec]

Hello Alex,

see the function below.

Thanks,

vencik


bool Cassandra_client::query(
const std::string & q_str,
const CassResult ** result,
CassConsistency consist)
{
CassStatement * stmt = NULL;
CassFuture * exec = NULL;

CassError status = CASS_OK; // optimistic assumption

stmt = cass_statement_new(q_str.c_str(), 0);
if (NULL == stmt)
throw std::runtime_error(
"libedge_rank::Cassandra_client: failed to compile query statement");

do { // pragmatic do ... while (0) loop to allow breaks
// Set query consistency
status = cass_statement_set_consistency(stmt, consist);
if (CASS_OK != status) {
error("Failed to set query consistency level: %d: %s",
status, cass_error_desc(status));

break;
}

// Execute query (synchronously)
exec = cass_session_execute(m_session, stmt);
cass_future_wait(exec);

status = cass_future_error_code(exec);
if (CASS_OK != status) {
error("Failed to execute query '%s': %d: %s",
q_str.c_str(), status, cass_error_desc(status));

break;
}

// Query executed OK
debug("Query '%s' executed successfully", q_str.c_str());

if (NULL != result) *result = cass_future_get_result(exec);

} while (0); // end of pragmatic loop

if (NULL != exec) cass_future_free(exec);
if (NULL != stmt) cass_statement_free(stmt);
return CASS_OK == status;
}



Dne středa 21. října 2015 7:16:53 UTC+2 Alex Popescu napsal(a):

[Michael Penick]

What version of the driver are you using?

[Vaclav Krpec]

I'm on https://github.com/datastax/cpp-driver master HEAD.

[Michael Penick]

In you original email you said you were experiencing "0x0100000a". This is a "No hosts available" error not a "protocol error". It doesn't seem to be a consistency issue.

printf("Error: %s\n", cass_error_desc(0x0100000a));

The preceding prints: Error: No hosts available

I'm not sure why you're getting that error. Could you print the error from future using: cass_future_error_message()?

Mike

On Thu, Oct 22, 2015 at 9:16 AM, Vaclav Krpec <venci...@gmail.com> wrote:

I'm on https://github.com/datastax/cpp-driver master HEAD.

To unsubscribe from this group and stop receiving emails from it, send an email to cpp-driver-us...@lists.datastax.com.

[Vaclav Krpec]

Hi Michael,

well, I'm not altogether that sure.
If you take a look at CASS_ERROR_MAP in cassandra.h, you'll find out that both CASS_ERROR_LIB_NO_HOSTS_AVAILABLE and CASS_ERROR_SERVER_PROTOCOL_ERROR are defined as 10 (well, the former is, the latter is 0x000A... ;-)
Since I've no problem connecting to the cluster, I merely presumed that it's actually a protocol error in this case.

Anyway, I'll try to print the error using cass_future_error_message... TBC

Thanks,

vencik



Dne čtvrtek 22. října 2015 19:26:36 UTC+2 Michael Penick napsal(a):

[Vaclav Krpec]

... ah, right, the CASS_ERROR_SOURCE_LIB bit is set... So it actually would be "No hosts available".
Hmm... Weird indeed.


Dne pátek 23. října 2015 9:00:15 UTC+2 Vaclav Krpec napsal(a):

[Vaclav Krpec]

Mike,

got the following reason from the future:
"All hosts in current policy attempted and were either unavailable or failed".

Still, it only happens with ALL consistency; if I call the function above with CASS_CONSISTENCY_ONE, the statement execution is successful.
Note that I run it on a single-node cluster...

Thanks for help,

vencik

[Vaclav Krpec]

Ah, got it in the end.
Replication factor was set inconsistently in the test environment (2).

Thanks for help, everybody.

Best regards

vencik