Re: edismax parsing confusion

wrote: > Hello guys > sorry for late response. @steve I am using solr 5.2 . > @greg i am using default mm from config file(According to me it is default > mm is 1). > > Regards, > Abhishek > > On Tue, Apr 4, 2017 at 5:27 AM, Greg Pendlebury <greg.pendleb...@gmail.com >

Re: edismax parsing confusion

eDismax uses 'mm', so knowing what that has been set to is important, or if it has been left unset/default you would need to consider whether 'q.op' has been set. Or the default operator from the config file. Ta, Greg On 3 April 2017 at 23:56, Steve Rowe wrote: > Hi

Re: Edismax query parsing in Solr 4 vs Solr 6

This has come up a lot on the lists lately. Keep in mind that edismax parses your query uses additional parameters such as 'mm' and 'q.op'. It is the handling of these parameters (and the selection of default values) which has changed between versions to address a few functionality gaps. The most

Re: changed query parsing between 4.10.4 and 5.5.3?

get some hits out of 99 million records and they are correct. > > Regards, > Bernd > > > Am 15.09.2016 um 01:41 schrieb Greg Pendlebury: > > I'm sorry that's been your experience Bernd. If you do manage to find > some > > time it would be good to see some de

Re: changed query parsing between 4.10.4 and 5.5.3?

gt; > If I get time I will look into this but right now my problem is solved > > and the customers and users are happy. > > > > I hope that this buggy edismax version is not used in solr 6.x otherwise > you > > have the same problems there. > > > > Regards >

Re: changed query parsing between 4.10.4 and 5.5.3?

ge some major internals > > and don't give any notice about how to keep old parsing behavior. > > > > From my point of view the old parsing behavior was correct. > > If searching for a term without operator it is always OR, otherwise > > you can add "+" or

Re: changed query parsing between 4.10.4 and 5.5.3?

with q.op AND it is > modified to "+" as a MUST. > > I still get some differences in search results between 4.10.4 and 5.5.3. > What other side effects has this change of q.op from AND to OR in > other parts of query handling, parsing and searching? > > Regards > B

Re: changed query parsing between 4.10.4 and 5.5.3?

I forgot to mention the tickets: SOLR-2649 and SOLR-8812 On 9 September 2016 at 13:38, Greg Pendlebury <greg.pendleb...@gmail.com> wrote: > Under 4.10 q.op was ignored by the edismax parser and always forced to OR. > 5.5 is looking at the q.op=AND you requested. > > There are

Re: changed query parsing between 4.10.4 and 5.5.3?

Under 4.10 q.op was ignored by the edismax parser and always forced to OR. 5.5 is looking at the q.op=AND you requested. There are also some changes to the default values selected for mm, but I doubt those apply here since you are setting it explicitly. On 8 September 2016 at 00:35, Mikhail

Re: After Solr 5.5, mm parameter doesn't work properly

operators > I don’t know... > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > > > 2. jun. 2016 kl. 05.12 skrev Greg Pendlebury <greg.pendleb...@gmail.com > >: > > > > I would describe that subtly differently, and I think it is

Re: After Solr 5.5, mm parameter doesn't work properly

id not care about q.op if mm was set explicitly, > but if mm was not set, then q.op=OR —> mm=0%, q.op=AND —> mm=100% > > And from 5.5 it seems as q.op does something even if mm is set... > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com >

Re: After Solr 5.5, mm parameter doesn't work properly

16 kl. 03.47 skrev Greg Pendlebury <greg.pendleb...@gmail.com > <javascript:;>>: > > > I don't think it is 8812. q.op was completely ignored by edismax prior to > > 5.5, so it is not mm that changed. > > That is not the case. Prior to 5.5, mm would be auto

Re: After Solr 5.5, mm parameter doesn't work properly

I don't think it is 8812. q.op was completely ignored by edismax prior to 5.5, so it is not mm that changed. If you do the same 5.4 query with q.op=OR I suspect it will not change the debug query at all. On 30 May 2016 at 21:07, Jan Høydahl wrote: > Hi, > > This may be

Phrase Slop relevance tuning

