Problem when using function query with group by field, rows=0 is not effect

Dear Solr, I am using Solr 4.8.1 with 2 shard nodes on a collection I have a query using the function query features and grouping start=60=0=((expireTime:[NOW TO *] ) OR (*:* NOT

Re: question about updates to shard leaders only

It's been a while since I've been in this deeply, but it should be something like: sendUpdateOnlyToShardLeaders will select the leaders for each shard as the load balanced targets for update. The updates may not go to the *right* leader, but only the leaders will be chosen, followers (non leader

Re: User queries end up in filterCache if facetting is enabled

I'd never noticed this before, but I believe it happens because, once you say `facet=true`, Solr will need the full docset (the set of all matching docs, not just the top matches) and does so by using the filter cache. > On May 3, 2018, at 7:10 AM, Markus Jelsma

Re: change in the Standard Query Parser behavior when migrating from Solr 5 to 7.

On 5/9/2018 2:37 PM, Piyush Kumar Nayak wrote: > Same here. "sow" restores the old behavior. This might be a bug.  I'd like someone who has better understanding of the low-level internals to comment before assuming that it's a bug, though.  Sounds like sow=false (default as of 7.0) might be

Re: Must clause with filter queries

On 5/9/2018 12:56 PM, root23 wrote: > Thanks for the explanation shawn. I will look at our autowarming time. > Looking at your response i am thinking i might be doing few more things > wrong > 1. Does Must clause with any of the filter query makes any sense or is > automatically implied. > e.g

Re: Upgrading to Solr 7.3 but Zookeeper 3.4.11 no longer available on Zookeeper mirror sites

Thanks Shawn. That makes sense. On Wed, May 9, 2018 at 5:10 PM, Shawn Heisey wrote: > On 5/9/2018 2:38 PM, Andy C wrote: > > Was not quite sure from reading the JIRA why the Zookeeper team felt the > > issue was so critical that they felt the need to pull the release from >

Re: Upgrading to Solr 7.3 but Zookeeper 3.4.11 no longer available on Zookeeper mirror sites

On 5/9/2018 2:38 PM, Andy C wrote: > Was not quite sure from reading the JIRA why the Zookeeper team felt the > issue was so critical that they felt the need to pull the release from > their mirrors. If somebody upgrades their servers from an earlier 3.4.x release to 3.4.11, then 3.4.11 might be

Re: Upgrading to Solr 7.3 but Zookeeper 3.4.11 no longer available on Zookeeper mirror sites

On 5/9/2018 1:51 PM, Andy C wrote: > According to the 7.3 release notes I should be using Zookeeper 3.4.11 with > Solr 7.3. The release notes don't make any specific recommendation about the version of ZK that you should use for your server.  The information in the release notes that mentions

Re: Upgrading to Solr 7.3 but Zookeeper 3.4.11 no longer available on Zookeeper mirror sites

Nope, we just moved to 3.4.11 recently. Raise a JIRA? On Wed, May 9, 2018 at 1:38 PM, Andy C wrote: > Thank Erick. > > Was not quite sure from reading the JIRA why the Zookeeper team felt the > issue was so critical that they felt the need to pull the release from > their

Re: Upgrading to Solr 7.3 but Zookeeper 3.4.11 no longer available on Zookeeper mirror sites

Thank Erick. Was not quite sure from reading the JIRA why the Zookeeper team felt the issue was so critical that they felt the need to pull the release from their mirrors. I guess the biggest issue is if you started out with a single ZK instance and then implemented a ZK cluster that it would

RE: change in the Standard Query Parser behavior when migrating from Solr 5 to 7.

Same here. "sow" restores the old behavior. The schema.xml in both Solr versions for me is the one that gets copied from the default template folder to the collections's conf folder. On 7 though, looks like the schema changes file changes to "managed-schema". The fieldtype that corresponds to

Re: Upgrading to Solr 7.3 but Zookeeper 3.4.11 no longer available on Zookeeper mirror sites

That bug isn't all that critical, at worst you may have to invert where your two directories point. 3.4.11 is available from https://archive.apache.org/dist/zookeeper/ Best, Erick On Wed, May 9, 2018 at 12:51 PM, Andy C wrote: > According to the 7.3 release notes I should

Re: change in the Standard Query Parser behavior when migrating from Solr 5 to 7.

sow=true made 7 mimic 5. On Wed, May 9, 2018 at 3:57 PM, Shawn Heisey wrote: > On 5/9/2018 1:25 PM, David Hastings wrote: > > https://pastebin.com/0QUseqrN > > > > here is mine for an example with the exact same behavior > > Can you try the query in the Analysis tab in

Re: change in the Standard Query Parser behavior when migrating from Solr 5 to 7.

On 5/9/2018 1:25 PM, David Hastings wrote: > https://pastebin.com/0QUseqrN > > here is mine for an example with the exact same behavior Can you try the query in the Analysis tab in the admin UI on both versions and see which step in the analysis chain is the point at which the two diverge from

Upgrading to Solr 7.3 but Zookeeper 3.4.11 no longer available on Zookeeper mirror sites

According to the 7.3 release notes I should be using Zookeeper 3.4.11 with Solr 7.3. However it appears that Zookeeper has pulled Zookeeper 3.4.11 from their mirror sites (this appears to be due to a serious bug in ZK 3.4.11 - ZOOKEEPER-2960)

Re: change in the Standard Query Parser behavior when migrating from Solr 5 to 7.

id rather not at least on my part, but in both cases i have: and text as my default field, changed from text_general On Wed, May 9, 2018 at 3:43 PM, Shawn Heisey wrote: > On 5/9/2018 1:25 PM, David Hastings wrote: > > https://pastebin.com/0QUseqrN > > Can you provide

Re: change in the Standard Query Parser behavior when migrating from Solr 5 to 7.

On 5/9/2018 1:25 PM, David Hastings wrote: > https://pastebin.com/0QUseqrN Can you provide the *full* schema for both versions? Thanks, Shawn

Re: change in the Standard Query Parser behavior when migrating from Solr 5 to 7.

https://pastebin.com/0QUseqrN here is mine for an example with the exact same behavior On Wed, May 9, 2018 at 3:14 PM, Shawn Heisey wrote: > On 5/9/2018 12:39 PM, Piyush Kumar Nayak wrote: > > we have recently upgraded from Solr5 to Solr7. I'm running into a change > of

Re: change in the Standard Query Parser behavior when migrating from Solr 5 to 7.

On 5/9/2018 12:39 PM, Piyush Kumar Nayak wrote: > we have recently upgraded from Solr5 to Solr7. I'm running into a change of > behavior that I cannot fathom. > For the term "test3" Solr7 splits the numeric and alphabetical components and > does a simple term search while Solr 5 did a phrase

Re: Must clause with filter queries

Thanks for the explanation shawn. I will look at our autowarming time. Looking at your response i am thinking i might be doing few more things wrong 1. Does Must clause with any of the filter query makes any sense or is automatically implied. e.g if i want all the docs with firstName:michael

Re: Problem with synonyms containing whitespace

thanks for the solution its working fine for me. I did the same configuration but missed the tokenizerFactory="solr.KeywordTokenizerFactory" in the filter tag. that great -- Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html

Re: change in the Standard Query Parser behavior when migrating from Solr 5 to 7.

Strange, I have the exact same results, whats more interesting is the analyzer shows identical for both 5 and 7, so its definetly a change in the LuceneQParser On Wed, May 9, 2018 at 2:39 PM, Piyush Kumar Nayak wrote: > we have recently upgraded from Solr5 to Solr7.

change in the Standard Query Parser behavior when migrating from Solr 5 to 7.

we have recently upgraded from Solr5 to Solr7. I'm running into a change of behavior that I cannot fathom. For the term "test3" Solr7 splits the numeric and alphabetical components and does a simple term search while Solr 5 did a phrase search.

Re: question about updates to shard leaders only

You may not need to deal with any of this. The default CloudSolrClient call creates a new LBHttpSolrClient for you. So unless you're doing something custom with any LBHttpSolrClient you create, you don't need to create one yourself. Second, the default for CloudSolrClient.add() is to take the

Re: Faceting over ExternalFileField

Absence of error is a bug for me. The problem is that eff is doubles not strings with ordinals. It would be possible after https://issues.apache.org/jira/browse/SOLR-10528 Now you can try to create several type:query subfacets passing either {!frange} or just plain Lucene query (there is a slight

Solr 7.3, FunctionScoreQuery no longer displays debug output

Hi, Is this a known problem? For example, the following query: q=australia=true=if(exists(query($bqlang)),2,1)=lang:en=edismax=content_en content_ro returns the following toString for 7.2.1: boost(+(Synonym(content_en:australia content_en:australia) | Synonym(content_ro:austral

Multiple languages, boosting and, stemming and KeywordRepeat

Hello, First, apologies for the weird subject line. We index many languages and search over all those languages at once, but boost the language of the user's preference. To differentiate between stemmed tokens and unstemmed tokens we use KeywordRepeat and RemoveDuplicates, this works very

Re: Solr Json Facet

Only for the records, I will describe here what I did to solve this problem. This is specific for those who are using python/requests and Solr json facet api. I would like to ask another question regarding json facet. > > With GET method, i was used to use many fq on the same query, each one >

Re: Regarding LTR feature

So Prateek : "You're right it doesn't have to be that accurate to the query time but our requirement is having a more solid control over our outputs from Solr like if we have 4 features then we can adjust the weights giving something like (40,20,20,20) to each feature such that the sum total of

Faceting over ExternalFileField

Is it possible to facet over ExternalFileField values? If I have this in my schema.xml: And request the following facet: facet={ "age": { "field": "eff_age", "type": "terms", "limit": 10 } } It returns an empty list of buckets. First, it doesn't throw an

Re: Too many segments flushed (was: Too many commits)

Thanks for the great info. Both of you. Yes, I know we have configuration issue with commitWithin and autoCommit. I cannot change our config freely, so this will probably stay like this for some time. I will try to indeed introduce autoSoftCommit (60 seconds is our maximus, as we try to achieve

question about updates to shard leaders only

Hi list, while going from single core master/slave to cloud multi core/node with leader/replica I want to change my SolrJ loading, because ConcurrentUpdateSolrClient isn't cloud aware and has performance impacts. I want to use CloudSolrClient with LBHttpSolrClient and updates should only go to

Re: Re:LTR performance issues

Thanks, Deigo. I shall followup from the jira.. - --Ilay -- Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html

Re: How to do indexing on remote location

Hello, Perhaps something like https://lucene.apache.org/solr/guide/7_0/content-streams.html#remotestreaming On Wed, May 9, 2018 at 6:10 AM, Raymond Xie wrote: > Please take this as no joking! Any suggestion is welcome and appreciated. > > I have data on remote WORM drive

Re: Async exceptions during distributed update

Hi Jay, Network blip might be the cause, but also the consequence of this issue. Maybe you can try avoiding DBQ while indexing and see if it is the cause. You can do thread dump on “the other” node and see if there are blocked threads and that can give you more clues what’s going on. Thanks,