Ping.
On Thu, May 7, 2026 at 10:40 PM Mikhail Khludnev <[email protected]> wrote:
> David, do you
> expect
> /mlt-collection,mlt-collection-2/select?q={!mlt+qf%3Dlowerfilt_u+mindf%3D0+mintf%3D1}100
> works with no code changes? It doesn't. We need to choose which part to
> fix: rtg or mltQP.
>
> GET
> http://127.0.0.1:38145/solr/mlt-collection,mlt-collection-2/select?q=%7B%21mlt+qf%3Dlowerfilt_u+mindf%3D0+mintf%3D1%7D100&wt=javabin
> HTTP/1.1
>
> 482098 ERROR (qtp739992701-56-null-10) [n:127.0.0.1:38145_solr
> c:mlt-collection s:shard2 r:core_node3 x:mlt-collection_shard2_replica_n1
> t:null-10] o.a.s.h.RequestHandlerBase Client exception
> org.apache.solr.common.SolrException: Error completing MLT request. Could
> not fetch document with id [100]
> at
> org.apache.solr.search.mlt.CloudMLTQParser.parse(CloudMLTQParser.java:54)
> at org.apache.solr.search.QParser.getQuery(QParser.java:196)
> at
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:190)
>
> [x] Traditional sentence regarding wasteful query parsing on
> coordinator node.
>
> On Thu, May 7, 2026 at 3:47 PM David Smiley <[email protected]> wrote:
>
>> We've discussed in the dev list recently a strong distaste for the
>> "collection" param. Is the issue you speak of equivalent if the
>> collection
>> is instead in the natural place in the path is comma-delimited?
>>
>> On Thu, May 7, 2026 at 3:33 AM Mikhail Khludnev <[email protected]> wrote:
>>
>> > Devs,
>> > After looking into it, I've got a two chairs question, either:
>> >
>> > - manage RTG /get to handle `collection`
>> > <
>> >
>> https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/handler/component/RealTimeGetComponent.java#L1046
>> > >
>> > param,
>> > or
>> > - let {!mlt} ignore no doc found error
>> > <
>> >
>> https://github.com/apache/solr/blob/a2370b58380e61633e0e1b65312bb33201eea3cd/solr/core/src/java/org/apache/solr/search/mlt/CloudMLTQParser.java#L53
>> > >
>> > in case if the `collection` param is sent, assuming the will be
>> found in
>> > another collection
>> >
>> > The latter approach causes a slight negative regression: it won't throw
>> an
>> > error in case of the nonexistent ID anymore.
>> > So, which one do you choose?
>> > .
>> >
>> > On Wed, May 6, 2026 at 8:49 PM Mikhail Khludnev <[email protected]>
>> wrote:
>> >
>> > > Hi there.
>> > > Here we got https://github.com/mkhludnev/solr/pull/1 it's a rough
>> cut.
>> > > How you feel about it?
>> > >
>> > > On Wed, May 6, 2026 at 8:06 PM Mikhail Khludnev <[email protected]>
>> wrote:
>> > >
>> > >> Hi
>> > >> It looks like
>> > >>
>> >
>> https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/search/mlt/CloudMLTQParser.java#L101
>> > >> is not clusteraware at all.
>> > >> It lacks functionality, needs to be developed.
>> > >>
>> > >> On Wed, May 6, 2026 at 7:47 PM Till Kinstler <[email protected]>
>> wrote:
>> > >>
>> > >>> Hi all,
>> > >>>
>> > >>> we have a use case, where we would like to make a MoreLikeThis Query
>> > >>> Parser request across two collections (of multiple shards each) in a
>> > >>> SolrCloud. The two collections share the same index schema.
>> > >>> The request looks like
>> > >>> q={!mlt qf=field1,field2}ID&collection=collection1,collection2
>> > >>>
>> > >>> It results in an error message "Error completing MLT request. Could
>> not
>> > >>> fetch document with id [ID]" from one of the shards of the
>> collection
>> > >>> not containing the document with id ID.
>> > >>>
>> > >>> So I guess, while the MoreLikeThis Query Parser is "SolrCloud aware"
>> > and
>> > >>> can handle MLT requests across multiple shards of one collection
>> (works
>> > >>> fpr us), it can not deal with multiple collections? Or are we
>> missing
>> > >>> something? Is there a way to send one MoreLikeThis Query Parser
>> request
>> > >>> to multiple SolrCloud collections?
>> > >>>
>> > >>> Thanks for any help,
>> > >>> Till
>> > >>>
>> > >>> --
>> > >>> Till Kinstler
>> > >>> Verbundzentrale des Gemeinsamen Bibliotheksverbundes (VZG)
>> > >>> Platz der Göttinger Sieben 1, D 37073 Göttingen
>> > >>> [email protected], http://www.gbv.de/
>> > >>>
>> > >>>
>> > >>
>> > >> --
>> > >> Sincerely yours
>> > >> Mikhail Khludnev
>> > >>
>> > >
>> > >
>> > > --
>> > > Sincerely yours
>> > > Mikhail Khludnev
>> > >
>> >
>> >
>> > --
>> > Sincerely yours
>> > Mikhail Khludnev
>> >
>>
>
>
> --
> Sincerely yours
> Mikhail Khludnev
>
--
Sincerely yours
Mikhail Khludnev
