Действительно ли opengrok требует отдельного промежуточного каталога?

Question

В примере инструкций по установке и настройке, как представляется, предполагается, что OpenGrok требуется две промежуточные области, с обоснованием, что одна область является рабочей областью регенерации индекса, а другая - рабочей областью, и они вращаются с каждый индекс регенерации.

Это действительно необходимо? Могу ли я иметь только одну область вместо двух?

Я ищу ответ, специфичный для opengrok, а не общий список условий гонки, с которыми можно столкнуться.

Answer 1

Строго говоря, в этом нет необходимости. Фактически, я почти уверен, что подавляющее большинство развертываний происходит без промежуточной области.

Тем не менее, вам нужно решить, устраивает ли вас окно несогласованности, которое может привести к некоторым неудачным / неточным поискам. Предположим, что источник был обновлен (например, через git pullв случае Git), а индексатор еще не завершил обработку новых изменений. Таким образом, индекс по-прежнему содержит данные, отражающие старое состояние источника. Допустим, изменения, примененные к источнику, удалили файл. Теперь, если кто-то инициирует поиск, который соответствует содержимому удаленного файла, результат поиска, вероятно, закончится ошибкой. Это, вероятно, лучшая альтернатива - рассмотрите случай, когда в файл вносятся более тонкие изменения, такие как удаление / добавление пары строк кода. В этом случае определения символов будут отключены, поэтому результаты поиска приведут вас к неправильной строке кода. Или, не столь тонкое изменение, когда, например, определение функции удаляется из файла, результаты поиска по ссылкам на эту функцию будут содержать недопустимые места.

Длина окна несогласованности зависит от времени индексации, которое в значительной степени зависит от двух вещей, по крайней мере, в настоящее время:

• размер изменений, примененных к источнику
• размер дерева исходных каталогов

Первый актуален из-за обработки истории. Чем больше входящих изменений в истории (например, наборов изменений в Git), тем больше работы придется выполнить индексатору для создания кэша истории и / или полей истории для индекса (при условии, что обработка истории включена).

Второе имеет значение, потому что индексатор просматривает все дерево исходных каталогов, чтобы выяснить, какие файлы были изменены, что может повлечь за собой множество системных вызовов и потенциально большое количество операций ввода-вывода. По крайней мере, до тех пор, пока не будет реализован https://github.com/oracle/opengrok/issues/3077, и это поможет только системам управления исходным кодом, основанным на наборах изменений.