SolrJ не задает обработчик запросов

У меня есть коллекция SolrCloud, настроенная с несколькими обработчиками запросов, и я хотел бы получить доступ к обработчику запроса по умолчанию, который называется /all, который определен в файле solrconfig.xml. Этот обработчик отлично работает, когда я ищу в браузере:SolrJ не задает обработчик запросов

Все обработчик:

Однако при поиске с помощью SolrJ SolrQuery.setRequestHandler("all"), я получаю 0 результатов. SolrJ просто ставит qt=/all в запросе, так что эти результаты браузера одного и того же запроса (SolrJ получает то же самое):

Выберите с кварты =/все:

наблюдается Такое же поведение для все наши другие обработчики. Если обработчик не определен, Solr выдает другую ошибку, если есть ведущий «/» или по умолчанию, чтобы выбрать, нет ли ведущего «/», поэтому мы знаем, что это не проблема.

Так что мой вопрос: как я могу заставить это работать в SolrJ? Выбор имеет настройки по умолчанию в файле solrconfig.xml и он должен оставаться обработчиком по умолчанию. Поиск вокруг, ошибка, похоже, происходит, когда есть повторяющиеся идентификаторы, или поле id не сохраняется. Но если это так, ни один из поисков не должен работать, поэтому я думаю, что здесь должно быть что-то еще.

источник

2016-09-20 jbird

просто предположение:/все можно зарезервировать. Вы пытались определить другую уникальную конечную точку обработчика? –

Да, у нас есть еще двое, и с ними одинаковое поведение. Если это помогает, это SolrCloud 6.0.1, и мы являемся автономной версией (5.3.0) с идентичным индексом, где все обработчики (включая/все) работают правильно, используя этот метод. – jbird

Хорошо. Вы пробовали отправить в список рассылки solr? Захватить внимание соответствующих людей могло бы помочь. –

Похоже, что проблема только что разрешилась. Никаких изменений не было, но теперь все работает правильно. Мы думаем, что может произойти некоторая индексация в фоновом режиме или, возможно, что-то случилось с самим Solr. Мы, возможно, никогда не узнаем, но я больше не могу воспроизвести проблему, поэтому я думаю, что это работает.

Спасибо всем, кто пытался помочь.

источник

2016-09-22 20:58:19 jbird

Это правда, что видимый эффект в методе setRequestHandler заключается в том, чтобы просто установить параметр qt. Но это не конец истории с SolrJ.

Когда обрабатывается запрос SolrJ, если параметр qt содержит строку, начинающуюся с косой черты, SolrJ изменит «/ select» в пути URL на значение, содержащееся в этом параметре, прежде чем отправит запрос Solr. Он также отправит параметр qt как есть в Solr, но сам параметр обычно не имеет значения.

Если вы отправляете фактический запрос Solr в обработчик/select с qt, установленным на «/ all», Solr должен игнорировать параметр qt - если вы не установите handleSelect в true в разделе requestDispatcher файла solrconfig.xml. Это не рекомендуется, потому что это означает, что вы можете изменить индекс с помощью обработчика/select, установив qt на «/ update».

https://cwiki.apache.org/confluence/display/solr/RequestDispatcher+in+SolrConfig#RequestDispatcherinSolrConfig-handleSelectElement

Это также возможно, что есть ошибка в новой Solr, где использование Qt с handleSelect = «истина» не работает правильно. Я не уверен, действительно ли это будет ошибкой или нет. Конечно, это не рекомендуется.

Что такое настройка handleSelect в файле solrconfig.xml, когда вы получаете это исключение?

источник

2016-09-21 15:11:43 elyograg

-1: 'handleSelect' амортизируется как Solr 3.6. Из вашей ссылки «Значение по умолчанию« false »будет игнорировать запросы на/select **, если requestHandler явно не зарегистрирован с именем /select.**» (акцент мой). Начиная с Solr 3.6, по умолчанию создается RequestHandler с именем/select, поэтому нет причин для его изменения. До 3.6, RequestHandler по умолчанию был вызван/search. – jbird

До версии 3.6 в конфигурационном файле config содержался обработчик по умолчанию с именем «default». Пример ответил на запросы «/ select», потому что этот обработчик сказал default = «true» и handleSelect был включен. Начиная с версии 3.6 на примере handleSelect отключен, а обработчик по умолчанию на самом деле был назван «/ select», чтобы он регистрировался по этому URL-адресу. Если параметр handleSelect устарел в 3.6, он полностью исчезнет с 4.0 и более поздних версий ... но документация, которую я связал выше, касается текущих версий, и в то время, когда я ее связал, это было 6.x. – elyograg

Хорошо, конечно. Недостаток был неправильным словом. Возможно, больше не используется. Он поддерживался для обратной совместимости в соответствии с обсуждением JIRA об этом. Независимо от того, этот ответ не имеет отношения к вопросу, поскольку я упоминаю использование обработчика выбора в своем сообщении. – jbird

SolrJ не задает обработчик запросов

ответ

Смежные вопросы