wait_for_responses() is waiting 10ms between sending messages, if not all messages are done

[mykaul]

See the following snippet:

            if messages_sent == len(msgs):
                break
            else:
                if timeout is not None:
                    timeout -= 0.01
                    if timeout <= 0.0:
                        raise OperationTimedOut()
                time.sleep(0.01)

That means that if not all messages were sent, we wait a fixed 10ms(!) and try again. That's a bit long and wasteful. It penalizes sending some queries since some other queries were delayed, and by 10ms, which is quite a bit.
Unsure if it is a real issue or not. I see it's used for metadata, for example:

        queries = [
            QueryMessage(query=maybe_add_timeout_to_query(self._SELECT_KEYSPACES, self.metadata_request_timeout),
                         fetch_size=fetch_size, consistency_level=cl),
            QueryMessage(query=maybe_add_timeout_to_query(self._SELECT_TABLES, self.metadata_request_timeout),
                         fetch_size=fetch_size, consistency_level=cl),
            QueryMessage(query=maybe_add_timeout_to_query(self._SELECT_COLUMNS, self.metadata_request_timeout),
                         fetch_size=fetch_size, consistency_level=cl),
            QueryMessage(query=maybe_add_timeout_to_query(self._SELECT_TYPES, self.metadata_request_timeout),
                         fetch_size=fetch_size, consistency_level=cl),
            QueryMessage(query=maybe_add_timeout_to_query(self._SELECT_FUNCTIONS, self.metadata_request_timeout),
                         fetch_size=fetch_size, consistency_level=cl),
            QueryMessage(query=maybe_add_timeout_to_query(self._SELECT_AGGREGATES, self.metadata_request_timeout),
                         fetch_size=fetch_size, consistency_level=cl),
            QueryMessage(query=maybe_add_timeout_to_query(self._SELECT_TRIGGERS, self.metadata_request_timeout),
                         fetch_size=fetch_size, consistency_level=cl),
            QueryMessage(query=maybe_add_timeout_to_query(self._SELECT_INDEXES, self.metadata_request_timeout),
                         fetch_size=fetch_size, consistency_level=cl),
            QueryMessage(query=maybe_add_timeout_to_query(self._SELECT_VIEWS, self.metadata_request_timeout),
                         fetch_size=fetch_size, consistency_level=cl),
        ]

        ((ks_success, ks_result),
         (table_success, table_result),
         (col_success, col_result),
         (types_success, types_result),
         (functions_success, functions_result),
         (aggregates_success, aggregates_result),
         (triggers_success, triggers_result),
         (indexes_success, indexes_result),
         (views_success, views_result)) = self.connection.wait_for_responses(
             *queries, timeout=self.timeout, fail_on_error=False
        )

which means that if some of those useless queries will be delayed, everything (?) will be, which is a shame.

[Lorak-mmk]

Isn't this sleep only happening if we exhausted available request ids on a connection? This should be extreme enough scenario to warrant some delay, no?

[mykaul]

Isn't this sleep only happening if we exhausted available request ids on a connection? This should be extreme enough scenario to warrant some delay, no?

It wasn't clear to me from the code under which conditions a send might fail to complete. I suspect it is rare and benign, or we'd had more complaints about it. Maybe a log (warn?) might have helped here.