FTS не работает

Добрый день! Проблемы с FTS. Не работает поиск. Запускаю из консоли JMX processQueue() - пишет Done 0 items… Хотя перед этим была запущенна процедура reindexAll() c результатом Enqueued 85178 items.
В логах вот такие сообщения:
2020-02-20 23:34:27.251 DEBUG [BackgroundTask-2-admin/app/admin] com.haulmont.cuba.web.jmx.JmxControlBean - Invoke method ‘processQueue’ from ‘app-core.fts:type=FtsManager’ on ’ (baygozin-work:)’
2020-02-20 23:34:27.251 INFO [BackgroundTask-2-admin/app/admin] com.haulmont.fts.core.app.FtsManager - Unable to process queue: there are entities that are waiting for reindex
2020-02-20 23:34:27.253 DEBUG [http-nio-8080-exec-7/app/admin] com.haulmont.cuba.web.gui.executors.impl.WebBackgroundWorker - Done task. User: admin

Что за объекты, “которые ждут переиндексации”? Как их найти и переиндексировать?

И еще смущают атрибуты бина. См. картинку:
atributes

Reindexing и Writing - false. Так и должно быть? И изменить их нельзя…

Тоже сталкивался с таким поведением. Перезапуск приложения вам поможет.
Полагаю, что это связано с asyncReindexAll(). Не нажимали перед тем, как выполнить reindexAll()?

Перезапуск приложения не помогает. Это все твориться на девелоперской машине с копией “боевой базы”. Что я только не делал и чего только не запускал. Если почистить базу в “нуль” и создать несколько записей - все четко работает. Восстанавливаю базу из бэкапа - все возвращается… fts.xml уже полностью коментировал - без толку. Осталось еще с cuba-fts.xml поизвращаться…

Дальше гадание на кофейной гуще… Я сам только второй день знакомлюсь с fts…

Базу восстанавливаете на которой уже нажималось asyncReindexAll()?
Если так, то попробуйте пожамкать на reindexNextBatch() и посмотреть количество записей в таблице с очередью. Изменяется?

1 симпатия

Ни на грамм! :slight_smile: В логах видно, что reindexNextBatch() отрабатывает, но с нулевым результатом… Да я уж что только не делал… Видимо, ключевые слова в логах - “Unable to process queue: there are entities that are waiting for reindex”. Туда и надо копать. Может кто из разработчиков Кубы внимание обратит?

Добрый день,

Если вы используете версию платформы 7.0 или выше, то у вас есть исходный код fts аддона, и вы без проблем можете разобраться в то, как бин работает, с отладчиком.
Главный класс это com.haulmont.fts.core.app.FtsManager

“ReindexEntitiesQueue” хранится тут:
"com.haulmont.fts.core.app.FtsManager#getReindexEntitiesQueue

Она лежит в памяти и не может не очиститься после перезагрузки сервера.
Если после перезагрузки она появляется опять, значит у вас где-то в коде, в скриптах, может быть в планировщиках кто-то вызывает asyncReindexAll().
Если поставите точку останова вот сюда:
com.haulmont.fts.core.app.FtsManager#asyncReindexEntity
то найдете виновника.

  1. Чтобы очередь reindex entities queue обработалась, вам нужно вручную много раз вызвать com.haulmont.fts.core.app.FtsManager#reindexNextBatch

Т.к. он обрабатывает не более одного класса сущности за вызов, даже если в таблице ноль записей, то вам действительно может возвращаться 0 после вызова. Но с каждым вызовом метода очередь ReindexEntitiesQueue будет уменьшаться на один класс.
Обычно этот метод ставят для периодического запуска по расписанию через механизм Scheduled Tasks.

1 симпатия

Переход на 7.0 - следующий этап головной боли. Пока 6.10.15. Вначале надо “добить” FTS - пациенты плачут… Все советы опробовал - не хочет работать…

Есть ещё одно средство радикальное от всех странных болезней - снести Tomcat со всеми потрохами и развернуть приложение заново.

Я могу посоветовать следующее:

  1. Изучить, как работает FtsManager, по исходным кодам на github.
    https://github.com/cuba-platform/fts

Ветки 6.10 там не выложено, но между 6.10 и 7.0 большой разницы нет.

  1. Переопределить бин com.haulmont.fts.core.app.FtsManager у себя в проекте.
    Тогда вы сможете переопределить ряд методов, для цели отлавливания, кто вызывает asyncReindex, или для изменения поведения.
1 симпатия

Исходники всех аддонов доступны в проекте, независимо от версии. Можно отлаживать пошагово.