[MDEV-535] Cassandra SE: Internal error: 'TimedOutException: Default TException errors Created: 2012-09-14 Updated: 2014-04-15 Resolved: 2014-04-15 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Sergei Petrunia | Assignee: | Sergei Petrunia |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||
| Description |
|
It looks like CassandraSE has very small timeouts. Any operation that takes longer than a few seconds ends like this: MariaDB [dbt3]> delete from customer ; I added calls to s->setConnTimeout(1000*1000); on a created TSocket object s, but this didn't seem to help. This needs to be investigated. |
| Comments |
| Comment by Sergei Petrunia [ 2012-09-21 ] |
|
Dunno if this related, but asynchronous client also experiences timeout failures. They seem to happen at random, examples: on_batch_mutate_fail obj 1 reason TimedOutException: Default TException. at 1181256 rows Need to find that timeout setting. And may be even add reconnect/retry functionality. |
| Comment by Sergei Petrunia [ 2012-09-21 ] |
|
$8 = (org::apache::cassandra::TimedOutException *) 0x7f19a43ea668 Interesting thing: this is not an exception from communication between mysqld process and cassandra. This exception is defined in cassandra.thrift file: /** RPC timeout was exceeded. either a node failed mid-operation, or load was too high, or the requested op was too large. */ and it was passed to us from inside Cassandra! |
| Comment by Sergei Petrunia [ 2014-04-15 ] |
|
Cassandra by its design may return timeouts, and in that case the user is expected to retry the operation. We could have better retry logic in Cassandra SE, if there was enough interest in making use of it. |