default_timeout

[Laing, Michael]

I have been unable to get this to work with my writes. :-/

I set it to None at the session level, prepare a query, execute_async with parameters, and - when I press Cassandra hard on my Mac - some queries time out anyway (unless I use the newly fixed DowngradingConsistencyRetryPolicy).

I have not been able to figure out from the driver code where this goes wrong.

Michael

[Tyler Hobbs]

You're referring to OperationTimedOut exceptions, correct?   Other types of timeouts are controlled by cassandra.yaml (e.g. read_request_timeout_in_ms).

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

--
Tyler Hobbs
DataStax

[Laing, Michael]

Correct. As I understand it, I should be able to set Session.default_timeout = None and have it be honored.

[Tyler Hobbs]

Hmm, can you paste an example of the exception (and if you can, relevant logs at DEBUG)?  OperationTimedOut is also used in a couple of other places: new connection creation and some internal methods.  It's possible that those operations are what's actually timing out and the error message is confusing.

[Laing, Michael]

https://gist.github.com/michaelplaing/4b5947880f7ac6e79d08

There's the log of a run - as soon as it timed out I interrupted.

Also included is the version of bm_data_create.py I used to generate the log.

[Tyler Hobbs]

Thanks for the logs.  The exception here is a cassandra.WriteTimeout, which is raised when write requests exceed write_request_timeout_in_ms (set in cassandra.yaml).  You either want to raise that timeout or lower your rate of inserts.

I definitely need to make the docs on timeouts more clear.  There are two different types of timeouts:

1)  Session.default_timeout and the 'timeout' arg for session.execute() set an upper bound on the entire request and any retries.  This all happens within the driver.  If this timeout is hit, an OperationTimedOut exception is raised no matter what.
2)  Cassandra has its own set of timeouts that are configurable through cassandra.yaml, like write_request_timeout_in_ms.  These timeouts are enforced by the coordinator node.  If the coordinator sees that a request has exceeded one of those timeouts, it will respond to the driver with a WriteTimeout or ReadTimeout message.  At that point, the driver checks the RetryPolicy to see if it should retry the operation on another node.  It could do several of these retries before hitting the Session.default_timeout.  By default, it just re-raises the Write/ReadTimeout right away.

Does that clarify things?  I'll try to expand on that in the docs.

[Laing, Michael]

That's clear (now)!

Thanks!

ml