Понимание проблем индексации Alfresco & Solr
Добрый день мудрые волшебники,
Чтобы сделать очень длинную историю длинной историей:
Недавно я был вовлечен в проект, который использует Solr от Alfresco для управления документами, который наше приложение Java использует через вызовы CMIS. Иногда мы получаем отчеты об ошибках от конечных пользователей, которые утверждают, что документы недоступны. Когда мы расследуем эти заявления, простое обновление (казалось бы) всего, что касается связанного документа, решает проблему за считанные секунды. Вы должны знать, что я совершенно новичок в Alfresco, Solr, и в этом проекте в целом, поэтому, пожалуйста, будьте терпеливы.
Это привело к тому, что предыдущий следователь полагал, что это проблема, связанная с индексацией; По какой-то причине Солр думал, что документ был обработан, но на самом деле это было до тех пор, пока не было сделано другое изменение, после которого он был должным образом проиндексирован и доступен для поиска.
Вскоре после этого мы нашли URL-адрес.../solr4/admin/cores? Action=REPORT, который указывал, что многие транзакции (и транзакции ACL) были в индексе, но не в БД, но даже после прочтения документации есть много Я не понимаю "... может быть проблема..." не помогает. Любое руководство и предложение приветствуется.
Кажется, что, когда слишком много вызовов CMIS используются, чтобы вызвать транзакции за слишком короткий период времени, "Количество транзакций acl в индексе, но не в БД" ("indexed-not-db" для краткости) увеличивается, и это, кажется, примерно соответствовать количеству обращений к отчетам об ошибках, которые мы получаем. Из-за этого я работаю над предположением, что мы должны исправить то, что вызывает проблему indexed-not-db.
Мы попросили их поддержки о помощи, и, хотя они были вежливы, она также оказалась бесполезной. Проблема не является надежно повторяемой, и отключение наших производственных сервисов исключительно сложно, на чем они настаивали. Мы придумали небольшое Java-приложение, которое принимает N документов и быстро добавляет / удаляет разрешения, чтобы попытаться вызвать эту проблему, которая увеличивает количество индексированных-не-дБ (на ненадежную величину), если N достаточно велико в нашей тестовой среде.,
Недавно мы настроили несколько конфигурационных файлов Solr в нашей тестовой среде в соответствии с настройкой производительности Solr и разделили Solr на собственную виртуальную машину для тестирования, но из-за ненадежного подсчета index-not-db в любом конкретном тесте, который я не выполняю большой прогресс. Число по-прежнему превышает 0 после 8 минут транзакций, вызванных CMIS.
- Что может привести к увеличению количества индексированных-не-БД?
- Является ли indexed-not-db на самом деле ошибкой, или я не в той кроличьей норе?
- Любые предложения о том, что может помешать росту индексации не базы данных?
- Что на самом деле делает action=FIX и почему число не всегда сбрасывается в 0? (для запуска в нашей производственной среде требуется более 30 минут, и он не может сбросить счетчик до 0 - даже когда никто не использует Solr, поэтому я не могу просто периодически запускать его как "исправление")
- Как я могу найти больше информации о транзакциях / узлах, которые являются частью indexed-not-db? Я не знаю, как взять идентифицированную "Первую транзакцию в индексе, но не в БД" и получить из нее что-нибудь полезное.
- Есть ли супер быстрый способ получить "Первую транзакцию в индексе, но не в БД" (или в идеале список всех из них), чтобы я мог вызвать для нее action=REINDEX (что очень быстро)?
Опять же, все мысли приветствуются. Я новичок в этом, хотя, пожалуйста, будьте многословны и явны. Вы потрясающие, не забывайте это.