Ошибка таймаута при использовании драйвера Cassandra Java datastax [дубликат]
Вот еще один случай, когда сырые типы вас укусят:
public class StrangeClass<T> {
@SuppressWarnings("unchecked")
public <X> X getSomethingElse() {
return (X)"Testing something else!";
}
public static void main(String[] args) {
final StrangeClass<Object> withGeneric = new StrangeClass<>();
final StrangeClass withoutGeneric = new StrangeClass();
final String value1,
value2;
// Works
value1 = withGeneric.getSomethingElse();
// Produces compile error:
// incompatible types: java.lang.Object cannot be converted to java.lang.String
value2 = withoutGeneric.getSomethingElse();
}
}
Как уже упоминалось в принятом ответе, вы теряете всю поддержку дженериков в коде необработанного типа. Каждый параметр типа преобразуется в его стирание (которое в приведенном выше примере просто Object).
4 ответа
Хотя я не понимаю причину этой проблемы, я смог решить проблему, увеличив значение таймаута в файле conf / cassandra.yaml.
write_request_timeout_in_ms: 20000
Это координатор (так сервер), ожидающий подтверждения для записи.
-
1Привет Крис, как я могу отлаживать дальше, чтобы узнать, почему ACK не пришел? Я столкнулся с подобной проблемой и пытаюсь найти первопричину ... Спасибо. – opstalj 12 May 2016 в 06:11
Мы столкнулись с аналогичными проблемами на одном узле в кластере ESX с прикрепленным хранилищем SAN (который не рекомендуется datastax , но на данный момент у нас нет других опций).
Примечание: приведенные ниже настройки могут стать большим ударом для максимальной производительности, которую может достичь Cassandra, но мы выбрали стабильную систему с высокой производительностью.
Пока iostat -xmt 1 мы обнаружили высокое время w_await в то же время, когда произошли записи WriteTimeoutExceptions. Оказалось, что memtable не может быть записана на диск в настройках по умолчанию write_request_timeout_in_ms: 2000.
Мы значительно уменьшили размер memtable с 512 Мб (по умолчанию до 25% пространства кучи, что в нашем случае было 2 ГБ) до 32Mb:
# Total permitted memory to use for memtables. Cassandra will stop
# accepting writes when the limit is exceeded until a flush completes,
# and will trigger a flush based on memtable_cleanup_threshold
# If omitted, Cassandra will set both to 1/4 the size of the heap.
# memtable_heap_space_in_mb: 2048
memtable_offheap_space_in_mb: 32
Мы также немного увеличили тайм-аут записи до 3 секунд:
write_request_timeout_in_ms: 3000
Также убедитесь, что вы регулярно записываете на диск, если у вас высокие времена ожидания ввода-вывода:
#commitlog_sync: batch
#commitlog_sync_batch_window_in_ms: 2
#
# the other option is "periodic" where writes may be acked immediately
# and the CommitLog is simply synced every commitlog_sync_period_in_ms
# milliseconds.
commitlog_sync: periodic
commitlog_sync_period_in_ms: 10000
Эти настройки позволили памяти памяти оставаться маленькой и записываться часто. Исключения были решены, и мы пережили стресс-тесты, которые проводились в системе.
Стоит дважды проверить настройки вашего GC для Cassandra.
В моем случае я использовал семафор, чтобы дросселировать асинхронные записи и все еще (иногда) получать тайм-ауты.
Я использовал непригодные настройки GC, я использовал блок cassandra для удобства, который имел непредвиденные последствия работы с настройками по умолчанию VM. Следовательно, мы в конечном итоге запускаем хит-стоп-GC, что приведет к таймауту записи. Применяя те же настройки GC, что и текущее изображение докеры cassandra, и все в порядке.
Это может быть необычной причиной, но это помогло бы мне, поэтому, кажется, стоит записать здесь.
BatchStatementдля записи данных в Касснадре. Мой размер партии был 10000. После уменьшения размера партии я не столкнулся с исключением. Таким образом, возможно, вы пытаетесь загрузить много данных в Cassandra по одному запросу. – abi_pat 24 September 2015 в 13:25