ferent lookupImp, that doesn't support
the suggest.cfq, for our 'suggesterY'.
Ron Haines
On Thu, Jan 9, 2025 at 2:41 PM Ron Haines wrote:
> Just recently started using the 'suggest.cfq' parameter. We have 2
> suggesters configured in solrconfig.xml. Let's call one
e
filtering out all of the valid matches that come from 'suggesterY'.
Is this by design? Or, maybe I'm not understanding how to use this
'suggest context' capability?
Thanks for any help.
Ron Haines
as the docs that were doing the
'joining'. Maybe I'm confused...it would make my life a bit easier, if the
'same shard' requirement were not necessary.
Ron Haines
On Wed, Jul 19, 2023 at 3:11 PM Charles Sanders wrote:
> Thanks for the reply Ron. You bring up a good
After your migration, did your documents that should 'join' end up located
on the same shard? I believe that is a requirement.
Ron Haines
On Wed, Jul 19, 2023 at 1:04 PM Charles Sanders wrote:
> Thanks again Mikhail for your reply. Yes there are absolutely matches for
> the
did get a thread dump, via admin console, while full load test is running:
Seeing a lot of thesemost in the 300k-900k ms rangeyes 300-900
seconds. Any chance these are just idle threads, waiting for work?
qtp1278319954-13565 (13565)
java.util.concurrent.locks.AbstractQueuedSynchronizer$
C
> 2.B -
> 3.C -
> 4.D *G*
> 5.E B
> 6.F. -
> 7.G
>
> So, if a user runs a query that finds docs A,B,C,D,E,F.
thread dumps
> under load gives a useful clue.
> Also, if "to" side is huge and highly sharded, and "from" is small, and
> updates are rare, index-time join via {!parent} may work well. Caveat - it
> may be cumbersome..
> PS, I suggested two jiras earlier, I don&
27; of cpu of these 2 tests vs. the one above, from a
'cores' point of view:
[image: image.png]
Like I said, I'll run these same tests with the ‘method=topLevelDV’, and
see if it changes behavior.
Thx
Ron Haines
On Thu, May 25, 2023 at 4:29 PM Mikhail Khludnev wrote:
> Ro
I've been using the 'join' query parser to 'filter out' related documents
that should not be part of the result set. Functionally, it is working
fine. However, when we throw a 'real' level of customer traffic at it, it
pretty much brings Solr to its knees. CPU increases ALOT. Close to 3X,
when
> params.set(CommonParams.FL, fromField);
> > params.set(CommonParams.SORT, fromField + " asc");
> > params.set(CommonParams.QT, "/export");
> >
> > However, the export handler doesn't sort by mv field
> >
> https://solr.apache.org/guide/8_9/
;person' collection was quite small. So, to
address this, I simply replicated my 'person' collection across all 5
shards.
I'm still in the process of 'certifying' if what I described is
actually behaving the way I think it should. So far, so good.
Ron Haines
versions of solr server and client you using?
>
> Thanks
>
> On Wed, Jan 11, 2023 at 9:17 PM Mikhail Khludnev wrote:
>
> > Hi, Ron.
> > Right. Never thought of that. It might be an issue.
> > Feel free to raise one.
> >
> > On Wed, Jan 11, 2023 at 8:36 PM
Seems like when I provide a 'children:[subquery]' in my &fl, and the xml
response now includes a nested element, the
XMLResponseParser.java throws a 'parsing error', Caused by:
javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,892]
Message: must be value or array
Is there a known is
13 matches
Mail list logo
