long timeout while waiting for futures

[Jean Giard]

Hi,
I am using the cassandra cpp driver in a new application and found out that sometimes a thread will be stuck waiting for a future while calling cass_future_error_code. The call usually time out after ~1 hour. I tried to reproduce this in a standalone binary with no luck so far.

I have a fair load on my application with ~25000 queries per second distributed among 20 thread.
I read about https://datastax-oss.atlassian.net/browse/CPP-162 which seems related but I don't understand if it is already fixed, or if it depends on my version on libuv. What of it ?

I think got around the problem by using cass_future_wait_timed but i'd rather let the driver handle it.

my driver version : git revision bfcfb85e1b5f23c192e15a2dc5a511faf0900b71 on branch 1.0
cassandra version : 2.1.2

[Michael Penick]

CPP-162 ended up not being a cpp-driver issue. There's a bad data race in libuv and it can cause the type of hanging you're running into. The fix ended being a PR I submitted to libuv, https://github.com/libuv/libuv/pull/50. It hasn't being merged yet (it may be time to get that pushed along) Unfortunately, it affects all versions of libuv, even the most current (v1.x).

Mike

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

[Jean Giard]

Thanks, i will check again when the fix is released then.

Also, do you have some bench/experiences with long running programs ? I noticed significant slowdown on query execution after running for an hour, while profiling indicates that cpu consumption of libcassandra / libuv increases regularly. However my query rate remains rather constant.
What bothers me is that the issue remains even if I drop the session and start a new one.
The performance issue disappear if I replace prepared statement binding with manual string replacement.

[Jean Giard]

Just a short update to say that all my problems were solved with the 1.0 GA release and libuv 1.x.
Good job :)