Со статусами пока обошелся малой кровью - добавил статус fail на случай когда диск(демон синхронизации) не имеет прав на доступ к своему локальному каталогу. Это особый статус - в нем демон ни на что не реагирует и ничего не делает - его можно только выключить.
Остальные статусы поделил на два лагеря - те что отвечают за состояние когда демон активен (условно - приконекчен к облаку): idle, busy, error, и когда он не активен (условно с облаком не соединен): none и no_net. Условно в последнюю группу входит и fault, но по сути этот статус стоит особняком от остальных, т.к. все остальные друг в друга могут переходить, fault - он всегда fault.
С таким делением статусов демон стал более полноценен:
1. может стартовать с отсутствующим локальным каталогом для синхронизации с облаком (создаст сам, если сможет)
2. имеет четкий статус соединен/не соединен
Попутно начал регулярно ловит ситуации подвисания одного из рабочих потоков в threadPoolExecutor. А так как оно там крутится и ничего наружу не выдает пришлось поднимать логгирование. Так что допилил наконец нормальное логгирование. Логгирование позволило выяснить что зависает получение статуса асинхронной операции. И выяснилось что таки да - там в обработчике у меня был слепой цикл если не получаю статус success. Оказалось, что можно получить и fail... а я эту ситуацию не обрабатывал, и получал зависающие навечно рабочие процессы в threadPoolExecutor-е.
То что я не мог вычислить этот кейс было в частности всязано с тем что я довольно мало возвращал из объекта Cloud(операции с облачным хранилищем). Пришлось допилить и этот объект что бы он по ошибке выдавал больше информации.
А это в свою очередь позволило раценить одну из ошибок как не ошибку. А именно - когда создание каталога в облаке возвращает ошибку такой путь уже существует - то это же никакая не ошибка - каталог же уже есть (и не важно что мы его не создали).
Пользователь добавил сообщение 03 Марта 2017, 16:50:28:
В целом я погряз в идее continuous integration - напилил кучу unittest-ов, и добился значительного покрытия кода тестами:
Name Stmts Miss Cover Missing
---------------------------------------
Cloud 135 5 96% 97, 244-247
Disk 494 77 84% 433-438, 440-446, 449, 681-758
jconfig 41 0 100%
---------------------------------------
TOTAL 670 82 88%
Причем диапазон строк 681-758 в классе Disk - это интерактивная обертка класса - т.е. просто обертка. А 433-438, 440-446 - это явно не запускаемый код - отработки конфликта (я его еще не продумал до конца и не отлаживал еще). Т.е. фактически у Disk - 100% покрытие на самом деле.
А в Cloud не покрыты только те ошибочные ситуации, которые можно протестировать разве что сеть погасив... как это временно сделать без административных прав - я пока не придумал....