I've received a request from our business area to take a look at emphasising ~0 phrase matches over ~1 (and greater) more that they are already. I can't see any doco on the subject, and I'd like to ask if anyone else has played in this area? Or at least is willing to sanity check my reasoning

Re: SolrCloud leaders using more disk space

you diff the listings of the index data directories on a leader vs. replica? Might give us some insights to what files the leader has that the replicas don't have. Cheers, Tim On Tue, Jun 3, 2014 at 8:32 PM, Greg Pendlebury greg.pendleb...@gmail.com wrote: Hi all, We launched our new

SolrCloud leaders using more disk space

Hi all, We launched our new production instance of SolrCloud last week and since then have noticed a trend with regards to disk usage. The non-leader replicas all seem to be self-optimizing their index segments as expected, but the leaders have (on average) around 33% more data on disk. My

Re: Deep paging in parallel with solr cloud - OutOfMemory

Shouldn't all deep pagination against a cluster use the new cursor mark feature instead of 'start' and 'rows'? 4 or 5 requests still seems a very low limit to be running into an OOM issues though, so perhaps it is both issues combined? Ta, Greg On 18 March 2014 07:49, Mike Hugo

Re: Deep paging in parallel with solr cloud - OutOfMemory

skip content. Ta, Greg On 18 March 2014 09:44, Mike Hugo m...@piragua.com wrote: Cursor mark definitely seems like the way to go. If I can get it to work in parallel then that's additional bonus On Mon, Mar 17, 2014 at 5:41 PM, Greg Pendlebury greg.pendleb...@gmail.comwrote: Shouldn't

Re: Deep paging in parallel with solr cloud - OutOfMemory

... but: A) I could be wrong, and B) I could be talking about parallel in a different way to Mike. Ta, Greg On 18 March 2014 10:24, Yonik Seeley yo...@heliosearch.com wrote: On Mon, Mar 17, 2014 at 7:14 PM, Greg Pendlebury greg.pendleb...@gmail.com wrote: My suspicion is that it won't work

Re: Solr metrics in Codahale metrics and Graphite?

In the codahale metrics library there are 1, 5 and 15 minute moving averages just like you would see in a tool like 'top'. However in Solr I can only see 5 and 15 minute values, plus 'avgRequestsPerSecond'. I assumed this was the 1 minute value initially, but it seems to be something like the

Re: Solr metrics in Codahale metrics and Graphite?

Metrics class has a method to return 1 minute stats but it is not used. On Mon, Mar 17, 2014 at 10:06 AM, Greg Pendlebury greg.pendleb...@gmail.com wrote: In the codahale metrics library there are 1, 5 and 15 minute moving averages just like you would see in a tool like 'top'. However in Solr I

Re: Solr 4.7.0 - cursorMark question

That was really clear; I just had another read through of the documentation with that explanation in mind and I can see I went off the rails. Sorry for any confusion on my part, and thanks for the details. Ta, Greg On 8 March 2014 08:36, Chris Hostetter hossman_luc...@fucit.org wrote: :

Re:Solr 4.7.0 - cursorMark question

* New 'cursorMark' request param for efficient deep paging of sorted result sets. See http://s.apache.org/cursorpagination; At the end of the linked doco there is an example that doesn't make sense to me, because it mentions sort=timestamp asc and is then followed by pseudo code that sorts by

Re: Solr 4.7.0 - cursorMark question

Thank-you, that all sounds great. My assumption about documents being missed was something like this: A,B,C,D where they are sorted by timestamp first and ID second. Say the first 'page' of results is 'A,B', and before the second page is requested both documents B + C receive update events and

Re: Cluster state ranges are all null after reboot

couldn't reproduce this but I didn't try too hard either. If you are able to isolate a reproducible example then please do report back. I'll spend some time to review the related code again to see if I can spot the problem. On Thu, Feb 27, 2014 at 2:19 AM, Greg Pendlebury greg.pendleb

Re: Cluster state ranges are all null after reboot

any more investigation into why this happened? Anything strange in the logs? Are you able to reproduce this in a test environment? On Wed, Feb 19, 2014 at 5:16 AM, Greg Pendlebury greg.pendleb...@gmail.com wrote: We've got a 15 shard cluster spread across 3 hosts. This morning our puppet

Cluster state ranges are all null after reboot

