Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-535

Cassandra SE: Internal error: 'TimedOutException: Default TException errors

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      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 ;
      ERROR 1928 (HY000): Internal error: 'TimedOutException: Default TException.'
      MariaDB [dbt3]> delete from lineitem ;
      ERROR 1928 (HY000): Internal error: 'TimedOutException: Default TException.'
      MariaDB [dbt3]> delete from nation ;
      ERROR 1928 (HY000): Internal error: 'TimedOutException: Default TException.'
      MariaDB [dbt3]> delete from orders ;

      I added calls to

      s->setConnTimeout(1000*1000);
      s->setRecvTimeout(1000*1000);
      s->setSendTimeout(1000*1000);

      on a created TSocket object s, but this didn't seem to help.

      This needs to be investigated.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

              Hide
              psergey Sergei Petrunia added a comment -

              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
              on_batch_mutate_fail obj 2 reason TimedOutException: Default TException. at 392616 rows
              on_batch_mutate_fail obj 1 reason TimedOutException: Default TException. at 343295 rows (9 reactor loops)

              Need to find that timeout setting. And may be even add reconnect/retry functionality.

              Show
              psergey Sergei Petrunia added a comment - 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 on_batch_mutate_fail obj 2 reason TimedOutException: Default TException. at 392616 rows on_batch_mutate_fail obj 1 reason TimedOutException: Default TException. at 343295 rows (9 reactor loops) Need to find that timeout setting. And may be even add reconnect/retry functionality.
              Hide
              psergey Sergei Petrunia added a comment -

              $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. */
              exception TimedOutException {
              }

              and it was passed to us from inside Cassandra!

              Show
              psergey Sergei Petrunia added a comment - $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. */ exception TimedOutException { } and it was passed to us from inside Cassandra!
              Hide
              psergey Sergei Petrunia added a comment -

              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.

              Show
              psergey Sergei Petrunia added a comment - 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.

                People

                • Assignee:
                  psergey Sergei Petrunia
                  Reporter:
                  psergey Sergei Petrunia
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  1 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:

                    Time Tracking

                    Estimated:
                    Original Estimate - Not Specified
                    Not Specified
                    Remaining:
                    Remaining Estimate - 0 minutes
                    0m
                    Logged:
                    Time Spent - 4 hours
                    4h