Якшибаев Данил, ДЗ №2

[gogy4]

No description provided.

[AMEST]

Тут сразу два типа ошибки:

1. Фиксируется не время затраченное на текущий запрос, а общее прошедшее время. Т.е. даже для самой быстрой реплики, запрос к которой выполнялся (условно 15мс), время будет записано не 15мс, а все время выполнения от начала (т.е. суммирование как минимум всех timeoutPerReplica).
   Поэтому третья реплика будь она самой быстрой "на диком западе" не окажется первой в списке при повторной отправке запрос через этот клиент
2. Даже если был бы локальный таймер под текущий запрос, при таймауте мы не должны записывать посто время таймаута, а хотя бы штрафное время для понижения реплики в списке. При ошибке так же, время выполнения будет минимальным и реплика незаслужено запишется "как самая быстрая). В случае ошибок должно быть записано высокое штрафное время с гарантированным понижением в списке при сортировке

[AMEST]

А здесь уже количество ошибок выросло до трех:

1. Использование общего таймера, а не индивидуального под каждый запрос — некорректная статистика которая по факту больше вредит, чем помогает
2. Записывание времени всегда без учета, что произошел таймаут (не знаем реальное время выполнения) и не учитывается ошибка запроса, что может записать некорректное малое значение, что поднимет реплику в списке реплик
3. Привязка обновления статистики к значению replicaAddress из foreach. У нас в completedTask может вернуться как таймаут, так и Задачи с запросами с предыдущих итераций. В итоге в completedTask может вернуться запрос к replicaAddress1, а у нас в foreach уже replicaAddress3, и мы запишем статистику времени выполнения replicaAddress1 в ячейку для replicaAddress3

[AMEST]

А в цикле ожидания завершения задач мы в принципе не запишем никакую статистику. В итоге статистика у нас не имеет ничего общего с реальностью