We've got a 15 shard cluster spread across 3 hosts. This morning our puppet software rebooted them all and afterwards the 'range' for each shard has become null in zookeeper. Is there any way to restore this value short of rebuilding a fresh index? I've read various questions from people with a

SolrCloud Archecture recommendations + related questions

Hi All, TL;DR version: We think we want to explore Lucene/Solr 4.0 and SolrCloud, but I’m not sure if there is any good doco/articles on how to make architecture choices for how to chop up big indexes… and what other general considerations are part of the equation? I’m throwing this post

Re: Embedded Solr Optimize under Windows

Ahh, thanks. I might try a basic commit() then and see, although it's not a huge deal for me. It occurred to me that two optimize() calls would probably leave exactly the same problem behind. On 20 May 2011 09:52, Chris Hostetter hossman_luc...@fucit.org wrote: : Thanks for the reply. I'm at

Re: Embedded Solr Optimize under Windows

Thanks for the reply. I'm at home right now, or I'd try this myself, but is the suggestion that two optimize() calls in a row would resolve the issue? The process in question is a JVM devoted entirely to harvesting, calls optimize() then shuts down. The least processor intensive way of triggering

Embedded Solr Optimize under Windows

Hi All, Just quick query of no particular importance to me, but we did observe this problem: http://code.google.com/p/solr-geonames/wiki/DeveloperInstall It's worth noting that the build has also been run on Mac and Solaris now, and the Solr index is about half the size. We suspect the

Re: Embedded Solr constructor not returning

Sounds good. Please go ahead and make this change yourself. Done. Ta, Greg On 6 April 2011 22:52, Steven A Rowe sar...@syr.edu wrote: Hi Greg, I need the servlet API in my app for it to work, despite being command line. So adding this to the maven POM fixed everything:

Embedded Solr constructor not returning

Hi All, I'm hoping this is a reasonably trivial issue, but it's frustrating me to no end. I'm putting together a tiny command line app to write data into an index. It has no web based Solr running against it; the index will be moved at a later time to have a proper server instance start for

Re: Embedded Solr constructor not returning

://wiki.apache.org/solr/Solrj Logback is passing along all of my logging but I suspect I'd have to add some Solr logging config before it would tell me this itself. I only stumbled on it by accident: http://osdir.com/ml/solr-user.lucene.apache.org/2009-11/msg00831.html On 6 April 2011 14:48, Greg Pendlebury

Re: Batch update, order of evaluation

I can't reproduce reliably, so I'm suspecting there are issues in our code. I'm refactoring to avoid the problem entirely. Thanks for the response though Erick. Greg On 8 September 2010 21:51, Greg Pendlebury greg.pendleb...@gmail.comwrote: Thanks, I'll create a deliberate test tomorrow

Re: Batch update, order of evaluation

before you search: 1 the batch is finished processing 2 you've issued a commit after the last document in the batch. If you're sure of the above and still see the problem, please let us know... HTH Erick On Tue, Sep 7, 2010 at 10:32 PM, Greg Pendlebury greg.pendleb...@gmail.comwrote

Batch update, order of evaluation

Does anyone know with certainty how (or even if) order is evaluated when updates are performed by batch? Our application internally buffers solr documents for speed of ingest before sending them to the server in chunks. The XML documents sent to the solr server contain all documents in the order

Always spellcheck (suggest)

Hi All, If I understand correctly the flag 'onlyMorePopular' encapsulates two independent behaviours. 1) It runs spell checking across queries that returned hits. Without the flag spell checking is not run when results are found. 2) It limits suggestions to terms with higher frequencies. Is

RE: Always spellcheck (suggest)

the paremeter spellcheck=true. Suggestions will be returned regardless of whether there are results. The only time I believe spelling suggestions might not be included is when all of the words are spelled correctly. On 10/04/2009 07:55 PM, Greg Pendlebury wrote: Hi All, If I understand

RE: Always spellcheck (suggest)

), nothing more. In short, I believe the answer is No. On 10/04/2009 09:19 PM, Greg Pendlebury wrote: Thanks for the response Christian. I'll modify my original point (1) then. Is 'onlyMorePopular' the only way to return suggestions when all of the search terms are present in the dictionary (ie