[jira] [Updated] (SOLR-11331) Ability to Debug Solr With Eclipse IDE
[ https://issues.apache.org/jira/browse/SOLR-11331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Thacker updated SOLR-11331: - Attachment: SOLR-11331.patch > Ability to Debug Solr With Eclipse IDE > -- > > Key: SOLR-11331 > URL: https://issues.apache.org/jira/browse/SOLR-11331 > Project: Solr > Issue Type: Improvement >Affects Versions: 6.6.2 >Reporter: Karthik Ramachandran >Assignee: Varun Thacker >Priority: Minor > Labels: eclipse > Attachments: SOLR-11331.diff, SOLR-11331.patch, SOLR-11331.patch, > SOLR-11331.patch, UI.png > > Time Spent: 10m > Remaining Estimate: 0h > > Ability to Debug Solr With Eclipse IDE -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-11331) Ability to Debug Solr With Eclipse IDE
[ https://issues.apache.org/jira/browse/SOLR-11331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Thacker reassigned SOLR-11331: Assignee: Varun Thacker > Ability to Debug Solr With Eclipse IDE > -- > > Key: SOLR-11331 > URL: https://issues.apache.org/jira/browse/SOLR-11331 > Project: Solr > Issue Type: Improvement >Affects Versions: 6.6.2 >Reporter: Karthik Ramachandran >Assignee: Varun Thacker >Priority: Minor > Labels: eclipse > Attachments: SOLR-11331.diff, SOLR-11331.patch, SOLR-11331.patch, > UI.png > > Time Spent: 10m > Remaining Estimate: 0h > > Ability to Debug Solr With Eclipse IDE -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Config file indenting rules
What about using something like http://editorconfig.org/ to handle this? David Smiley at "Fri, 31 Mar 2017 03:00:51 +" wrote: DS> bq. Let's make 'em uniform and argue later. DS> Agreed. I find it very annoying that the indentation on some of them are internally inconsistent. DS> On Wed, Mar 29, 2017 at 7:19 PM Erick Ericksonwrote: DS> I don't think we've ever really had a formal rule, certainly not one DS> that's been enforced. Personally I'd be satisfied with just doing DS> whatever IntelliJ or Eclipse are happy with. DS> DS> I did finally take time to look and you can make IntelliJ recognize DS> "managed-schema" as an XML file with settings>>editor>>file types DS> DS> Let's make 'em uniform and argue later. DS> DS> Erick DS> DS> On Wed, Mar 29, 2017 at 4:10 PM, Alexandre Rafalovitch DS> wrote: >> I am redoing an example and realized I have no idea what the >> formatting rules are. >> >> In the code, the WIKI says, we should use 2-spaces offset. >> >> What about in config (XML) files? >> >> I see no tabs, so at least that part is clear. But with spaces, I see >> all sorts of things. >> >> I seem to see a mix of 4 and 2 spaces in managed-schema. I seem to see >> 2 spaces in solrconfig.xml. I am not sure what I see in DIH >> configuration files. >> >> Also, there are comments and their multi-line internal comments. I >> seem to see 1 space there. Also, does the text in the comment start on >> the same line as comment indicator (> http://www.solr-start.com/ - Resources for Solr users, new and experienced >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> DS> DS> - DS> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org DS> For additional commands, e-mail: dev-h...@lucene.apache.org -- With best wishes,Alex Ott http://alexott.net/ Twitter: alexott_en (English), alexott (Russian) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-11795) Add Solr metrics exporter for Prometheus
[ https://issues.apache.org/jira/browse/SOLR-11795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Sekiguchi resolved SOLR-11795. --- Resolution: Fixed Mark as resolved. Thanks everyone! > Add Solr metrics exporter for Prometheus > > > Key: SOLR-11795 > URL: https://issues.apache.org/jira/browse/SOLR-11795 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Affects Versions: 7.2 >Reporter: Minoru Osuka >Assignee: Koji Sekiguchi >Priority: Minor > Fix For: 7.3, master (8.0) > > Attachments: SOLR-11795-10.patch, SOLR-11795-11.patch, > SOLR-11795-2.patch, SOLR-11795-3.patch, SOLR-11795-4.patch, > SOLR-11795-5.patch, SOLR-11795-6.patch, SOLR-11795-7.patch, > SOLR-11795-8.patch, SOLR-11795-9.patch, SOLR-11795-dev-tools.patch, > SOLR-11795-ref-guide.patch, SOLR-11795.patch, solr-dashboard.png, > solr-exporter-diagram.png > > Time Spent: 20m > Remaining Estimate: 0h > > I 'd like to monitor Solr using Prometheus and Grafana. > I've already created Solr metrics exporter for Prometheus. I'd like to > contribute to contrib directory if you don't mind. > !solr-exporter-diagram.png|thumbnail! > !solr-dashboard.png|thumbnail! -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-12081) Improve docs on query parsing: embedded queries, uf (edismax)
[ https://issues.apache.org/jira/browse/SOLR-12081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396096#comment-16396096 ] David Smiley edited comment on SOLR-12081 at 3/13/18 4:51 AM: -- Can someone please review... maybe [~ctargett] since it's the ref guide? I wasn't sure when I needed to escape chars or not; I've observed that the Markdown plugin to IntelliJ doesn't *quite* follow the nitty gritty details consistently. I tried to build the PDF but ran afowl of errors recently reported in SOLR-10297. I tried to do the HTML version by attempting to see if I could use a Docker Jekyll image but ran into errors and I'm not sure what the cause is. I could of course try to install that stuff "normally" but I'm keen on Docker and apparently I want to make my life more difficult than needed today. was (Author: dsmiley): Can someone please review... maybe [~cassandra] since it's the ref guide? I wasn't sure when I needed to escape chars or not; I've observed that the Markdown plugin to IntelliJ doesn't *quite* follow the nitty gritty details consistently. I tried to build the PDF but ran afowl of errors recently reported in SOLR-10297. I tried to do the HTML version by attempting to see if I could use a Docker Jekyll image but ran into errors and I'm not sure what the cause is. I could of course try to install that stuff "normally" but I'm keen on Docker and apparently I want to make my life more difficult than needed today. > Improve docs on query parsing: embedded queries, uf (edismax) > - > > Key: SOLR-12081 > URL: https://issues.apache.org/jira/browse/SOLR-12081 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: David Smiley >Assignee: David Smiley >Priority: Major > Attachments: > SOLR-12081__improve_docs_on_query_parsing,_embedded_queries.patch, > SOLR-12081__improve_docs_on_query_parsing,_embedded_queries.patch > > > The {{uf}} parameter is a *space* separated list (not comma). Furthermore the > docs should be improved -- see > https://issues.apache.org/jira/browse/SOLR-11501?focusedCommentId=16326592=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16326592 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12081) Improve docs on query parsing: embedded queries, uf (edismax)
[ https://issues.apache.org/jira/browse/SOLR-12081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396545#comment-16396545 ] David Smiley commented on SOLR-12081: - Updated patch. I got the PDF version finally; SOLR-10297 wasn't a blocker after all (I was confused). I think I finally got all the escaping right; it was difficult, and each debug round to see if it was right was kinda painful. > Improve docs on query parsing: embedded queries, uf (edismax) > - > > Key: SOLR-12081 > URL: https://issues.apache.org/jira/browse/SOLR-12081 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: David Smiley >Assignee: David Smiley >Priority: Major > Attachments: > SOLR-12081__improve_docs_on_query_parsing,_embedded_queries.patch, > SOLR-12081__improve_docs_on_query_parsing,_embedded_queries.patch > > > The {{uf}} parameter is a *space* separated list (not comma). Furthermore the > docs should be improved -- see > https://issues.apache.org/jira/browse/SOLR-11501?focusedCommentId=16326592=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16326592 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12081) Improve docs on query parsing: embedded queries, uf (edismax)
[ https://issues.apache.org/jira/browse/SOLR-12081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated SOLR-12081: Attachment: SOLR-12081__improve_docs_on_query_parsing,_embedded_queries.patch > Improve docs on query parsing: embedded queries, uf (edismax) > - > > Key: SOLR-12081 > URL: https://issues.apache.org/jira/browse/SOLR-12081 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: David Smiley >Assignee: David Smiley >Priority: Major > Attachments: > SOLR-12081__improve_docs_on_query_parsing,_embedded_queries.patch, > SOLR-12081__improve_docs_on_query_parsing,_embedded_queries.patch > > > The {{uf}} parameter is a *space* separated list (not comma). Furthermore the > docs should be improved -- see > https://issues.apache.org/jira/browse/SOLR-11501?focusedCommentId=16326592=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16326592 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-11661) New HDFS collection reuses unremoved data from a deleted HDFS collection with same name causes inconsistent view of documents
[ https://issues.apache.org/jira/browse/SOLR-11661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cao Manh Dat resolved SOLR-11661. - Resolution: Fixed Assignee: Cao Manh Dat > New HDFS collection reuses unremoved data from a deleted HDFS collection with > same name causes inconsistent view of documents > - > > Key: SOLR-11661 > URL: https://issues.apache.org/jira/browse/SOLR-11661 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Cao Manh Dat >Priority: Major > Fix For: 7.3, master (8.0) > > Attachments: 11458-2-MoveReplicaHDFSTest-log.txt, SOLR-11661.patch, > SOLR-11661.patch > > > While testing SOLR-11458, [~ab] ran into an interesting failure which > resulted in different document counts between leader and replica. The test is > MoveReplicaHDFSTest on jira/solr-11458-2 branch. > The failure is rare but reproducible on beasting: > {code} > reproduce with: ant test -Dtestcase=MoveReplicaHDFSTest > -Dtests.method=testNormalFailedMove -Dtests.seed=161856CB543CD71C > -Dtests.slow=true -Dtests.locale=ar-SA -Dtests.timezone=US/Michigan > -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 >[junit4] FAILURE 14.2s | MoveReplicaHDFSTest.testNormalFailedMove <<< >[junit4]> Throwable #1: java.lang.AssertionError: expected:<100> but > was:<56> >[junit4]> at > __randomizedtesting.SeedInfo.seed([161856CB543CD71C:31134983787E4905]:0) >[junit4]> at > org.apache.solr.cloud.MoveReplicaTest.testFailedMove(MoveReplicaTest.java:305) >[junit4]> at > org.apache.solr.cloud.MoveReplicaHDFSTest.testNormalFailedMove(MoveReplicaHDFSTest.java:69) > {code} > The root problem here is when the old replica is not live during deletion of > a collection, the correspond HDFS data of that replica is not removed > therefore when a new collection with the same name as the deleted collection > is created, new replicas will reuse the old HDFS data. This leads to many > problems in leader election and recovery -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-10-ea+43) - Build # 21630 - Still Unstable!
Error processing tokens: Error while parsing action 'Text/ZeroOrMore/FirstOf/Token/DelimitedToken/DelimitedToken_Action3' at input position (line 79, pos 4): )"} ^ java.lang.OutOfMemoryError: Java heap space - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-SmokeRelease-7.x - Build # 173 - Still Failing
Error processing tokens: Error while parsing action 'Text/ZeroOrMore/FirstOf/Token/DelimitedToken/DelimitedToken_Action3' at input position (line 76, pos 4): )"} ^ java.lang.OutOfMemoryError: Java heap space - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12028) BadApple and AwaitsFix annotations usage
[ https://issues.apache.org/jira/browse/SOLR-12028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396490#comment-16396490 ] ASF subversion and git services commented on SOLR-12028: Commit b2856a14620aa3132899dcac3512e67162400c5b in lucene-solr's branch refs/heads/branch_7x from [~caomanhdat] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b2856a1 ] SOLR-12028: Remove BadApples for ZkShardTermsTest.testParticipationOfReplicas > BadApple and AwaitsFix annotations usage > > > Key: SOLR-12028 > URL: https://issues.apache.org/jira/browse/SOLR-12028 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-12016-buildsystem.patch, SOLR-12028-3-Mar.patch, > SOLR-12028-sysprops-reproduce.patch, SOLR-12028.patch, SOLR-12028.patch > > > There's a long discussion of this topic at SOLR-12016. Here's a summary: > - BadApple annotations are used for tests that intermittently fail, say < 30% > of the time. Tests that fail more often shold be moved to AwaitsFix. This is, > of course, a judgement call > - AwaitsFix annotations are used for tests that, for some reason, the problem > can't be fixed immediately. Likely reasons are third-party dependencies, > extreme difficulty tracking down, dependency on another JIRA etc. > Jenkins jobs will typically run with BadApple disabled to cut down on noise. > Periodically Jenkins jobs will be run with BadApples enabled so BadApple > tests won't be lost and reports can be generated. Tests that run with > BadApples disabled that fail require _immediate_ attention. > The default for developers is that BadApple is enabled. > If you are working on one of these tests and cannot get the test to fail > locally, it is perfectly acceptable to comment the annotation out. You should > let the dev list know that this is deliberate. > This JIRA is a placeholder for BadApple tests to point to between the times > they're identified as BadApple and they're either fixed or changed to > AwaitsFix or assigned their own JIRA. > I've assigned this to myself to track so I don't lose track of it. No one > person will fix all of these issues, this will be an ongoing technical debt > cleanup effort. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12028) BadApple and AwaitsFix annotations usage
[ https://issues.apache.org/jira/browse/SOLR-12028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396487#comment-16396487 ] ASF subversion and git services commented on SOLR-12028: Commit 0cd9f7f35af84ce769a37a2ef1afe8990c5b061a in lucene-solr's branch refs/heads/master from [~caomanhdat] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0cd9f7f ] SOLR-12028: Remove BadApples for ZkShardTermsTest.testParticipationOfReplicas > BadApple and AwaitsFix annotations usage > > > Key: SOLR-12028 > URL: https://issues.apache.org/jira/browse/SOLR-12028 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-12016-buildsystem.patch, SOLR-12028-3-Mar.patch, > SOLR-12028-sysprops-reproduce.patch, SOLR-12028.patch, SOLR-12028.patch > > > There's a long discussion of this topic at SOLR-12016. Here's a summary: > - BadApple annotations are used for tests that intermittently fail, say < 30% > of the time. Tests that fail more often shold be moved to AwaitsFix. This is, > of course, a judgement call > - AwaitsFix annotations are used for tests that, for some reason, the problem > can't be fixed immediately. Likely reasons are third-party dependencies, > extreme difficulty tracking down, dependency on another JIRA etc. > Jenkins jobs will typically run with BadApple disabled to cut down on noise. > Periodically Jenkins jobs will be run with BadApples enabled so BadApple > tests won't be lost and reports can be generated. Tests that run with > BadApples disabled that fail require _immediate_ attention. > The default for developers is that BadApple is enabled. > If you are working on one of these tests and cannot get the test to fail > locally, it is perfectly acceptable to comment the annotation out. You should > let the dev list know that this is deliberate. > This JIRA is a placeholder for BadApple tests to point to between the times > they're identified as BadApple and they're either fixed or changed to > AwaitsFix or assigned their own JIRA. > I've assigned this to myself to track so I don't lose track of it. No one > person will fix all of these issues, this will be an ongoing technical debt > cleanup effort. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr issue #287: SOLR-11331: Ability to Debug Solr With Eclipse IDE
Github user mrkarthik commented on the issue: https://github.com/apache/lucene-solr/pull/287 I have updated the PR. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11331) Ability to Debug Solr With Eclipse IDE
[ https://issues.apache.org/jira/browse/SOLR-11331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karthik Ramachandran updated SOLR-11331: Attachment: SOLR-11331.diff > Ability to Debug Solr With Eclipse IDE > -- > > Key: SOLR-11331 > URL: https://issues.apache.org/jira/browse/SOLR-11331 > Project: Solr > Issue Type: Improvement >Affects Versions: 6.6.2 >Reporter: Karthik Ramachandran >Priority: Minor > Labels: eclipse > Attachments: SOLR-11331.diff, SOLR-11331.patch, SOLR-11331.patch, > UI.png > > > Ability to Debug Solr With Eclipse IDE -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11331) Ability to Debug Solr With Eclipse IDE
[ https://issues.apache.org/jira/browse/SOLR-11331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396480#comment-16396480 ] Karthik Ramachandran commented on SOLR-11331: - I had removed a macro that was applied during build. I have updated the PR and patch. > Ability to Debug Solr With Eclipse IDE > -- > > Key: SOLR-11331 > URL: https://issues.apache.org/jira/browse/SOLR-11331 > Project: Solr > Issue Type: Improvement >Affects Versions: 6.6.2 >Reporter: Karthik Ramachandran >Priority: Minor > Labels: eclipse > Attachments: SOLR-11331.diff, SOLR-11331.patch, SOLR-11331.patch, > UI.png > > > Ability to Debug Solr With Eclipse IDE -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8202) Add a FixedShingleFilter
[ https://issues.apache.org/jira/browse/LUCENE-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396431#comment-16396431 ] David Smiley commented on LUCENE-8202: -- I suppose this is for fields that one might use in Solr "pf2" "pf3" etc ? Can ShingleGraphFilter do what this does too, albeit slower and with greater chance of bugs? It appears so. Maybe we only need one Factory, and the Factory can produce the Filter most appropriate based on the configuration? > Add a FixedShingleFilter > > > Key: LUCENE-8202 > URL: https://issues.apache.org/jira/browse/LUCENE-8202 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Attachments: LUCENE-8202.patch > > > In LUCENE-3475 I tried to make a ShingleGraphFilter that could accept and > emit arbitrary graphs, while duplicating all the functionality of the > existing ShingleFilter. This ends up being extremely hairy, and doesn't play > well with query parsers. > I'd like to step back and try and create a simpler shingle filter that can be > used for index-time phrase tokenization only. It will have a single fixed > shingle size, can deal with single-token synonyms, and won't emit unigrams. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3475) ShingleFilter should handle positionIncrement of zero, e.g. synonyms
[ https://issues.apache.org/jira/browse/LUCENE-3475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396416#comment-16396416 ] David Smiley commented on LUCENE-3475: -- bq. Some of this behaviour is different to the standard ShingleFilter, so I think we should probably keep them separate (while deprecating the old version and removing in master) Wouldn't this be a Version switch situation instead? Why bother the users with a new name instead? > ShingleFilter should handle positionIncrement of zero, e.g. synonyms > > > Key: LUCENE-3475 > URL: https://issues.apache.org/jira/browse/LUCENE-3475 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Reporter: Cameron >Assignee: Alan Woodward >Priority: Minor > Labels: newdev > Attachments: LUCENE-3475.patch, LUCENE-3475.patch > > > ShingleFilter is creating shingles for a single term that has been expanded > by synonyms when it shouldn't. The position increment is 0. > As an example, I have an Analyzer with a SynonymFilter followed by a > ShingleFilter. Assuming car and auto are synonyms, the SynonymFilter produces > two tokens and position 1: car, auto. The ShingleFilter is then producing 3 > tokens, when there should only be two: car, car auto, auto. This behavior > seems incorrect. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12064) NullPointerException in JSON facet
[ https://issues.apache.org/jira/browse/SOLR-12064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396411#comment-16396411 ] ASF subversion and git services commented on SOLR-12064: Commit 768349b25253791158debeefaf43242a117247d5 in lucene-solr's branch refs/heads/branch_7x from [~yo...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=768349b ] SOLR-12064: resize reused accs to fix bugs with limit:-1 and missing:true > NullPointerException in JSON facet > -- > > Key: SOLR-12064 > URL: https://issues.apache.org/jira/browse/SOLR-12064 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module >Affects Versions: 7.2 >Reporter: Karthik Ramachandran >Assignee: Yonik Seeley >Priority: Major > Attachments: SOLR-12064.patch, patch.diff, patch.diff > > Time Spent: 10m > Remaining Estimate: 0h > > NullPointerException in JSON facet when using terms with limit -1 and more > than one facet > {f1:{terms:{field:'cat_ldS', limit:-1, sort:'n1 desc', > facet:{n1:'avg(num_ldS)', n2:'sum(num_ldS)'} > {noformat} > java.lang.NullPointerException > at org.apache.solr.search.facet.AvgSlotAcc.collect(SlotAcc.java:390) > at > org.apache.solr.search.facet.FacetFieldProcessor$MultiAcc.collect(FacetFieldProcessor.java:510) > at org.apache.solr.search.facet.SlotAcc.collect(SlotAcc.java:97) > at > org.apache.solr.search.facet.FacetFieldProcessor.collectFirstPhase(FacetFieldProcessor.java:220) > at > org.apache.solr.search.facet.UnInvertedField.collectDocsGeneric(UnInvertedField.java:431) > at > org.apache.solr.search.facet.UnInvertedField.collectDocs(UnInvertedField.java:410) > at > org.apache.solr.search.facet.FacetFieldProcessorByArrayUIF.collectDocs(FacetFieldProcessorByArrayUIF.java:64) > at > org.apache.solr.search.facet.FacetFieldProcessorByArray.calcFacets(FacetFieldProcessorByArray.java:108) > at > org.apache.solr.search.facet.FacetFieldProcessorByArray.process(FacetFieldProcessorByArray.java:58) > at > org.apache.solr.search.facet.FacetProcessor.processSubs(FacetProcessor.java:460) > at > org.apache.solr.search.facet.FacetProcessor.fillBucket(FacetProcessor.java:407) > at > org.apache.solr.search.facet.FacetQueryProcessor.process(FacetQuery.java:64) > at org.apache.solr.search.facet.FacetModule.process(FacetModule.java:154) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:180) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:2503) > at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:710) > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326) > {noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12064) NullPointerException in JSON facet
[ https://issues.apache.org/jira/browse/SOLR-12064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396413#comment-16396413 ] ASF subversion and git services commented on SOLR-12064: Commit a348a8c46830010d00acbd6b8365a329179abe17 in lucene-solr's branch refs/heads/branch_7_3 from [~yo...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a348a8c ] SOLR-12064: resize reused accs to fix bugs with limit:-1 and missing:true > NullPointerException in JSON facet > -- > > Key: SOLR-12064 > URL: https://issues.apache.org/jira/browse/SOLR-12064 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module >Affects Versions: 7.2 >Reporter: Karthik Ramachandran >Assignee: Yonik Seeley >Priority: Major > Attachments: SOLR-12064.patch, patch.diff, patch.diff > > Time Spent: 10m > Remaining Estimate: 0h > > NullPointerException in JSON facet when using terms with limit -1 and more > than one facet > {f1:{terms:{field:'cat_ldS', limit:-1, sort:'n1 desc', > facet:{n1:'avg(num_ldS)', n2:'sum(num_ldS)'} > {noformat} > java.lang.NullPointerException > at org.apache.solr.search.facet.AvgSlotAcc.collect(SlotAcc.java:390) > at > org.apache.solr.search.facet.FacetFieldProcessor$MultiAcc.collect(FacetFieldProcessor.java:510) > at org.apache.solr.search.facet.SlotAcc.collect(SlotAcc.java:97) > at > org.apache.solr.search.facet.FacetFieldProcessor.collectFirstPhase(FacetFieldProcessor.java:220) > at > org.apache.solr.search.facet.UnInvertedField.collectDocsGeneric(UnInvertedField.java:431) > at > org.apache.solr.search.facet.UnInvertedField.collectDocs(UnInvertedField.java:410) > at > org.apache.solr.search.facet.FacetFieldProcessorByArrayUIF.collectDocs(FacetFieldProcessorByArrayUIF.java:64) > at > org.apache.solr.search.facet.FacetFieldProcessorByArray.calcFacets(FacetFieldProcessorByArray.java:108) > at > org.apache.solr.search.facet.FacetFieldProcessorByArray.process(FacetFieldProcessorByArray.java:58) > at > org.apache.solr.search.facet.FacetProcessor.processSubs(FacetProcessor.java:460) > at > org.apache.solr.search.facet.FacetProcessor.fillBucket(FacetProcessor.java:407) > at > org.apache.solr.search.facet.FacetQueryProcessor.process(FacetQuery.java:64) > at org.apache.solr.search.facet.FacetModule.process(FacetModule.java:154) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:180) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:2503) > at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:710) > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326) > {noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [jira] [Commented] (SOLR-12059) Unable to rename solr.xml
Probably the focus here is to just allow the rename of solr.xml, since other filenames in the first layer can be successfully renamed except solr.xml? The SolrXmlConfig is under the Jar file solr-core-7.2.1.jar, which we have renamed it to my-core-7.2.1.jar For other things in the log, we can deal with them again another time if required. I do see some of the entries in the log are hard coded in the source code. Regards, Edwin On 13 March 2018 at 00:45, Erick Erickson (JIRA)wrote: > > [ https://issues.apache.org/jira/browse/SOLR-12059?page= > com.atlassian.jira.plugin.system.issuetabpanels:comment- > tabpanel=16395490#comment-16395490 ] > > Erick Erickson commented on SOLR-12059: > --- > > close as "won't fix"? > > > Unable to rename solr.xml > > - > > > > Key: SOLR-12059 > > URL: https://issues.apache.org/jira/browse/SOLR-12059 > > Project: Solr > > Issue Type: Improvement > > Security Level: Public(Default Security Level. Issues are Public) > >Affects Versions: 6.5.1 > > Environment: Renaming of solr,xml in the $SOLR_HOME directory > >Reporter: Edwin Yeo Zheng Lin > >Priority: Major > > > > I am able to rename the flie names like solrconfig.xml and solr.log to > custom names like myconfig.xml and my.log quite seamlessly. > > However, I am not able to rename the same for solr.xml. Understand that > the solr.xml is hard-coded at the SolrXmlConfig.java. Meaning it requires a > re-compile of the Jar file in order to rename it. > > Since we can rename files like solrconfig.xml from the properties files, > so we should do the same for solr.xml? > > > > > > > > -- > This message was sent by Atlassian JIRA > (v7.6.3#76005) > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
[jira] [Updated] (SOLR-12083) RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled
[ https://issues.apache.org/jira/browse/SOLR-12083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amrit Sarkar updated SOLR-12083: Attachment: SOLR-12083.patch > RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled > > > Key: SOLR-12083 > URL: https://issues.apache.org/jira/browse/SOLR-12083 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: CDCR >Affects Versions: 7.2, 7.2.1 >Reporter: Amrit Sarkar >Priority: Major > Attachments: SOLR-12083.patch > > > On the lines of SOLR-12063: Bidirectional support introduced serious bugs and > here RealTimeGetComponent is broken. > As we have added additional flag to each {{tlog}} entry, the following > assertions fail when Cdcr enabled: > {code} > if (oper == UpdateLog.UPDATE_INPLACE) { > assert entry.size() == 5; > } > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12064) NullPointerException in JSON facet
[ https://issues.apache.org/jira/browse/SOLR-12064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396387#comment-16396387 ] ASF subversion and git services commented on SOLR-12064: Commit 68d8eb45046e01b511b45efbdc72323670956fbd in lucene-solr's branch refs/heads/master from [~yo...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=68d8eb4 ] SOLR-12064: resize reused accs to fix bugs with limit:-1 and missing:true > NullPointerException in JSON facet > -- > > Key: SOLR-12064 > URL: https://issues.apache.org/jira/browse/SOLR-12064 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module >Affects Versions: 7.2 >Reporter: Karthik Ramachandran >Assignee: Yonik Seeley >Priority: Major > Attachments: SOLR-12064.patch, patch.diff, patch.diff > > Time Spent: 10m > Remaining Estimate: 0h > > NullPointerException in JSON facet when using terms with limit -1 and more > than one facet > {f1:{terms:{field:'cat_ldS', limit:-1, sort:'n1 desc', > facet:{n1:'avg(num_ldS)', n2:'sum(num_ldS)'} > {noformat} > java.lang.NullPointerException > at org.apache.solr.search.facet.AvgSlotAcc.collect(SlotAcc.java:390) > at > org.apache.solr.search.facet.FacetFieldProcessor$MultiAcc.collect(FacetFieldProcessor.java:510) > at org.apache.solr.search.facet.SlotAcc.collect(SlotAcc.java:97) > at > org.apache.solr.search.facet.FacetFieldProcessor.collectFirstPhase(FacetFieldProcessor.java:220) > at > org.apache.solr.search.facet.UnInvertedField.collectDocsGeneric(UnInvertedField.java:431) > at > org.apache.solr.search.facet.UnInvertedField.collectDocs(UnInvertedField.java:410) > at > org.apache.solr.search.facet.FacetFieldProcessorByArrayUIF.collectDocs(FacetFieldProcessorByArrayUIF.java:64) > at > org.apache.solr.search.facet.FacetFieldProcessorByArray.calcFacets(FacetFieldProcessorByArray.java:108) > at > org.apache.solr.search.facet.FacetFieldProcessorByArray.process(FacetFieldProcessorByArray.java:58) > at > org.apache.solr.search.facet.FacetProcessor.processSubs(FacetProcessor.java:460) > at > org.apache.solr.search.facet.FacetProcessor.fillBucket(FacetProcessor.java:407) > at > org.apache.solr.search.facet.FacetQueryProcessor.process(FacetQuery.java:64) > at org.apache.solr.search.facet.FacetModule.process(FacetModule.java:154) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:180) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:2503) > at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:710) > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326) > {noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_162) - Build # 21629 - Still Unstable!
Error processing tokens: Error while parsing action 'Text/ZeroOrMore/FirstOf/Token/DelimitedToken/DelimitedToken_Action3' at input position (line 79, pos 4): )"} ^ java.lang.OutOfMemoryError: Java heap space - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-repro - Build # 258 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/258/ [...truncated 28 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/12/consoleText [repro] Revision: b82ce515f04eaedf4032c2ee3188620e9644a925 [repro] Repro line: ant test -Dtestcase=HdfsAutoAddReplicasIntegrationTest -Dtests.method=testSimple -Dtests.seed=7DD583F7A5B89E45 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=en-ZA -Dtests.timezone=Asia/Novosibirsk -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=TriggerIntegrationTest -Dtests.method=testEventQueue -Dtests.seed=7DD583F7A5B89E45 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=sr-BA -Dtests.timezone=America/Eirunepe -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=AtomicUpdateProcessorFactoryTest -Dtests.method=testMultipleThreads -Dtests.seed=7DD583F7A5B89E45 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ar-SA -Dtests.timezone=Asia/Dili -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=TestReplicationHandler -Dtests.method=doTestIndexFetchOnMasterRestart -Dtests.seed=7DD583F7A5B89E45 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ja-JP-u-ca-japanese-x-lvariant-JP -Dtests.timezone=America/Cancun -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=AutoAddReplicasIntegrationTest -Dtests.method=testSimple -Dtests.seed=7DD583F7A5B89E45 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=th-TH -Dtests.timezone=America/Manaus -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=TestLTRReRankingPipeline -Dtests.method=testDifferentTopN -Dtests.seed=5394B1BAA58B6095 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ar-QA -Dtests.timezone=America/New_York -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: b82ce515f04eaedf4032c2ee3188620e9644a925 [repro] git fetch [repro] git checkout b82ce515f04eaedf4032c2ee3188620e9644a925 [...truncated 1 lines...] [repro] git merge --ff-only [...truncated 1 lines...] [repro] ant clean [...truncated 6 lines...] [repro] Test suites by module: [repro]solr/contrib/ltr [repro] TestLTRReRankingPipeline [repro]solr/core [repro] TestReplicationHandler [repro] AutoAddReplicasIntegrationTest [repro] AtomicUpdateProcessorFactoryTest [repro] TriggerIntegrationTest [repro] HdfsAutoAddReplicasIntegrationTest [repro] ant compile-test [...truncated 2563 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.TestLTRReRankingPipeline" -Dtests.showOutput=onerror -Dtests.seed=5394B1BAA58B6095 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ar-QA -Dtests.timezone=America/New_York -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [...truncated 135 lines...] [repro] Setting last failure code to 256 [repro] ant compile-test [...truncated 1329 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=25 -Dtests.class="*.TestReplicationHandler|*.AutoAddReplicasIntegrationTest|*.AtomicUpdateProcessorFactoryTest|*.TriggerIntegrationTest|*.HdfsAutoAddReplicasIntegrationTest" -Dtests.showOutput=onerror -Dtests.seed=7DD583F7A5B89E45 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ja-JP-u-ca-japanese-x-lvariant-JP -Dtests.timezone=America/Cancun -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [...truncated 74164 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 0/5 failed: org.apache.solr.update.processor.AtomicUpdateProcessorFactoryTest [repro] 2/5 failed: org.apache.solr.cloud.autoscaling.TriggerIntegrationTest [repro] 5/5 failed: org.apache.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest [repro] 5/5 failed: org.apache.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest [repro] 5/5 failed: org.apache.solr.handler.TestReplicationHandler [repro] 5/5 failed: org.apache.solr.ltr.TestLTRReRankingPipeline [repro] Re-testing 100% failures at the tip of master [repro] ant clean [...truncated 8 lines...] [repro] Test suites by module: [repro]solr/contrib/ltr [repro] TestLTRReRankingPipeline [repro]solr/core [repro] TestReplicationHandler [repro] AutoAddReplicasIntegrationTest [repro] HdfsAutoAddReplicasIntegrationTest [repro] ant compile-test [...truncated 2563 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.TestLTRReRankingPipeline" -Dtests.showOutput=onerror -Dtests.seed=5394B1BAA58B6095 -Dtests.multiplier=2
[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk-9.0.1) - Build # 500 - Still unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/500/ Java: 64bit/jdk-9.0.1 -XX:-UseCompressedOops -XX:+UseSerialGC 8 tests failed. FAILED: junit.framework.TestSuite.org.apache.lucene.index.TestBackwardsCompatibility Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_1E4514E1A2F8F18D-001\4.10.1-cfs-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_1E4514E1A2F8F18D-001\4.10.1-cfs-001 C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_1E4514E1A2F8F18D-001\4.7.2-cfs-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_1E4514E1A2F8F18D-001\4.7.2-cfs-001 C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_1E4514E1A2F8F18D-001\4.1.0-nocfs-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_1E4514E1A2F8F18D-001\4.1.0-nocfs-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_1E4514E1A2F8F18D-001\4.10.1-cfs-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_1E4514E1A2F8F18D-001\4.10.1-cfs-001 C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_1E4514E1A2F8F18D-001\4.7.2-cfs-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_1E4514E1A2F8F18D-001\4.7.2-cfs-001 C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_1E4514E1A2F8F18D-001\4.1.0-nocfs-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_1E4514E1A2F8F18D-001\4.1.0-nocfs-001 at __randomizedtesting.SeedInfo.seed([1E4514E1A2F8F18D]:0) at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329) at org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216) at com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) FAILED: junit.framework.TestSuite.org.apache.lucene.index.TestAtomicUpdate Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.index.TestAtomicUpdate_A08BE6B2EB105C7D-001\lucene.test.atomic-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.index.TestAtomicUpdate_A08BE6B2EB105C7D-001\lucene.test.atomic-001 C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.index.TestAtomicUpdate_A08BE6B2EB105C7D-001\lucene.test.atomic-001\segments_h: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.index.TestAtomicUpdate_A08BE6B2EB105C7D-001\lucene.test.atomic-001\segments_h
[jira] [Created] (SOLR-12083) RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled
Amrit Sarkar created SOLR-12083: --- Summary: RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled Key: SOLR-12083 URL: https://issues.apache.org/jira/browse/SOLR-12083 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: CDCR Affects Versions: 7.2, 7.2.1 Reporter: Amrit Sarkar On the lines of SOLR-12063: Bidirectional support introduced serious bugs and here RealTimeGetComponent is broken. As we have added additional flag to each {{tlog}} entry, the following assertions fail when Cdcr enabled: {code} if (oper == UpdateLog.UPDATE_INPLACE) { assert entry.size() == 5; } {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-repro - Build # 257 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/257/ [...truncated 32 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-Tests-master/2420/consoleText [repro] Revision: 28ddb5f355bc1ebd6ba88007d5a380cd1bba7f45 [repro] Repro line: ant test -Dtestcase=LeaderVoteWaitTimeoutTest -Dtests.method=testMostInSyncReplicasCanWinElection -Dtests.seed=8767B62FF5934BF1 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=de-DE -Dtests.timezone=US/Indiana-Starke -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] Repro line: ant test -Dtestcase=TriggerIntegrationTest -Dtests.method=testMetricTrigger -Dtests.seed=8767B62FF5934BF1 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=bg-BG -Dtests.timezone=Canada/Saskatchewan -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] Repro line: ant test -Dtestcase=CollectionsAPISolrJTest -Dtests.method=testSplitShard -Dtests.seed=8767B62FF5934BF1 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=es-PA -Dtests.timezone=America/Asuncion -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] Repro line: ant test -Dtestcase=ScheduledMaintenanceTriggerTest -Dtests.method=testInactiveShardCleanup -Dtests.seed=8767B62FF5934BF1 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=ar-SA -Dtests.timezone=Europe/Madrid -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: b82ce515f04eaedf4032c2ee3188620e9644a925 [repro] git fetch [repro] git checkout 28ddb5f355bc1ebd6ba88007d5a380cd1bba7f45 [...truncated 2 lines...] [repro] git merge --ff-only [...truncated 1 lines...] [repro] ant clean [...truncated 6 lines...] [repro] Test suites by module: [repro]solr/core [repro] TriggerIntegrationTest [repro] LeaderVoteWaitTimeoutTest [repro] ScheduledMaintenanceTriggerTest [repro] CollectionsAPISolrJTest [repro] ant compile-test [...truncated 3292 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=20 -Dtests.class="*.TriggerIntegrationTest|*.LeaderVoteWaitTimeoutTest|*.ScheduledMaintenanceTriggerTest|*.CollectionsAPISolrJTest" -Dtests.showOutput=onerror -Dtests.seed=8767B62FF5934BF1 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=bg-BG -Dtests.timezone=Canada/Saskatchewan -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [...truncated 15921 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 0/5 failed: org.apache.solr.cloud.CollectionsAPISolrJTest [repro] 0/5 failed: org.apache.solr.cloud.LeaderVoteWaitTimeoutTest [repro] 2/5 failed: org.apache.solr.cloud.autoscaling.ScheduledMaintenanceTriggerTest [repro] 2/5 failed: org.apache.solr.cloud.autoscaling.TriggerIntegrationTest [repro] git checkout b82ce515f04eaedf4032c2ee3188620e9644a925 [...truncated 2 lines...] [repro] Exiting with code 256 [...truncated 6 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-7.x - Build # 498 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/498/ 7 tests failed. FAILED: org.apache.solr.cloud.BasicDistributedZkTest.test Error Message: Test abandoned because suite timeout was reached. Stack Trace: java.lang.Exception: Test abandoned because suite timeout was reached. at __randomizedtesting.SeedInfo.seed([9AE3B2F8A0EB66C1]:0) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest Error Message: Suite timeout exceeded (>= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (>= 720 msec). at __randomizedtesting.SeedInfo.seed([9AE3B2F8A0EB66C1]:0) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestLeaderElectionZkExpiry Error Message: ObjectTracker found 1 object(s) that were not released!!! [Overseer] org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.solr.cloud.Overseer at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.cloud.Overseer.start(Overseer.java:545) at org.apache.solr.cloud.OverseerElectionContext.runLeaderProcess(ElectionContext.java:850) at org.apache.solr.cloud.LeaderElector.runIamLeaderProcess(LeaderElector.java:170) at org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:135) at org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:307) at org.apache.solr.cloud.LeaderElector.retryElection(LeaderElector.java:393) at org.apache.solr.cloud.ZkController.rejoinOverseerElection(ZkController.java:2055) at org.apache.solr.cloud.Overseer$ClusterStateUpdater.checkIfIamStillLeader(Overseer.java:331) at java.lang.Thread.run(Thread.java:748) Stack Trace: java.lang.AssertionError: ObjectTracker found 1 object(s) that were not released!!! [Overseer] org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.solr.cloud.Overseer at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.cloud.Overseer.start(Overseer.java:545) at org.apache.solr.cloud.OverseerElectionContext.runLeaderProcess(ElectionContext.java:850) at org.apache.solr.cloud.LeaderElector.runIamLeaderProcess(LeaderElector.java:170) at org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:135) at org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:307) at org.apache.solr.cloud.LeaderElector.retryElection(LeaderElector.java:393) at org.apache.solr.cloud.ZkController.rejoinOverseerElection(ZkController.java:2055) at org.apache.solr.cloud.Overseer$ClusterStateUpdater.checkIfIamStillLeader(Overseer.java:331) at java.lang.Thread.run(Thread.java:748) at __randomizedtesting.SeedInfo.seed([9AE3B2F8A0EB66C1]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:301) at sun.reflect.GeneratedMethodAccessor65.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:897) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at
[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-9.0.4) - Build # 1521 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1521/ Java: 64bit/jdk-9.0.4 -XX:-UseCompressedOops -XX:+UseG1GC 5 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.autoscaling.TriggerIntegrationTest Error Message: ObjectTracker found 1 object(s) that were not released!!! [SolrZkClient] org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.solr.common.cloud.SolrZkClient at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:185) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:120) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:110) at org.apache.solr.common.cloud.ZkStateReader.(ZkStateReader.java:285) at org.apache.solr.client.solrj.impl.ZkClientClusterStateProvider.connect(ZkClientClusterStateProvider.java:155) at org.apache.solr.client.solrj.impl.CloudSolrClient.getZkStateReader(CloudSolrClient.java:342) at org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.(SolrClientNodeStateProvider.java:80) at org.apache.solr.client.solrj.impl.SolrClientCloudManager.getNodeStateProvider(SolrClientCloudManager.java:104) at org.apache.solr.cloud.autoscaling.MetricTrigger.run(MetricTrigger.java:143) at org.apache.solr.cloud.autoscaling.ScheduledTriggers$TriggerWrapper.run(ScheduledTriggers.java:572) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514) at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:300) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) at java.base/java.lang.Thread.run(Thread.java:844) Stack Trace: java.lang.AssertionError: ObjectTracker found 1 object(s) that were not released!!! [SolrZkClient] org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.solr.common.cloud.SolrZkClient at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:185) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:120) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:110) at org.apache.solr.common.cloud.ZkStateReader.(ZkStateReader.java:285) at org.apache.solr.client.solrj.impl.ZkClientClusterStateProvider.connect(ZkClientClusterStateProvider.java:155) at org.apache.solr.client.solrj.impl.CloudSolrClient.getZkStateReader(CloudSolrClient.java:342) at org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.(SolrClientNodeStateProvider.java:80) at org.apache.solr.client.solrj.impl.SolrClientCloudManager.getNodeStateProvider(SolrClientCloudManager.java:104) at org.apache.solr.cloud.autoscaling.MetricTrigger.run(MetricTrigger.java:143) at org.apache.solr.cloud.autoscaling.ScheduledTriggers$TriggerWrapper.run(ScheduledTriggers.java:572) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514) at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:300) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) at java.base/java.lang.Thread.run(Thread.java:844) at __randomizedtesting.SeedInfo.seed([37322C213120DB0F]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:301) at jdk.internal.reflect.GeneratedMethodAccessor76.invoke(Unknown Source) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:897) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at
[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-9.0.1) - Build # 7219 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7219/ Java: 64bit/jdk-9.0.1 -XX:-UseCompressedOops -XX:+UseG1GC 10 tests failed. FAILED: junit.framework.TestSuite.org.apache.lucene.store.TestNIOFSDirectory Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestNIOFSDirectory_436F2628257E928F-001\testLongs-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestNIOFSDirectory_436F2628257E928F-001\testLongs-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestNIOFSDirectory_436F2628257E928F-001\testLongs-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestNIOFSDirectory_436F2628257E928F-001\testLongs-001 at __randomizedtesting.SeedInfo.seed([436F2628257E928F]:0) at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329) at org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216) at com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) FAILED: junit.framework.TestSuite.org.apache.solr.analytics.value.CastingBooleanValueTest Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analytics\test\J0\temp\solr.analytics.value.CastingBooleanValueTest_1547EFDB58B7EACF-001\init-core-data-001: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analytics\test\J0\temp\solr.analytics.value.CastingBooleanValueTest_1547EFDB58B7EACF-001\init-core-data-001 C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analytics\test\J0\temp\solr.analytics.value.CastingBooleanValueTest_1547EFDB58B7EACF-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analytics\test\J0\temp\solr.analytics.value.CastingBooleanValueTest_1547EFDB58B7EACF-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analytics\test\J0\temp\solr.analytics.value.CastingBooleanValueTest_1547EFDB58B7EACF-001\init-core-data-001: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analytics\test\J0\temp\solr.analytics.value.CastingBooleanValueTest_1547EFDB58B7EACF-001\init-core-data-001 C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analytics\test\J0\temp\solr.analytics.value.CastingBooleanValueTest_1547EFDB58B7EACF-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analytics\test\J0\temp\solr.analytics.value.CastingBooleanValueTest_1547EFDB58B7EACF-001 at __randomizedtesting.SeedInfo.seed([1547EFDB58B7EACF]:0) at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329) at org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216) at com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at
[jira] [Commented] (LUCENE-4545) Better error reporting StemmerOverrideFilterFactory
[ https://issues.apache.org/jira/browse/LUCENE-4545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396237#comment-16396237 ] Shawn Heisey commented on LUCENE-4545: -- Found this issue because of a user having a problem. Uploaded a new patch against master (8.0). [~rcmuir], I didn't use LineNumberReader as you suggested. I did find an example of that elsewhere in the code, but using that would have required a more substantial rewrite. I'm willing to do that if you really think that's the way it should be done, but I was able to get line numbers more directly than what the first patch did. The code has changed since the first patch was made. I changed the regex in the split usage to any sequence of one or more whitespace characters, so it should be able to handle just about anything a user is likely to throw at it. I did find a few other usages elsewhere of split with a single tab character. Some of them should perhaps be reviewed for adjustment to the "any whitespace" regex. > Better error reporting StemmerOverrideFilterFactory > --- > > Key: LUCENE-4545 > URL: https://issues.apache.org/jira/browse/LUCENE-4545 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Affects Versions: 4.0 >Reporter: Markus Jelsma >Priority: Trivial > Fix For: 4.9, 6.0 > > Attachments: LUCENE-4545-trunk-1.patch, LUCENE-4545.patch > > > If the dictionary contains an error such as a space instead of a tab > somewhere in the dictionary it is hard to find the error in a long > dictionary. This patch includes the file and line number in the exception, > helping to debug it quickly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4545) Better error reporting StemmerOverrideFilterFactory
[ https://issues.apache.org/jira/browse/LUCENE-4545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey updated LUCENE-4545: - Attachment: LUCENE-4545.patch > Better error reporting StemmerOverrideFilterFactory > --- > > Key: LUCENE-4545 > URL: https://issues.apache.org/jira/browse/LUCENE-4545 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Affects Versions: 4.0 >Reporter: Markus Jelsma >Priority: Trivial > Fix For: 4.9, 6.0 > > Attachments: LUCENE-4545-trunk-1.patch, LUCENE-4545.patch > > > If the dictionary contains an error such as a space instead of a tab > somewhere in the dictionary it is hard to find the error in a long > dictionary. This patch includes the file and line number in the exception, > helping to debug it quickly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12063) Fix tlog entry indexes in UpdateLog for CDCR to work smoothly.
[ https://issues.apache.org/jira/browse/SOLR-12063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396204#comment-16396204 ] Amrit Sarkar commented on SOLR-12063: - In-place updates are never dropped in this part of the code. It only validates whether the {{prev-version}} is to be assigned or not. If {{CdcrTransactionLog}} and tlog entry size 6; {{TransactionLog}}, {{HDFSTransationLog}} and tlog entry size 5, assign the prev-version to newly created update objects created from respective tlogs. This prev-version value has signifiicane in distributed updates: {{DistributedUpdateProcessor:: waitForDependentUpdates()}} to make sure the updates are executed in proper chronological order as in-places updates depends on previous full updates. > Fix tlog entry indexes in UpdateLog for CDCR to work smoothly. > -- > > Key: SOLR-12063 > URL: https://issues.apache.org/jira/browse/SOLR-12063 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: CDCR >Affects Versions: 7.2 >Reporter: Amrit Sarkar >Assignee: Varun Thacker >Priority: Major > Attachments: SOLR-12063.patch, SOLR-12063.patch, SOLR-12063.patch, > SOLR-12063.patch, test-report-PeerSyncTest, test-report-TestStressRecovery > > > In *UpdateLog*, {{RecentUpdates}} reads the entry of tlogs, and throughout > the project the entry indexes for various operations are consistent, but odd > in this part. As we included new entry in TransactionLog for CDCR, read > operations in {{update()}} method of {{RecentUpdates}} throw error rightfully > as elements are read from wrong indexes of tlog entry. The entry indexes of > llog should be consistent throughout. > {code} > [beaster] 2> 27394 WARN (qtp97093533-72) [n:127.0.0.1:44658_solr > c:cdcr-cluster1 s:shard1 r:core_node3 x:cdcr-cluster1_shard1_replica_n1] > o.a.s.u.UpdateLog Unexpected log entry or corrupt log. Entry=[2, > -1594312216007409664, [B@28e6859c, true] > [beaster] 2> java.lang.ClassCastException: java.lang.Boolean cannot be > cast to [B > [beaster] 2> at > org.apache.solr.update.UpdateLog$RecentUpdates.update(UpdateLog.java:1443) > [beaster] 2> at > org.apache.solr.update.UpdateLog$RecentUpdates.(UpdateLog.java:1340) > [beaster] 2> at > org.apache.solr.update.UpdateLog.getRecentUpdates(UpdateLog.java:1513) > [beaster] 2> at > org.apache.solr.handler.CdcrRequestHandler.handleShardCheckpointAction(CdcrRequestHandler.java:448) > [beaster] 2> at > org.apache.solr.handler.CdcrRequestHandler.handleRequestBody(CdcrRequestHandler.java:198) > [beaster] 2> at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:195) > [beaster] 2> at > org.apache.solr.core.SolrCore.execute(SolrCore.java:2503) > [beaster] 2> at > org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711) > [beaster] 2> at > org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:517) > [beaster] 2> at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:384) > [beaster] 2> at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:330) > [beaster] 2> at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637) > [beaster] 2> at > org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139) > [beaster] 2> at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637) > [beaster] 2> at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533) > [beaster] 2> at > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188) > [beaster] 2> at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595) > [beaster] 2> at > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188) > [beaster] 2> at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253) > [beaster] 2> at > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168) > [beaster] 2> at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473) > [beaster] 2> at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564) > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-9.0.4) - Build # 21628 - Still unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21628/ Java: 64bit/jdk-9.0.4 -XX:-UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.cloud.SSLMigrationTest.test Error Message: Replica didn't have the proper urlScheme in the ClusterState Stack Trace: java.lang.AssertionError: Replica didn't have the proper urlScheme in the ClusterState at __randomizedtesting.SeedInfo.seed([5152D3D007D29180:D906EC0AA92EFC78]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.cloud.SSLMigrationTest.assertReplicaInformation(SSLMigrationTest.java:103) at org.apache.solr.cloud.SSLMigrationTest.testMigrateSSL(SSLMigrationTest.java:96) at org.apache.solr.cloud.SSLMigrationTest.test(SSLMigrationTest.java:60) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at
[JENKINS] Lucene-Solr-repro - Build # 255 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/255/ [...truncated 28 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/12/consoleText [repro] Revision: 1bd09cf6accf19c7ae1da46ea57e2b8d76c82280 [repro] Repro line: ant test -Dtestcase=TestReplicationHandler -Dtests.method=doTestIndexFetchOnMasterRestart -Dtests.seed=2B57E6E4E7FE472E -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=es-VE -Dtests.timezone=Etc/GMT-0 -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=AutoAddReplicasIntegrationTest -Dtests.method=testSimple -Dtests.seed=2B57E6E4E7FE472E -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ko -Dtests.timezone=AST -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=HdfsAutoAddReplicasIntegrationTest -Dtests.method=testSimple -Dtests.seed=2B57E6E4E7FE472E -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=hi-IN -Dtests.timezone=Pacific/Guam -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=AutoscalingHistoryHandlerTest -Dtests.method=testHistory -Dtests.seed=2B57E6E4E7FE472E -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=da-DK -Dtests.timezone=Australia/Lord_Howe -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=AtomicUpdateProcessorFactoryTest -Dtests.method=testMultipleThreads -Dtests.seed=2B57E6E4E7FE472E -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ro -Dtests.timezone=America/Indiana/Petersburg -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=TestComputePlanAction -Dtests.method=testNodeAdded -Dtests.seed=2B57E6E4E7FE472E -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ar-IQ -Dtests.timezone=Asia/Chita -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=TestComputePlanAction -Dtests.seed=2B57E6E4E7FE472E -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ar-IQ -Dtests.timezone=Asia/Chita -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=TestLTRReRankingPipeline -Dtests.method=testDifferentTopN -Dtests.seed=B79F0610DD5FA417 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=th -Dtests.timezone=Asia/Singapore -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: b82ce515f04eaedf4032c2ee3188620e9644a925 [repro] git fetch [repro] git checkout 1bd09cf6accf19c7ae1da46ea57e2b8d76c82280 [...truncated 2 lines...] [repro] git merge --ff-only [...truncated 1 lines...] [repro] ant clean [...truncated 6 lines...] [repro] Test suites by module: [repro]solr/core [repro] AtomicUpdateProcessorFactoryTest [repro] AutoscalingHistoryHandlerTest [repro] TestComputePlanAction [repro] HdfsAutoAddReplicasIntegrationTest [repro] TestReplicationHandler [repro] AutoAddReplicasIntegrationTest [repro]solr/contrib/ltr [repro] TestLTRReRankingPipeline [repro] ant compile-test [...truncated 3310 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=30 -Dtests.class="*.AtomicUpdateProcessorFactoryTest|*.AutoscalingHistoryHandlerTest|*.TestComputePlanAction|*.HdfsAutoAddReplicasIntegrationTest|*.TestReplicationHandler|*.AutoAddReplicasIntegrationTest" -Dtests.showOutput=onerror -Dtests.seed=2B57E6E4E7FE472E -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ro -Dtests.timezone=America/Indiana/Petersburg -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [...truncated 81892 lines...] [repro] Setting last failure code to 256 [repro] ant compile-test [...truncated 566 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.TestLTRReRankingPipeline" -Dtests.showOutput=onerror -Dtests.seed=B79F0610DD5FA417 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=th -Dtests.timezone=Asia/Singapore -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [...truncated 135 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 0/5 failed: org.apache.solr.cloud.autoscaling.sim.TestComputePlanAction [repro] 3/5 failed: org.apache.solr.update.processor.AtomicUpdateProcessorFactoryTest [repro] 5/5 failed: org.apache.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest [repro] 5/5 failed: org.apache.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest [repro] 5/5 failed: org.apache.solr.handler.TestReplicationHandler [repro] 5/5 failed: org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest [repro] 5/5
[jira] [Commented] (SOLR-11331) Ability to Debug Solr With Eclipse IDE
[ https://issues.apache.org/jira/browse/SOLR-11331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396131#comment-16396131 ] Varun Thacker commented on SOLR-11331: -- Hi Karthik, I reviewed your latest patch which folds in the suggestions. I think something broke because when I try running solr or solr-cloud the UI doesn't load up correctly ( it was working fine in the previous iteration ) so I'm guessing you missed a line somewhere > Ability to Debug Solr With Eclipse IDE > -- > > Key: SOLR-11331 > URL: https://issues.apache.org/jira/browse/SOLR-11331 > Project: Solr > Issue Type: Improvement >Affects Versions: 6.6.2 >Reporter: Karthik Ramachandran >Priority: Minor > Labels: eclipse > Attachments: SOLR-11331.patch, SOLR-11331.patch, UI.png > > > Ability to Debug Solr With Eclipse IDE -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11331) Ability to Debug Solr With Eclipse IDE
[ https://issues.apache.org/jira/browse/SOLR-11331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Thacker updated SOLR-11331: - Attachment: UI.png > Ability to Debug Solr With Eclipse IDE > -- > > Key: SOLR-11331 > URL: https://issues.apache.org/jira/browse/SOLR-11331 > Project: Solr > Issue Type: Improvement >Affects Versions: 6.6.2 >Reporter: Karthik Ramachandran >Priority: Minor > Labels: eclipse > Attachments: SOLR-11331.patch, SOLR-11331.patch, UI.png > > > Ability to Debug Solr With Eclipse IDE -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8202) Add a FixedShingleFilter
[ https://issues.apache.org/jira/browse/LUCENE-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward updated LUCENE-8202: -- Attachment: LUCENE-8202.patch > Add a FixedShingleFilter > > > Key: LUCENE-8202 > URL: https://issues.apache.org/jira/browse/LUCENE-8202 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Attachments: LUCENE-8202.patch > > > In LUCENE-3475 I tried to make a ShingleGraphFilter that could accept and > emit arbitrary graphs, while duplicating all the functionality of the > existing ShingleFilter. This ends up being extremely hairy, and doesn't play > well with query parsers. > I'd like to step back and try and create a simpler shingle filter that can be > used for index-time phrase tokenization only. It will have a single fixed > shingle size, can deal with single-token synonyms, and won't emit unigrams. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8202) Add a FixedShingleFilter
Alan Woodward created LUCENE-8202: - Summary: Add a FixedShingleFilter Key: LUCENE-8202 URL: https://issues.apache.org/jira/browse/LUCENE-8202 Project: Lucene - Core Issue Type: New Feature Reporter: Alan Woodward Assignee: Alan Woodward In LUCENE-3475 I tried to make a ShingleGraphFilter that could accept and emit arbitrary graphs, while duplicating all the functionality of the existing ShingleFilter. This ends up being extremely hairy, and doesn't play well with query parsers. I'd like to step back and try and create a simpler shingle filter that can be used for index-time phrase tokenization only. It will have a single fixed shingle size, can deal with single-token synonyms, and won't emit unigrams. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11501) Depending on the parser, QParser should not parse local-params
[ https://issues.apache.org/jira/browse/SOLR-11501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396097#comment-16396097 ] David Smiley commented on SOLR-11501: - I filed SOLR-12081 for the docs; patch is already there. (Reviews welcome!) > Depending on the parser, QParser should not parse local-params > -- > > Key: SOLR-11501 > URL: https://issues.apache.org/jira/browse/SOLR-11501 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: query parsers >Reporter: David Smiley >Assignee: David Smiley >Priority: Major > Fix For: 7.2 > > Attachments: SOLR_11501_limit_local_params_parsing.patch, > SOLR_11501_limit_local_params_parsing.patch > > > Solr should not parse local-params (and thus be able to switch the query > parser) in certain circumstances. _Perhaps_ it is when the QParser.getParser > is passed "lucene" for the {{defaultParser}}? This particular approach is > just a straw-man; I suspect certain valid embedded queries could no longer > work if this is done incorrectly. Whatever the solution, I don't think we > should assume 'q' is special, as it's valid and useful to build up queries > containing user input in other ways, e.g. {{q= +field:value +\{!dismax > v=$qq\}=user input}} and we want to protect the user input there > similarly from unwelcome query parsing switching. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12081) Improve docs on query parsing: embedded queries, uf (edismax)
[ https://issues.apache.org/jira/browse/SOLR-12081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396096#comment-16396096 ] David Smiley commented on SOLR-12081: - Can someone please review... maybe [~cassandra] since it's the ref guide? I wasn't sure when I needed to escape chars or not; I've observed that the Markdown plugin to IntelliJ doesn't *quite* follow the nitty gritty details consistently. I tried to build the PDF but ran afowl of errors recently reported in SOLR-10297. I tried to do the HTML version by attempting to see if I could use a Docker Jekyll image but ran into errors and I'm not sure what the cause is. I could of course try to install that stuff "normally" but I'm keen on Docker and apparently I want to make my life more difficult than needed today. > Improve docs on query parsing: embedded queries, uf (edismax) > - > > Key: SOLR-12081 > URL: https://issues.apache.org/jira/browse/SOLR-12081 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: David Smiley >Assignee: David Smiley >Priority: Major > Attachments: > SOLR-12081__improve_docs_on_query_parsing,_embedded_queries.patch > > > The {{uf}} parameter is a *space* separated list (not comma). Furthermore the > docs should be improved -- see > https://issues.apache.org/jira/browse/SOLR-11501?focusedCommentId=16326592=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16326592 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12081) Improve docs on query parsing: embedded queries, uf (edismax)
[ https://issues.apache.org/jira/browse/SOLR-12081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated SOLR-12081: Attachment: SOLR-12081__improve_docs_on_query_parsing,_embedded_queries.patch > Improve docs on query parsing: embedded queries, uf (edismax) > - > > Key: SOLR-12081 > URL: https://issues.apache.org/jira/browse/SOLR-12081 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: David Smiley >Assignee: David Smiley >Priority: Major > Attachments: > SOLR-12081__improve_docs_on_query_parsing,_embedded_queries.patch > > > The {{uf}} parameter is a *space* separated list (not comma). Furthermore the > docs should be improved -- see > https://issues.apache.org/jira/browse/SOLR-11501?focusedCommentId=16326592=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16326592 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12082) Improve docs on query parsing: embedded queries, uf (edismax)
David Smiley created SOLR-12082: --- Summary: Improve docs on query parsing: embedded queries, uf (edismax) Key: SOLR-12082 URL: https://issues.apache.org/jira/browse/SOLR-12082 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: documentation Reporter: David Smiley Assignee: David Smiley The {{uf}} parameter is a *space* separated list (not comma). Furthermore the docs should be improved -- see https://issues.apache.org/jira/browse/SOLR-11501?focusedCommentId=16326592=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16326592 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12081) Improve docs on query parsing: embedded queries, uf (edismax)
David Smiley created SOLR-12081: --- Summary: Improve docs on query parsing: embedded queries, uf (edismax) Key: SOLR-12081 URL: https://issues.apache.org/jira/browse/SOLR-12081 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: documentation Reporter: David Smiley Assignee: David Smiley The {{uf}} parameter is a *space* separated list (not comma). Furthermore the docs should be improved -- see https://issues.apache.org/jira/browse/SOLR-11501?focusedCommentId=16326592=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16326592 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 12 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/12/ 6 tests failed. FAILED: org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testEventQueue Error Message: action wasn't interrupted Stack Trace: java.lang.AssertionError: action wasn't interrupted at __randomizedtesting.SeedInfo.seed([7DD583F7A5B89E45:B460C159ACDF58B0]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testEventQueue(TriggerIntegrationTest.java:752) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest.testSimple Error Message: Waiting for collection testSimple1 null Live Nodes: [127.0.0.1:44482_solr, 127.0.0.1:60434_solr] Last available state: DocCollection(testSimple1//collections/testSimple1/state.json/8)={ "pullReplicas":"0",
[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-10-ea+43) - Build # 1520 - Unstable!
Error processing tokens: Error while parsing action 'Text/ZeroOrMore/FirstOf/Token/DelimitedToken/DelimitedToken_Action3' at input position (line 79, pos 4): )"} ^ java.lang.OutOfMemoryError: Java heap space - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8200) Allow doc-values to be updated atomically together with a document
[ https://issues.apache.org/jira/browse/LUCENE-8200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395875#comment-16395875 ] Michael McCandless commented on LUCENE-8200: +1, patch looks great; I left a minor comment on the github commit. Amazing how little code the change requires, and it's a nice approach for soft deletes. > Allow doc-values to be updated atomically together with a document > --- > > Key: LUCENE-8200 > URL: https://issues.apache.org/jira/browse/LUCENE-8200 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 7.4, master (8.0) >Reporter: Simon Willnauer >Assignee: Simon Willnauer >Priority: Major > Attachments: LUCENE-8200.patch > > > Today we can only update a document by deleting all previously indexed > documents for the given term. In some cases like when deletes are not `final` > in the way that documents that are marked as deleted should not be merged > away a `soft-delete` is needed which is possible when doc-values updates can > be done atomically just like delete and add in updateDocument(s) > > This change introduces such a soft update that reuses all code paths from > deletes to update all previously updated documents for a given term instead > of marking it as deleted. This is a spinnoff from LUCENE-8198 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11331) Ability to Debug Solr With Eclipse IDE
[ https://issues.apache.org/jira/browse/SOLR-11331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395869#comment-16395869 ] Varun Thacker commented on SOLR-11331: -- Thanks Karthik for the patch I applied it locally and I see 3 new features added * Run Solr from eclipse * Run Solr from eclipse without console GC logging * Run all Solr tests Let's make the following changes * Ability to run standalone Solr ( "run-solr" ) * Ability to run a 1 node solr cloud server. Both don't need to have GC logging enabled on the console as it's much easier to look at eclipse without it ( "run-solr-cloud" ) * Ability to run all solr tests ( "run-solr-tests" ) * Ability to run all lucene tests ( "run-lucene-test" ) You only need to run 'ant eclipse' once and these configurations get added. It's pretty cool. We don't have these features in IntelliJ currently but that can be added as a separate Jira > Ability to Debug Solr With Eclipse IDE > -- > > Key: SOLR-11331 > URL: https://issues.apache.org/jira/browse/SOLR-11331 > Project: Solr > Issue Type: Improvement >Affects Versions: 6.6.2 >Reporter: Karthik Ramachandran >Priority: Minor > Labels: eclipse > Attachments: SOLR-11331.patch, SOLR-11331.patch > > > Ability to Debug Solr With Eclipse IDE -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-8201) TestCodecLoadingDeadlock.testDeadlock failure has no "reproduce with" line
[ https://issues.apache.org/jira/browse/LUCENE-8201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Rowe resolved LUCENE-8201. Resolution: Not A Problem Assignee: Steve Rowe Thanks for the explanation Dawid, resolving as Not A Problem. > TestCodecLoadingDeadlock.testDeadlock failure has no "reproduce with" line > -- > > Key: LUCENE-8201 > URL: https://issues.apache.org/jira/browse/LUCENE-8201 > Project: Lucene - Core > Issue Type: Test >Reporter: Steve Rowe >Assignee: Steve Rowe >Priority: Major > > Is it expected that there are test situations where a "reproduce with" line > is not printed? ({{reproduceJenkinsFailures.py}} assumes that all failures > produce such a line.) > Here's one from > [https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/172/]: > {noformat} >[smoker][junit4] Suite: > org.apache.lucene.codecs.TestCodecLoadingDeadlock >[smoker][junit4] FAILURE 30.4s J0 | > TestCodecLoadingDeadlock.testDeadlock <<< >[smoker][junit4]> Throwable #1: java.lang.AssertionError: Process > did not exit after 30 secs -> classloader deadlock? >[smoker][junit4]> at > __randomizedtesting.SeedInfo.seed([88B4FC32922379:DE355E834C88EAF]:0) >[smoker][junit4]> at > org.apache.lucene.codecs.TestCodecLoadingDeadlock.testDeadlock(TestCodecLoadingDeadlock.java:75) >[smoker][junit4] Completed [132/466 (1!)] on J0 in 30.45s, 1 test, 1 > failure <<< FAILURES! > {noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8201) TestCodecLoadingDeadlock.testDeadlock failure has no "reproduce with" line
[ https://issues.apache.org/jira/browse/LUCENE-8201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395835#comment-16395835 ] Dawid Weiss commented on LUCENE-8201: - This "reproduce with" line is printed with a test event listener, it's not really part of randomized testing. This particular test has this in its header: {code} /* WARNING: This test does *not* extend LuceneTestCase to prevent static class * initialization when spawned as subprocess (and please let default codecs alive)! */ @RunWith(RandomizedRunner.class) public class TestCodecLoadingDeadlock extends Assert { {code} Note it extends randomized runner, but does not extend the base test class from Lucene (for a reason); that's why you can't see the "repro" line. The seed is printed as part of the stack trace (and this is part of the randomizedtesting framework), so if you use it, the failure should be reproducible. {code} ant -Dtests.seed=88B4FC32922379 {code} > TestCodecLoadingDeadlock.testDeadlock failure has no "reproduce with" line > -- > > Key: LUCENE-8201 > URL: https://issues.apache.org/jira/browse/LUCENE-8201 > Project: Lucene - Core > Issue Type: Test >Reporter: Steve Rowe >Priority: Major > > Is it expected that there are test situations where a "reproduce with" line > is not printed? ({{reproduceJenkinsFailures.py}} assumes that all failures > produce such a line.) > Here's one from > [https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/172/]: > {noformat} >[smoker][junit4] Suite: > org.apache.lucene.codecs.TestCodecLoadingDeadlock >[smoker][junit4] FAILURE 30.4s J0 | > TestCodecLoadingDeadlock.testDeadlock <<< >[smoker][junit4]> Throwable #1: java.lang.AssertionError: Process > did not exit after 30 secs -> classloader deadlock? >[smoker][junit4]> at > __randomizedtesting.SeedInfo.seed([88B4FC32922379:DE355E834C88EAF]:0) >[smoker][junit4]> at > org.apache.lucene.codecs.TestCodecLoadingDeadlock.testDeadlock(TestCodecLoadingDeadlock.java:75) >[smoker][junit4] Completed [132/466 (1!)] on J0 in 30.45s, 1 test, 1 > failure <<< FAILURES! > {noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1727 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1727/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.autoscaling.ScheduledMaintenanceTriggerTest.testInactiveShardCleanup Error Message: cleanup action didn't run Stack Trace: java.lang.AssertionError: cleanup action didn't run at __randomizedtesting.SeedInfo.seed([FE245CB5777C120B:E3089CC7163F3500]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.cloud.autoscaling.ScheduledMaintenanceTriggerTest.testInactiveShardCleanup(ScheduledMaintenanceTriggerTest.java:197) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Build Log: [...truncated 14050 lines...] [junit4] Suite: org.apache.solr.cloud.autoscaling.ScheduledMaintenanceTriggerTest [junit4] 2> Creating dataDir:
[jira] [Created] (LUCENE-8201) TestCodecLoadingDeadlock.testDeadlock failure has no "reproduce with" line
Steve Rowe created LUCENE-8201: -- Summary: TestCodecLoadingDeadlock.testDeadlock failure has no "reproduce with" line Key: LUCENE-8201 URL: https://issues.apache.org/jira/browse/LUCENE-8201 Project: Lucene - Core Issue Type: Test Reporter: Steve Rowe Is it expected that there are test situations where a "reproduce with" line is not printed? ({{reproduceJenkinsFailures.py}} assumes that all failures produce such a line.) Here's one from [https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/172/]: {noformat} [smoker][junit4] Suite: org.apache.lucene.codecs.TestCodecLoadingDeadlock [smoker][junit4] FAILURE 30.4s J0 | TestCodecLoadingDeadlock.testDeadlock <<< [smoker][junit4]> Throwable #1: java.lang.AssertionError: Process did not exit after 30 secs -> classloader deadlock? [smoker][junit4]>at __randomizedtesting.SeedInfo.seed([88B4FC32922379:DE355E834C88EAF]:0) [smoker][junit4]>at org.apache.lucene.codecs.TestCodecLoadingDeadlock.testDeadlock(TestCodecLoadingDeadlock.java:75) [smoker][junit4] Completed [132/466 (1!)] on J0 in 30.45s, 1 test, 1 failure <<< FAILURES! {noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-master - Build # 2420 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2420/ 4 tests failed. FAILED: org.apache.solr.cloud.CollectionsAPISolrJTest.testSplitShard Error Message: Error from server at https://127.0.0.1:45141/solr: KeeperErrorCode = NoNode for /overseer/collection-queue-work/qnr-38 Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at https://127.0.0.1:45141/solr: KeeperErrorCode = NoNode for /overseer/collection-queue-work/qnr-38 at __randomizedtesting.SeedInfo.seed([8767B62FF5934BF1:5C6D1B43EB66774E]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1105) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:885) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:818) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.cloud.CollectionsAPISolrJTest.testSplitShard(CollectionsAPISolrJTest.java:215) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_162) - Build # 21627 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21627/ Java: 64bit/jdk1.8.0_162 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.cloud.autoscaling.ScheduledMaintenanceTriggerTest.testInactiveShardCleanup Error Message: should be at least one inactive event Stack Trace: java.lang.AssertionError: should be at least one inactive event at __randomizedtesting.SeedInfo.seed([25C2A8FF59E8133E:38EE688D38AB3435]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.cloud.autoscaling.ScheduledMaintenanceTriggerTest.testInactiveShardCleanup(ScheduledMaintenanceTriggerTest.java:218) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Build Log: [...truncated 12936 lines...] [junit4] Suite: org.apache.solr.cloud.autoscaling.ScheduledMaintenanceTriggerTest [junit4] 2> Creating dataDir:
[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 977 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/977/ No tests ran. Build Log: [...truncated 30082 lines...] prepare-release-no-sign: [mkdir] Created dir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist [copy] Copying 491 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene [copy] Copying 230 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8 [smoker] Java 9 JAVA_HOME=/home/jenkins/tools/java/latest1.9 [smoker] NOTE: output encoding is UTF-8 [smoker] [smoker] Load release URL "file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"... [smoker] [smoker] Test Lucene... [smoker] test basics... [smoker] get KEYS [smoker] 0.2 MB in 0.01 sec (16.8 MB/sec) [smoker] check changes HTML... [smoker] download lucene-8.0.0-src.tgz... [smoker] 30.3 MB in 0.03 sec (886.9 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-8.0.0.tgz... [smoker] 73.3 MB in 0.09 sec (862.6 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-8.0.0.zip... [smoker] 83.8 MB in 0.10 sec (856.1 MB/sec) [smoker] verify md5/sha1 digests [smoker] unpack lucene-8.0.0.tgz... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.8... [smoker] got 6253 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] test demo with 9... [smoker] got 6253 hits for query "lucene" [smoker] checkindex with 9... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-8.0.0.zip... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.8... [smoker] got 6253 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] test demo with 9... [smoker] got 6253 hits for query "lucene" [smoker] checkindex with 9... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-8.0.0-src.tgz... [smoker] make sure no JARs/WARs in src dist... [smoker] run "ant validate" [smoker] run tests w/ Java 8 and testArgs='-Dtests.badapples=false -Dtests.slow=false'... [smoker] test demo with 1.8... [smoker] got 212 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] generate javadocs w/ Java 8... [smoker] [smoker] Crawl/parse... [smoker] [smoker] Verify... [smoker] run tests w/ Java 9 and testArgs='-Dtests.badapples=false -Dtests.slow=false'... [smoker] test demo with 9... [smoker] got 212 hits for query "lucene" [smoker] checkindex with 9... [smoker] confirm all releases have coverage in TestBackwardsCompatibility [smoker] find all past Lucene releases... [smoker] run TestBackwardsCompatibility.. [smoker] success! [smoker] [smoker] Test Solr... [smoker] test basics... [smoker] get KEYS [smoker] 0.2 MB in 0.00 sec (237.2 MB/sec) [smoker] check changes HTML... [smoker] download solr-8.0.0-src.tgz... [smoker] 53.4 MB in 0.06 sec (821.8 MB/sec) [smoker] verify md5/sha1 digests [smoker] download solr-8.0.0.tgz... [smoker] 154.6 MB in 0.62 sec (249.0 MB/sec) [smoker] verify md5/sha1 digests [smoker] download solr-8.0.0.zip... [smoker] 155.6 MB in 1.72 sec (90.7 MB/sec) [smoker] verify md5/sha1 digests [smoker] unpack solr-8.0.0.tgz... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] unpack lucene-8.0.0.tgz... [smoker] **WARNING**: skipping check of /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar: it has javax.* classes [smoker] **WARNING**: skipping check of /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar: it has javax.* classes [smoker] copying unpacked distribution for Java 8 ... [smoker] test solr example w/ Java 8... [smoker] start Solr instance (log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0-java8/solr-example.log)... [smoker] No process found for Solr node running on port 8983 [smoker] Running techproducts example on port 8983 from
[jira] [Commented] (SOLR-11267) Add support for "add-distinct" atomic update operation
[ https://issues.apache.org/jira/browse/SOLR-11267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395738#comment-16395738 ] David Smiley commented on SOLR-11267: - [~noble.paul] did you forget to port to 7.x? Now we have a 7.3 branch too. > Add support for "add-distinct" atomic update operation > -- > > Key: SOLR-11267 > URL: https://issues.apache.org/jira/browse/SOLR-11267 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Major > Attachments: SOLR-11267.patch, SOLR-11267.patch, SOLR-11267.patch > > > Often, a multivalued field is used as a set of values. Since multivalued > fields are more like lists than sets, users do two consecutive operations, > remove and add, to insert an element into the field and also maintain the > set's property of only having unique elements. > Proposing a new single operation, called "add-distinct" (which essentially > means "add-if-doesn't exist") for this. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12063) Fix tlog entry indexes in UpdateLog for CDCR to work smoothly.
[ https://issues.apache.org/jira/browse/SOLR-12063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395728#comment-16395728 ] Varun Thacker commented on SOLR-12063: -- Hi Amrit, I'm trying to understand your latest patch. Here's a change you made to the UpdateLog Old: {code:java} if (oper == UpdateLog.UPDATE_INPLACE && entry.size() == 5) { update.previousVersion = (Long) entry.get(UpdateLog.PREV_VERSION_IDX); }{code} New: {code:java} if (oper == UpdateLog.UPDATE_INPLACE) { if ((update.log instanceof CdcrTransactionLog && entry.size() == 6) || (!(update.log instanceof CdcrTransactionLog) && entry.size() == 5)) { update.previousVersion = (Long) entry.get(UpdateLog.PREV_VERSION_IDX); } }{code} What's the difference in behaviour here? Will we simply drop in-place updates if the inner if clause if not satisfied with the new patch? > Fix tlog entry indexes in UpdateLog for CDCR to work smoothly. > -- > > Key: SOLR-12063 > URL: https://issues.apache.org/jira/browse/SOLR-12063 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: CDCR >Affects Versions: 7.2 >Reporter: Amrit Sarkar >Assignee: Varun Thacker >Priority: Major > Attachments: SOLR-12063.patch, SOLR-12063.patch, SOLR-12063.patch, > SOLR-12063.patch, test-report-PeerSyncTest, test-report-TestStressRecovery > > > In *UpdateLog*, {{RecentUpdates}} reads the entry of tlogs, and throughout > the project the entry indexes for various operations are consistent, but odd > in this part. As we included new entry in TransactionLog for CDCR, read > operations in {{update()}} method of {{RecentUpdates}} throw error rightfully > as elements are read from wrong indexes of tlog entry. The entry indexes of > llog should be consistent throughout. > {code} > [beaster] 2> 27394 WARN (qtp97093533-72) [n:127.0.0.1:44658_solr > c:cdcr-cluster1 s:shard1 r:core_node3 x:cdcr-cluster1_shard1_replica_n1] > o.a.s.u.UpdateLog Unexpected log entry or corrupt log. Entry=[2, > -1594312216007409664, [B@28e6859c, true] > [beaster] 2> java.lang.ClassCastException: java.lang.Boolean cannot be > cast to [B > [beaster] 2> at > org.apache.solr.update.UpdateLog$RecentUpdates.update(UpdateLog.java:1443) > [beaster] 2> at > org.apache.solr.update.UpdateLog$RecentUpdates.(UpdateLog.java:1340) > [beaster] 2> at > org.apache.solr.update.UpdateLog.getRecentUpdates(UpdateLog.java:1513) > [beaster] 2> at > org.apache.solr.handler.CdcrRequestHandler.handleShardCheckpointAction(CdcrRequestHandler.java:448) > [beaster] 2> at > org.apache.solr.handler.CdcrRequestHandler.handleRequestBody(CdcrRequestHandler.java:198) > [beaster] 2> at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:195) > [beaster] 2> at > org.apache.solr.core.SolrCore.execute(SolrCore.java:2503) > [beaster] 2> at > org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711) > [beaster] 2> at > org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:517) > [beaster] 2> at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:384) > [beaster] 2> at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:330) > [beaster] 2> at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637) > [beaster] 2> at > org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139) > [beaster] 2> at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637) > [beaster] 2> at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533) > [beaster] 2> at > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188) > [beaster] 2> at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595) > [beaster] 2> at > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188) > [beaster] 2> at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253) > [beaster] 2> at > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168) > [beaster] 2> at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473) > [beaster] 2> at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564) > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail:
[GitHub] lucene-solr pull request #323: SOLR-11731: LatLonPointSpatialField could be ...
Github user mrkarthik commented on a diff in the pull request: https://github.com/apache/lucene-solr/pull/323#discussion_r173911215 --- Diff: solr/core/src/java/org/apache/solr/search/SolrDocumentFetcher.java --- @@ -486,16 +486,14 @@ private Object decodeDVField(int localId, LeafReader leafReader, String fieldNam case SORTED_NUMERIC: final SortedNumericDocValues numericDv = leafReader.getSortedNumericDocValues(fieldName); if (numericDv != null && numericDv.advance(localId) == localId) { - if (schemaField.getType() instanceof LatLonPointSpatialField) { -long number = numericDv.nextValue(); -return ((LatLonPointSpatialField) schemaField.getType()).geoValueToStringValue(number); - } final List outValues = new ArrayList<>(numericDv.docValueCount()); for (int i = 0; i < numericDv.docValueCount(); i++) { long number = numericDv.nextValue(); Object value = decodeNumberFromDV(schemaField, number, true); // return immediately if the number is not decodable, hence won't return an empty list. if (value == null) return null; +// return the value as "lat, lon" if its not multi-valued --- End diff -- Yes, I have test case of both store and docValue --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #323: SOLR-11731: LatLonPointSpatialField could be ...
Github user mrkarthik commented on a diff in the pull request: https://github.com/apache/lucene-solr/pull/323#discussion_r173911226 --- Diff: solr/core/src/java/org/apache/solr/schema/LatLonPointSpatialField.java --- @@ -75,8 +77,16 @@ protected SpatialStrategy newSpatialStrategy(String fieldName) { return new LatLonPointSpatialStrategy(ctx, fieldName, schemaField.indexed(), schemaField.hasDocValues()); } - public String geoValueToStringValue(long value) { -return new String(decodeLatitudeCeil(value) + "," + decodeLongitudeCeil(value)); + /** + * Converts to "lat, lon" + * @param value Non-null; stored location field data + * @return Non-null; "lat, lon" with 6 decimal point precision --- End diff -- Based on the article it would be close 111mm https://gis.stackexchange.com/a/8674 https://en.wikipedia.org/wiki/Decimal_degrees --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8200) Allow doc-values to be updated atomically together with a document
[ https://issues.apache.org/jira/browse/LUCENE-8200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395723#comment-16395723 ] Robert Muir commented on LUCENE-8200: - the public IW api looks good and simple. There's a missing space in the javadocs "flush may happen only afterthe add" I didn't review any of the impl details or tests. > Allow doc-values to be updated atomically together with a document > --- > > Key: LUCENE-8200 > URL: https://issues.apache.org/jira/browse/LUCENE-8200 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 7.4, master (8.0) >Reporter: Simon Willnauer >Assignee: Simon Willnauer >Priority: Major > Attachments: LUCENE-8200.patch > > > Today we can only update a document by deleting all previously indexed > documents for the given term. In some cases like when deletes are not `final` > in the way that documents that are marked as deleted should not be merged > away a `soft-delete` is needed which is possible when doc-values updates can > be done atomically just like delete and add in updateDocument(s) > > This change introduces such a soft update that reuses all code paths from > deletes to update all previously updated documents for a given term instead > of marking it as deleted. This is a spinnoff from LUCENE-8198 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #323: SOLR-11731: LatLonPointSpatialField could be ...
Github user dsmiley commented on a diff in the pull request: https://github.com/apache/lucene-solr/pull/323#discussion_r173906040 --- Diff: solr/core/src/java/org/apache/solr/search/SolrDocumentFetcher.java --- @@ -486,16 +486,14 @@ private Object decodeDVField(int localId, LeafReader leafReader, String fieldNam case SORTED_NUMERIC: final SortedNumericDocValues numericDv = leafReader.getSortedNumericDocValues(fieldName); if (numericDv != null && numericDv.advance(localId) == localId) { - if (schemaField.getType() instanceof LatLonPointSpatialField) { -long number = numericDv.nextValue(); -return ((LatLonPointSpatialField) schemaField.getType()).geoValueToStringValue(number); - } final List outValues = new ArrayList<>(numericDv.docValueCount()); for (int i = 0; i < numericDv.docValueCount(); i++) { long number = numericDv.nextValue(); Object value = decodeNumberFromDV(schemaField, number, true); // return immediately if the number is not decodable, hence won't return an empty list. if (value == null) return null; +// return the value as "lat, lon" if its not multi-valued --- End diff -- I understand that internally the type is SORTED_NUMERIC either way. But externally (from user's point of view) the visible behavior should be consistent with what would happen if the field were stored. Please ensure this distinction is tested too (if it isn't already) --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12076) Remove more usages of printLayout in CDCR tests
[ https://issues.apache.org/jira/browse/SOLR-12076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395644#comment-16395644 ] Varun Thacker commented on SOLR-12076: -- Until INFRA-15850 is resolved the user tagged with the commit will not be me > Remove more usages of printLayout in CDCR tests > --- > > Key: SOLR-12076 > URL: https://issues.apache.org/jira/browse/SOLR-12076 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Varun Thacker >Assignee: Varun Thacker >Priority: Minor > Attachments: SOLR-12076.patch > > > All the CDCR tests simply print everything stored in ZooKeeper when we start > the servers. > It adds no value in my option and simply generates noise. > In general we should remove printLayoutToStdOut which prints everything and > pass a parameter to print only a particular set of znodes which they care > about. For example if the leader election tests fail print everything related > to that collection and not print everything including the configs. > It's also a public API so I don't want to tackle this in the interest of > time. I plan on specifically tackling the usage in CDCR tests and removing > them. SOLR-6090 is also related for reference. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12076) Remove more usages of printLayout in CDCR tests
[ https://issues.apache.org/jira/browse/SOLR-12076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395628#comment-16395628 ] ASF subversion and git services commented on SOLR-12076: Commit 6b8a20264b83f997bb6e936bce20c8a20c38c004 in lucene-solr's branch refs/heads/branch_7x from [~varun_saxena] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6b8a202 ] SOLR-12076: Remove unnecessary printLayout usage in CDCR tests (cherry picked from commit 2a0b776) > Remove more usages of printLayout in CDCR tests > --- > > Key: SOLR-12076 > URL: https://issues.apache.org/jira/browse/SOLR-12076 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Varun Thacker >Assignee: Varun Thacker >Priority: Minor > Attachments: SOLR-12076.patch > > > All the CDCR tests simply print everything stored in ZooKeeper when we start > the servers. > It adds no value in my option and simply generates noise. > In general we should remove printLayoutToStdOut which prints everything and > pass a parameter to print only a particular set of znodes which they care > about. For example if the leader election tests fail print everything related > to that collection and not print everything including the configs. > It's also a public API so I don't want to tackle this in the interest of > time. I plan on specifically tackling the usage in CDCR tests and removing > them. SOLR-6090 is also related for reference. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12076) Remove more usages of printLayout in CDCR tests
[ https://issues.apache.org/jira/browse/SOLR-12076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395617#comment-16395617 ] ASF subversion and git services commented on SOLR-12076: Commit 2a0b7767abcfc1e6a78abb784120d913489da7b8 in lucene-solr's branch refs/heads/master from [~varun_saxena] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2a0b776 ] SOLR-12076: Remove unnecessary printLayout usage in CDCR tests > Remove more usages of printLayout in CDCR tests > --- > > Key: SOLR-12076 > URL: https://issues.apache.org/jira/browse/SOLR-12076 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Varun Thacker >Assignee: Varun Thacker >Priority: Minor > Attachments: SOLR-12076.patch > > > All the CDCR tests simply print everything stored in ZooKeeper when we start > the servers. > It adds no value in my option and simply generates noise. > In general we should remove printLayoutToStdOut which prints everything and > pass a parameter to print only a particular set of znodes which they care > about. For example if the leader election tests fail print everything related > to that collection and not print everything including the configs. > It's also a public API so I don't want to tackle this in the interest of > time. I plan on specifically tackling the usage in CDCR tests and removing > them. SOLR-6090 is also related for reference. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11947) 7.3 Streaming Expression Documentation
[ https://issues.apache.org/jira/browse/SOLR-11947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395616#comment-16395616 ] Joel Bernstein commented on SOLR-11947: --- Ok, I have cleaned up branch_7x and branch_7_3 so there are no placeholders for unfinished documentation. I think this should be fine to release now, it just isn't complete. About half of the new functions added in 7.3 have been added to the reference page. After I finish the math expression userguides, I'll add the rest of the function references. > 7.3 Streaming Expression Documentation > -- > > Key: SOLR-11947 > URL: https://issues.apache.org/jira/browse/SOLR-11947 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation, streaming expressions >Reporter: Joel Bernstein >Priority: Major > Attachments: SOLR-11947.patch, SOLR-11947.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11947) 7.3 Streaming Expression Documentation
[ https://issues.apache.org/jira/browse/SOLR-11947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395603#comment-16395603 ] ASF subversion and git services commented on SOLR-11947: Commit df10445cc6625237b598a2f4ea7d94bf2ddaf98c in lucene-solr's branch refs/heads/branch_7_3 from [~joel.bernstein] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=df10445 ] SOLR-11947: Remove place holder for lerp > 7.3 Streaming Expression Documentation > -- > > Key: SOLR-11947 > URL: https://issues.apache.org/jira/browse/SOLR-11947 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation, streaming expressions >Reporter: Joel Bernstein >Priority: Major > Attachments: SOLR-11947.patch, SOLR-11947.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11947) 7.3 Streaming Expression Documentation
[ https://issues.apache.org/jira/browse/SOLR-11947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395604#comment-16395604 ] ASF subversion and git services commented on SOLR-11947: Commit 7046b9891a34850ba3b619969759104c2514ef5e in lucene-solr's branch refs/heads/branch_7_3 from [~joel.bernstein] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7046b98 ] SOLR-11947: Remove place holders for documentation that will not be complete for 7.3. > 7.3 Streaming Expression Documentation > -- > > Key: SOLR-11947 > URL: https://issues.apache.org/jira/browse/SOLR-11947 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation, streaming expressions >Reporter: Joel Bernstein >Priority: Major > Attachments: SOLR-11947.patch, SOLR-11947.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11407) AutoscalingHistoryHandlerTest fails frequently
[ https://issues.apache.org/jira/browse/SOLR-11407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395593#comment-16395593 ] ASF subversion and git services commented on SOLR-11407: Commit 78d592d2fdfc64c227fc1bcb8fafa3d806fbb384 in lucene-solr's branch refs/heads/branch_7x from [~ab] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=78d592d ] SOLR-11407: Add more logging to this test to discover the reason for failures. > AutoscalingHistoryHandlerTest fails frequently > -- > > Key: SOLR-11407 > URL: https://issues.apache.org/jira/browse/SOLR-11407 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: AutoScaling >Reporter: Andrzej Bialecki >Assignee: Andrzej Bialecki >Priority: Major > Fix For: master (8.0) > > > This test fails frequently on jenkins with a failed assertion (see also > SOLR-11378 for other failure mode): > {code} >[junit4] FAILURE 6.49s J2 | AutoscalingHistoryHandlerTest.testHistory <<< >[junit4]> Throwable #1: java.lang.AssertionError: expected:<8> but > was:<6> >[junit4]> at > __randomizedtesting.SeedInfo.seed([164F10BB7F145FDE:7BB3B446C55CA0D9]:0) >[junit4]> at > org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.testHistory(AutoscalingHistoryHandlerTest.java:194) >[junit4]> at java.lang.Thread.run(Thread.java:748) > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11947) 7.3 Streaming Expression Documentation
[ https://issues.apache.org/jira/browse/SOLR-11947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395590#comment-16395590 ] ASF subversion and git services commented on SOLR-11947: Commit 00a2f3f385cdd16528bec67c3be6d2879a5eb4e0 in lucene-solr's branch refs/heads/branch_7x from [~joel.bernstein] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=00a2f3f ] SOLR-11947: Remove place holder for lerp > 7.3 Streaming Expression Documentation > -- > > Key: SOLR-11947 > URL: https://issues.apache.org/jira/browse/SOLR-11947 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation, streaming expressions >Reporter: Joel Bernstein >Priority: Major > Attachments: SOLR-11947.patch, SOLR-11947.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11947) 7.3 Streaming Expression Documentation
[ https://issues.apache.org/jira/browse/SOLR-11947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395584#comment-16395584 ] ASF subversion and git services commented on SOLR-11947: Commit 7c0a00d1caf39ebb914fc515c2174bd39a2a2c0b in lucene-solr's branch refs/heads/branch_7x from [~joel.bernstein] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7c0a00d ] SOLR-11947: Remove place holders for documentation that will not be complete for 7.3. > 7.3 Streaming Expression Documentation > -- > > Key: SOLR-11947 > URL: https://issues.apache.org/jira/browse/SOLR-11947 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation, streaming expressions >Reporter: Joel Bernstein >Priority: Major > Attachments: SOLR-11947.patch, SOLR-11947.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-12076) Remove more usages of printLayout in CDCR tests
[ https://issues.apache.org/jira/browse/SOLR-12076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Thacker reassigned SOLR-12076: Assignee: Varun Thacker > Remove more usages of printLayout in CDCR tests > --- > > Key: SOLR-12076 > URL: https://issues.apache.org/jira/browse/SOLR-12076 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Varun Thacker >Assignee: Varun Thacker >Priority: Minor > Attachments: SOLR-12076.patch > > > All the CDCR tests simply print everything stored in ZooKeeper when we start > the servers. > It adds no value in my option and simply generates noise. > In general we should remove printLayoutToStdOut which prints everything and > pass a parameter to print only a particular set of znodes which they care > about. For example if the leader election tests fail print everything related > to that collection and not print everything including the configs. > It's also a public API so I don't want to tackle this in the interest of > time. I plan on specifically tackling the usage in CDCR tests and removing > them. SOLR-6090 is also related for reference. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-BadApples-Tests-7.x - Build # 12 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/12/ 8 tests failed. FAILED: org.apache.solr.cloud.autoscaling.sim.TestComputePlanAction.testNodeAdded Error Message: Test abandoned because suite timeout was reached. Stack Trace: java.lang.Exception: Test abandoned because suite timeout was reached. at __randomizedtesting.SeedInfo.seed([2B57E6E4E7FE472E]:0) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.autoscaling.sim.TestComputePlanAction Error Message: Suite timeout exceeded (>= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (>= 720 msec). at __randomizedtesting.SeedInfo.seed([2B57E6E4E7FE472E]:0) FAILED: org.apache.solr.update.processor.AtomicUpdateProcessorFactoryTest.testMultipleThreads Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([2B57E6E4E7FE472E:76591696B3A31AA]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:908) at org.apache.solr.update.processor.AtomicUpdateProcessorFactoryTest.testMultipleThreads(AtomicUpdateProcessorFactoryTest.java:260) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at
[jira] [Commented] (SOLR-11947) 7.3 Streaming Expression Documentation
[ https://issues.apache.org/jira/browse/SOLR-11947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1639#comment-1639 ] Joel Bernstein commented on SOLR-11947: --- I think the best thing todo is for me to simply clean up the unfinished TODO's directly in branch_7x. Then push the change to the branch so the release can get started. In the 7.4 release we'll have more time to integrate the math expressions user-guide and decide on how we want to handle the massive evaluators reference page, which I think needs to be broken into smaller pages or be redesigned. > 7.3 Streaming Expression Documentation > -- > > Key: SOLR-11947 > URL: https://issues.apache.org/jira/browse/SOLR-11947 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation, streaming expressions >Reporter: Joel Bernstein >Priority: Major > Attachments: SOLR-11947.patch, SOLR-11947.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_162) - Build # 21626 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21626/ Java: 64bit/jdk1.8.0_162 -XX:-UseCompressedOops -XX:+UseParallelGC 3 tests failed. FAILED: org.apache.solr.cloud.autoscaling.ScheduledMaintenanceTriggerTest.testInactiveShardCleanup Error Message: should be at least one inactive event Stack Trace: java.lang.AssertionError: should be at least one inactive event at __randomizedtesting.SeedInfo.seed([63A857963F1079CE:7E8497E45E535EC5]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.cloud.autoscaling.ScheduledMaintenanceTriggerTest.testInactiveShardCleanup(ScheduledMaintenanceTriggerTest.java:218) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.cloud.autoscaling.ScheduledMaintenanceTriggerTest.testInactiveShardCleanup Error Message: should be at least one inactive event Stack Trace: java.lang.AssertionError:
[jira] [Commented] (SOLR-11865) Refactor QueryElevationComponent to prepare query subset matching
[ https://issues.apache.org/jira/browse/SOLR-11865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395493#comment-16395493 ] David Smiley commented on SOLR-11865: - BTW one thing that I'm not sure about is if it might make sense to move the subsetMatch flag from the ElevatingQuery to Elevation; and then we don't need an ElevatingQuery (just use the query String as before). But I'm not sure. The current design allows to elevate a query with and without subsetMatch with separate rules... I think? If that's pertinent then nevermind. > Refactor QueryElevationComponent to prepare query subset matching > - > > Key: SOLR-11865 > URL: https://issues.apache.org/jira/browse/SOLR-11865 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SearchComponents - other >Affects Versions: master (8.0) >Reporter: Bruno Roustant >Priority: Minor > Labels: QueryComponent > Fix For: master (8.0) > > Attachments: > 0001-Refactor-QueryElevationComponent-to-introduce-Elevat.patch, > SOLR-11865.patch > > > The goal is to prepare a second improvement to support query terms subset > matching or query elevation rules. > Before that, we need to refactor the QueryElevationComponent. We make it > extendible. We introduce the ElevationProvider interface which will be > implemented later in a second patch to support subset matching. The current > full-query match policy becomes a default simple MapElevationProvider. > - Add overridable methods to handle exceptions during the component > initialization. > - Add overridable methods to provide the default values for config properties. > - No functional change beyond refactoring. > - Adapt unit test. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12059) Unable to rename solr.xml
[ https://issues.apache.org/jira/browse/SOLR-12059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395490#comment-16395490 ] Erick Erickson commented on SOLR-12059: --- close as "won't fix"? > Unable to rename solr.xml > - > > Key: SOLR-12059 > URL: https://issues.apache.org/jira/browse/SOLR-12059 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.5.1 > Environment: Renaming of solr,xml in the $SOLR_HOME directory >Reporter: Edwin Yeo Zheng Lin >Priority: Major > > I am able to rename the flie names like solrconfig.xml and solr.log to custom > names like myconfig.xml and my.log quite seamlessly. > However, I am not able to rename the same for solr.xml. Understand that the > solr.xml is hard-coded at the SolrXmlConfig.java. Meaning it requires a > re-compile of the Jar file in order to rename it. > Since we can rename files like solrconfig.xml from the properties files, so > we should do the same for solr.xml? > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11865) Refactor QueryElevationComponent to prepare query subset matching
[ https://issues.apache.org/jira/browse/SOLR-11865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395483#comment-16395483 ] David Smiley commented on SOLR-11865: - Thanks Bruno. It seems there is _some_ new/changed behavior (and that's fine): * can define the same query more than once and it'll get merged; no longer an exception * new {{keepElevationPriority}} parameter Comments: * I'm a little skeptical about the need for InitializationExceptionHandler, LoadingExceptionHandler, and related complexities. Maybe you can provide some insight as to why this is needed? * IMO it's unfortunate that ElevationProvider is mutable and has the makeImmutable method. How about createElevationProvider accept the elevationBuilderMap? And does ElevationProvider.size need to be there either? And does getElevationForQuery need to throw an IOException? With such simplifications, we could then simply use JDK Function. Not that using the JDK one is a big deal (and it's debatable too) but my point is more about simplifying. * the indentation around line ~671 (contents of the for loop) is messed up; it made me misinterpret the intent of the the logic * My preference is to not have javadoc comments like "Can be overridden by extending this class." because "protected" access implies this, thus it's redundant. * suggest change comparator docVal (~line 1318) to use getOrDefault * suggest to use {{localBoosts.addAll(boosted.keySet());}} at line ~661 instead of manual looping (IntelliJ helpfully pointed this out) * in parseExcludedMarkerFieldName and parseEditorialMarkerFieldName I see initArgs.get being called with a default value, yet it's followed up with a check for null to then use the default value. This seems quite redundant since the two-arg SolrParams.get already does that. I don't like the empty string check (this is for a config file, not a request parameter where a better argument could be made for it) -- I'd much prefer something tighter/simpler. It appears SOLR-2037 introduced this but it was a minor detail that wasn't discussed in the comments. Removing this would technically be a back-compat break but it's minor enough and so easy for someone to fix that I think it's fine. * Instead of IndexedValueProvider, which we don't even expose, lets just use a UnaryOperator? and then use a Java 8 method reference when needed instead of declaring QueryElevationComponent.indexedValueProvider ? * Maybe make the constructor of ElevatingQuery protected so it could be subclassed. Likewise for Elevation. BTW this code pattern {{seen.contains(id) == false}} is often written as-such deliberately instead of {{!seen.contains(id)}} because it reads clearer (and takes no additional lines of code). Bugs have been missed then found because of that style. There is no code standard for it in Lucene or Solr but I recommend against modifying existing lines that made one choice or the other as part this cleanup. > Refactor QueryElevationComponent to prepare query subset matching > - > > Key: SOLR-11865 > URL: https://issues.apache.org/jira/browse/SOLR-11865 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SearchComponents - other >Affects Versions: master (8.0) >Reporter: Bruno Roustant >Priority: Minor > Labels: QueryComponent > Fix For: master (8.0) > > Attachments: > 0001-Refactor-QueryElevationComponent-to-introduce-Elevat.patch, > SOLR-11865.patch > > > The goal is to prepare a second improvement to support query terms subset > matching or query elevation rules. > Before that, we need to refactor the QueryElevationComponent. We make it > extendible. We introduce the ElevationProvider interface which will be > implemented later in a second patch to support subset matching. The current > full-query match policy becomes a default simple MapElevationProvider. > - Add overridable methods to handle exceptions during the component > initialization. > - Add overridable methods to provide the default values for config properties. > - No functional change beyond refactoring. > - Adapt unit test. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11947) 7.3 Streaming Expression Documentation
[ https://issues.apache.org/jira/browse/SOLR-11947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395473#comment-16395473 ] Cassandra Targett commented on SOLR-11947: -- I'm not totally sure which commit you're referring to. Was it the big commit I did for typos a couple weeks ago? Most of it was already backported to branch_7x, but because you had a bunch edits in master that weren't on branch_7x, and I didn't notice that until too late, I had huge merge conflicts and ended up removing the changes for that file entirely from my cherry-pick and left them on master. Which, now that I think about it, probably was the wrong thing to do and I see now why that's caused you some confusion. I'm not sure what would happen if you tried to backport my big commit since almost all of it already exists in the branch. One solution would be to simply checkout the file from master to branch_7x and branch_7_3, but I don't know if what you have in master is supposed to be in those branches or not since I'm not sure what you're doing overall. I don't particularly care if my changes make it into 7.3 - I can make the changes again later for 7.4. > 7.3 Streaming Expression Documentation > -- > > Key: SOLR-11947 > URL: https://issues.apache.org/jira/browse/SOLR-11947 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation, streaming expressions >Reporter: Joel Bernstein >Priority: Major > Attachments: SOLR-11947.patch, SOLR-11947.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12070) TestJMXIntegration.testJMXOnCoreReload always fails
[ https://issues.apache.org/jira/browse/SOLR-12070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395454#comment-16395454 ] Erick Erickson commented on SOLR-12070: --- Does the way MBeans are registered now have enough tests behind it that we can just remove this totally? > TestJMXIntegration.testJMXOnCoreReload always fails > --- > > Key: SOLR-12070 > URL: https://issues.apache.org/jira/browse/SOLR-12070 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (8.0) >Reporter: Andrzej Bialecki >Assignee: Andrzej Bialecki >Priority: Major > > This test is marked @BadApple but the issue it refers to probably doesn't > apply anymore since the JMX integration has been substantially changed as a > part of the metrics refactoring. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Windows (32bit/jdk1.8.0_144) - Build # 499 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/499/ Java: 32bit/jdk1.8.0_144 -client -XX:+UseSerialGC 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.lucene.store.TestMultiMMap Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.store.TestMultiMMap_EE927C3F6AB49B80-001\testSeekEnd-016: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.store.TestMultiMMap_EE927C3F6AB49B80-001\testSeekEnd-016 C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.store.TestMultiMMap_EE927C3F6AB49B80-001\tempDir-002: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.store.TestMultiMMap_EE927C3F6AB49B80-001\tempDir-002 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.store.TestMultiMMap_EE927C3F6AB49B80-001\testSeekEnd-016: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.store.TestMultiMMap_EE927C3F6AB49B80-001\testSeekEnd-016 C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.store.TestMultiMMap_EE927C3F6AB49B80-001\tempDir-002: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J0\temp\lucene.store.TestMultiMMap_EE927C3F6AB49B80-001\tempDir-002 at __randomizedtesting.SeedInfo.seed([EE927C3F6AB49B80]:0) at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329) at org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216) at com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: junit.framework.TestSuite.org.apache.lucene.mockfile.TestVerboseFS Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\test-framework\test\J0\temp\lucene.mockfile.TestVerboseFS_B267D3F2A393B8D6-001\tempDir-010: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\test-framework\test\J0\temp\lucene.mockfile.TestVerboseFS_B267D3F2A393B8D6-001\tempDir-010 C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\test-framework\test\J0\temp\lucene.mockfile.TestVerboseFS_B267D3F2A393B8D6-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\test-framework\test\J0\temp\lucene.mockfile.TestVerboseFS_B267D3F2A393B8D6-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\test-framework\test\J0\temp\lucene.mockfile.TestVerboseFS_B267D3F2A393B8D6-001\tempDir-010: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\test-framework\test\J0\temp\lucene.mockfile.TestVerboseFS_B267D3F2A393B8D6-001\tempDir-010 C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\test-framework\test\J0\temp\lucene.mockfile.TestVerboseFS_B267D3F2A393B8D6-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\test-framework\test\J0\temp\lucene.mockfile.TestVerboseFS_B267D3F2A393B8D6-001 at __randomizedtesting.SeedInfo.seed([B267D3F2A393B8D6]:0) at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329) at org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216) at com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31)
[GitHub] lucene-solr pull request #323: SOLR-11731: LatLonPointSpatialField could be ...
Github user dsmiley commented on a diff in the pull request: https://github.com/apache/lucene-solr/pull/323#discussion_r173838565 --- Diff: solr/core/src/java/org/apache/solr/schema/LatLonPointSpatialField.java --- @@ -75,8 +77,16 @@ protected SpatialStrategy newSpatialStrategy(String fieldName) { return new LatLonPointSpatialStrategy(ctx, fieldName, schemaField.indexed(), schemaField.hasDocValues()); } - public String geoValueToStringValue(long value) { -return new String(decodeLatitudeCeil(value) + "," + decodeLongitudeCeil(value)); + /** + * Converts to "lat, lon" + * @param value Non-null; stored location field data + * @return Non-null; "lat, lon" with 6 decimal point precision --- End diff -- By "What does that translate to in the metric system?" I mean for example how many meters would this translate to with 6 decimal points? "6 was just based on what i read" read where? --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #323: SOLR-11731: LatLonPointSpatialField could be ...
Github user dsmiley commented on a diff in the pull request: https://github.com/apache/lucene-solr/pull/323#discussion_r173838087 --- Diff: solr/core/src/java/org/apache/solr/schema/LatLonPointSpatialField.java --- @@ -75,8 +77,16 @@ protected SpatialStrategy newSpatialStrategy(String fieldName) { return new LatLonPointSpatialStrategy(ctx, fieldName, schemaField.indexed(), schemaField.hasDocValues()); } - public String geoValueToStringValue(long value) { -return new String(decodeLatitudeCeil(value) + "," + decodeLongitudeCeil(value)); + /** + * Converts to "lat, lon" + * @param value Non-null; stored location field data + * @return Non-null; "lat, lon" with 6 decimal point precision + */ + public static String decodeDocValueToString(long value) { +double latitudeDecoded = BigDecimal.valueOf(decodeLatitude((int) (value >> 32))).setScale(6, HALF_UP).doubleValue(); --- End diff -- I'm not arguing with your choice; just trying to understand. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr issue #323: SOLR-11731: LatLonPointSpatialField could be improve...
Github user dsmiley commented on the issue: https://github.com/apache/lucene-solr/pull/323 In general my review here has a higher attention to detail than normal because I think there are some nitty gritty details here that should be explained so that not only me but future reviewers know _why_ we're doing what we're doing. Spatial / numerical stuff demands more attention to detail. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5143) rm or formalize dealing with "general" KEYS files in our dist dir
[ https://issues.apache.org/jira/browse/LUCENE-5143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated LUCENE-5143: Fix Version/s: master (8.0) 7.4 > rm or formalize dealing with "general" KEYS files in our dist dir > - > > Key: LUCENE-5143 > URL: https://issues.apache.org/jira/browse/LUCENE-5143 > Project: Lucene - Core > Issue Type: Task >Reporter: Hoss Man >Assignee: Jan Høydahl >Priority: Major > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-5143.patch, LUCENE-5143.patch, LUCENE-5143.patch, > LUCENE-5143_READMEs.patch, LUCENE-5143_READMEs.patch, > LUCENE-5143_READMEs.patch, LUCENE_5143_KEYS.patch > > > At some point in the past, we started creating a snapshots of KEYS (taken > from the auto-generated data from id.apache.org) in the release dir of each > release... > http://www.apache.org/dist/lucene/solr/4.4.0/KEYS > http://www.apache.org/dist/lucene/java/4.4.0/KEYS > http://archive.apache.org/dist/lucene/java/4.3.0/KEYS > http://archive.apache.org/dist/lucene/solr/4.3.0/KEYS > etc... > But we also still have some "general" KEYS files... > https://www.apache.org/dist/lucene/KEYS > https://www.apache.org/dist/lucene/java/KEYS > https://www.apache.org/dist/lucene/solr/KEYS > ...which (as i discovered when i went to add my key to them today) are stale > and don't seem to be getting updated. > I vaguely remember someone (rmuir?) explaining to me at one point the reason > we started creating a fresh copy of KEYS in each release dir, but i no longer > remember what they said, and i can't find any mention of a reason in any of > the release docs, or in any sort of comment in buildAndPushRelease.py > we probably do one of the following: > * remove these "general" KEYS files > * add a disclaimer to the top of these files that they are legacy files for > verifying old releases and are no longer used for new releases > * ensure these files are up to date stop generating per-release KEYS file > copies > * update our release process to ensure that the general files get updated on > each release as well -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12080) Frequent failures of MoveReplicaHDFSTest.testFailedMove
[ https://issues.apache.org/jira/browse/SOLR-12080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki updated SOLR-12080: - Attachment: jenkins.log.txt.gz > Frequent failures of MoveReplicaHDFSTest.testFailedMove > --- > > Key: SOLR-12080 > URL: https://issues.apache.org/jira/browse/SOLR-12080 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Andrzej Bialecki >Priority: Major > Attachments: jenkins.log.txt.gz > > > This test frequently fails. This is one of the failing seeds: > {code} >[junit4] 2> 129275 INFO (qtp1647120030-248) [n:127.0.0.1:55469_solr > c:MoveReplicaHDFSTest_failed_coll_true s:shard2 r:core_node7 > x:MoveReplicaHDFSTest_failed_coll_true_shard2_replica_n4] o.a.s.c.S.Request > [MoveReplicaHDFSTest_failed_coll_true_shard2_replica_n4] webapp=/solr > path=/select > params={q=*:*&_stateVer_=MoveReplicaHDFSTest_failed_coll_true:9=javabin=2} > status=503 QTime=0 >[junit4] 2> 129278 ERROR (qtp148844424-682) [n:127.0.0.1:54855_solr > c:MoveReplicaHDFSTest_failed_coll_true s:shard2 r:core_node8 > x:MoveReplicaHDFSTest_failed_coll_true_shard2_replica_n6] > o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: no servers > hosting shard: shard1 >[junit4] 2> at > org.apache.solr.handler.component.HttpShardHandler.prepDistributed(HttpShardHandler.java:436) >[junit4] 2> at > org.apache.solr.handler.component.SearchHandler.getAndPrepShardHandler(SearchHandler.java:226) >[junit4] 2> at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:264) >[junit4] 2> at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:195) >[junit4] 2> at > org.apache.solr.core.SolrCore.execute(SolrCore.java:2503) >[junit4] 2> at > org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711) >[junit4] 2> at > org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:517) >[junit4] 2> at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:384) >[junit4] 2> at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:330) >[junit4] 2> at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637) >[junit4] 2> at > org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139) >[junit4] 2> at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637) >[junit4] 2> at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533) >[junit4] 2> at > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188) >[junit4] 2> at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595) >[junit4] 2> at > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188) >[junit4] 2> at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253) >[junit4] 2> at > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168) >[junit4] 2> at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473) >[junit4] 2> at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564) >[junit4] 2> at > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:166) >[junit4] 2> at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155) >[junit4] 2> at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) >[junit4] 2> at > org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:527) >[junit4] 2> at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) >[junit4] 2> at > org.eclipse.jetty.server.Server.handle(Server.java:530) >[junit4] 2> at > org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:347) >[junit4] 2> at > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:256) >[junit4] 2> at > org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279) >[junit4] 2> at > org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) >[junit4] 2> at > org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124) >[junit4] 2> at >
[jira] [Assigned] (LUCENE-5143) rm or formalize dealing with "general" KEYS files in our dist dir
[ https://issues.apache.org/jira/browse/LUCENE-5143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl reassigned LUCENE-5143: --- Assignee: Jan Høydahl > rm or formalize dealing with "general" KEYS files in our dist dir > - > > Key: LUCENE-5143 > URL: https://issues.apache.org/jira/browse/LUCENE-5143 > Project: Lucene - Core > Issue Type: Task >Reporter: Hoss Man >Assignee: Jan Høydahl >Priority: Major > Attachments: LUCENE-5143.patch, LUCENE-5143.patch, LUCENE-5143.patch, > LUCENE-5143_READMEs.patch, LUCENE-5143_READMEs.patch, > LUCENE-5143_READMEs.patch, LUCENE_5143_KEYS.patch > > > At some point in the past, we started creating a snapshots of KEYS (taken > from the auto-generated data from id.apache.org) in the release dir of each > release... > http://www.apache.org/dist/lucene/solr/4.4.0/KEYS > http://www.apache.org/dist/lucene/java/4.4.0/KEYS > http://archive.apache.org/dist/lucene/java/4.3.0/KEYS > http://archive.apache.org/dist/lucene/solr/4.3.0/KEYS > etc... > But we also still have some "general" KEYS files... > https://www.apache.org/dist/lucene/KEYS > https://www.apache.org/dist/lucene/java/KEYS > https://www.apache.org/dist/lucene/solr/KEYS > ...which (as i discovered when i went to add my key to them today) are stale > and don't seem to be getting updated. > I vaguely remember someone (rmuir?) explaining to me at one point the reason > we started creating a fresh copy of KEYS in each release dir, but i no longer > remember what they said, and i can't find any mention of a reason in any of > the release docs, or in any sort of comment in buildAndPushRelease.py > we probably do one of the following: > * remove these "general" KEYS files > * add a disclaimer to the top of these files that they are legacy files for > verifying old releases and are no longer used for new releases > * ensure these files are up to date stop generating per-release KEYS file > copies > * update our release process to ensure that the general files get updated on > each release as well -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #323: SOLR-11731: LatLonPointSpatialField could be ...
Github user mrkarthik commented on a diff in the pull request: https://github.com/apache/lucene-solr/pull/323#discussion_r173832060 --- Diff: solr/core/src/test/org/apache/solr/search/TestSolr4Spatial2.java --- @@ -120,21 +120,27 @@ public void testRptWithGeometryGeo3dField() throws Exception { @Test public void testLatLonRetrieval() throws Exception { -assertU(adoc("id", "0", -"llp_1_dv_st", "-75,41", -"llp_1_dv", "-80.0,20.0", -"llp_1_dv_dvasst", "40.299599,-74.082728")); +assertU(adoc("id", "0", "llp_1_dv_st", "-75,41")); // stored --- End diff -- Sure. will add --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #323: SOLR-11731: LatLonPointSpatialField could be ...
Github user mrkarthik commented on a diff in the pull request: https://github.com/apache/lucene-solr/pull/323#discussion_r173832038 --- Diff: solr/core/src/java/org/apache/solr/schema/LatLonPointSpatialField.java --- @@ -75,8 +77,16 @@ protected SpatialStrategy newSpatialStrategy(String fieldName) { return new LatLonPointSpatialStrategy(ctx, fieldName, schemaField.indexed(), schemaField.hasDocValues()); } - public String geoValueToStringValue(long value) { -return new String(decodeLatitudeCeil(value) + "," + decodeLongitudeCeil(value)); + /** + * Converts to "lat, lon" + * @param value Non-null; stored location field data + * @return Non-null; "lat, lon" with 6 decimal point precision + */ + public static String decodeDocValueToString(long value) { +double latitudeDecoded = BigDecimal.valueOf(decodeLatitude((int) (value >> 32))).setScale(6, HALF_UP).doubleValue(); --- End diff -- HALF_UP is only for ceil, I will remove the rounding. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #323: SOLR-11731: LatLonPointSpatialField could be ...
Github user mrkarthik commented on a diff in the pull request: https://github.com/apache/lucene-solr/pull/323#discussion_r173832000 --- Diff: solr/core/src/java/org/apache/solr/search/SolrDocumentFetcher.java --- @@ -486,16 +486,14 @@ private Object decodeDVField(int localId, LeafReader leafReader, String fieldNam case SORTED_NUMERIC: final SortedNumericDocValues numericDv = leafReader.getSortedNumericDocValues(fieldName); if (numericDv != null && numericDv.advance(localId) == localId) { - if (schemaField.getType() instanceof LatLonPointSpatialField) { -long number = numericDv.nextValue(); -return ((LatLonPointSpatialField) schemaField.getType()).geoValueToStringValue(number); - } final List outValues = new ArrayList<>(numericDv.docValueCount()); for (int i = 0; i < numericDv.docValueCount(); i++) { long number = numericDv.nextValue(); Object value = decodeNumberFromDV(schemaField, number, true); // return immediately if the number is not decodable, hence won't return an empty list. if (value == null) return null; +// return the value as "lat, lon" if its not multi-valued --- End diff -- The only reason I had to do this is LatLonDocValuesField type is SORTED_NUMERIC, so even for non-multivalued data, we would be returning an array. If that is what is excepted? If the field is stored then it would return string for non-multi-valued data and string array for multi-valued data. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #323: SOLR-11731: LatLonPointSpatialField could be ...
Github user mrkarthik commented on a diff in the pull request: https://github.com/apache/lucene-solr/pull/323#discussion_r173832025 --- Diff: solr/core/src/java/org/apache/solr/schema/LatLonPointSpatialField.java --- @@ -75,8 +77,16 @@ protected SpatialStrategy newSpatialStrategy(String fieldName) { return new LatLonPointSpatialStrategy(ctx, fieldName, schemaField.indexed(), schemaField.hasDocValues()); } - public String geoValueToStringValue(long value) { -return new String(decodeLatitudeCeil(value) + "," + decodeLongitudeCeil(value)); + /** + * Converts to "lat, lon" + * @param value Non-null; stored location field data + * @return Non-null; "lat, lon" with 6 decimal point precision --- End diff -- 6 was just based on what i read, For 40.299599,-74.082728 it is 40°17'58.52",74°4'57.79". I will remove it --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12080) Frequent failures of MoveReplicaHDFSTest.testFailedMove
Andrzej Bialecki created SOLR-12080: Summary: Frequent failures of MoveReplicaHDFSTest.testFailedMove Key: SOLR-12080 URL: https://issues.apache.org/jira/browse/SOLR-12080 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Andrzej Bialecki This test frequently fails. This is one of the failing seeds: {code} [junit4] 2> 129275 INFO (qtp1647120030-248) [n:127.0.0.1:55469_solr c:MoveReplicaHDFSTest_failed_coll_true s:shard2 r:core_node7 x:MoveReplicaHDFSTest_failed_coll_true_shard2_replica_n4] o.a.s.c.S.Request [MoveReplicaHDFSTest_failed_coll_true_shard2_replica_n4] webapp=/solr path=/select params={q=*:*&_stateVer_=MoveReplicaHDFSTest_failed_coll_true:9=javabin=2} status=503 QTime=0 [junit4] 2> 129278 ERROR (qtp148844424-682) [n:127.0.0.1:54855_solr c:MoveReplicaHDFSTest_failed_coll_true s:shard2 r:core_node8 x:MoveReplicaHDFSTest_failed_coll_true_shard2_replica_n6] o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: no servers hosting shard: shard1 [junit4] 2>at org.apache.solr.handler.component.HttpShardHandler.prepDistributed(HttpShardHandler.java:436) [junit4] 2>at org.apache.solr.handler.component.SearchHandler.getAndPrepShardHandler(SearchHandler.java:226) [junit4] 2>at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:264) [junit4] 2>at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:195) [junit4] 2>at org.apache.solr.core.SolrCore.execute(SolrCore.java:2503) [junit4] 2>at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711) [junit4] 2>at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:517) [junit4] 2>at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:384) [junit4] 2>at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:330) [junit4] 2>at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637) [junit4] 2>at org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139) [junit4] 2>at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637) [junit4] 2>at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533) [junit4] 2>at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188) [junit4] 2>at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595) [junit4] 2>at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188) [junit4] 2>at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253) [junit4] 2>at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168) [junit4] 2>at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473) [junit4] 2>at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564) [junit4] 2>at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:166) [junit4] 2>at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155) [junit4] 2>at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) [junit4] 2>at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:527) [junit4] 2>at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) [junit4] 2>at org.eclipse.jetty.server.Server.handle(Server.java:530) [junit4] 2>at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:347) [junit4] 2>at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:256) [junit4] 2>at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279) [junit4] 2>at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) [junit4] 2>at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124) [junit4] 2>at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:247) [junit4] 2>at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:140) [junit4] 2>at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131) [junit4] 2>at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:382)
[jira] [Updated] (LUCENE-5143) rm or formalize dealing with "general" KEYS files in our dist dir
[ https://issues.apache.org/jira/browse/LUCENE-5143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated LUCENE-5143: Attachment: LUCENE-5143_READMEs.patch > rm or formalize dealing with "general" KEYS files in our dist dir > - > > Key: LUCENE-5143 > URL: https://issues.apache.org/jira/browse/LUCENE-5143 > Project: Lucene - Core > Issue Type: Task >Reporter: Hoss Man >Priority: Major > Attachments: LUCENE-5143.patch, LUCENE-5143.patch, LUCENE-5143.patch, > LUCENE-5143_READMEs.patch, LUCENE-5143_READMEs.patch, > LUCENE-5143_READMEs.patch, LUCENE_5143_KEYS.patch > > > At some point in the past, we started creating a snapshots of KEYS (taken > from the auto-generated data from id.apache.org) in the release dir of each > release... > http://www.apache.org/dist/lucene/solr/4.4.0/KEYS > http://www.apache.org/dist/lucene/java/4.4.0/KEYS > http://archive.apache.org/dist/lucene/java/4.3.0/KEYS > http://archive.apache.org/dist/lucene/solr/4.3.0/KEYS > etc... > But we also still have some "general" KEYS files... > https://www.apache.org/dist/lucene/KEYS > https://www.apache.org/dist/lucene/java/KEYS > https://www.apache.org/dist/lucene/solr/KEYS > ...which (as i discovered when i went to add my key to them today) are stale > and don't seem to be getting updated. > I vaguely remember someone (rmuir?) explaining to me at one point the reason > we started creating a fresh copy of KEYS in each release dir, but i no longer > remember what they said, and i can't find any mention of a reason in any of > the release docs, or in any sort of comment in buildAndPushRelease.py > we probably do one of the following: > * remove these "general" KEYS files > * add a disclaimer to the top of these files that they are legacy files for > verifying old releases and are no longer used for new releases > * ensure these files are up to date stop generating per-release KEYS file > copies > * update our release process to ensure that the general files get updated on > each release as well -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5143) rm or formalize dealing with "general" KEYS files in our dist dir
[ https://issues.apache.org/jira/browse/LUCENE-5143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395361#comment-16395361 ] Jan Høydahl commented on LUCENE-5143: - Uploaded separate patch for new master {{KEYS}} file. It is intended to be the new KEYS file and only be updated on demand, typically when a new RM prepares a release. Added some documentation to the file as well as the historic missing keys. > rm or formalize dealing with "general" KEYS files in our dist dir > - > > Key: LUCENE-5143 > URL: https://issues.apache.org/jira/browse/LUCENE-5143 > Project: Lucene - Core > Issue Type: Task >Reporter: Hoss Man >Priority: Major > Attachments: LUCENE-5143.patch, LUCENE-5143.patch, LUCENE-5143.patch, > LUCENE-5143_READMEs.patch, LUCENE-5143_READMEs.patch, LUCENE_5143_KEYS.patch > > > At some point in the past, we started creating a snapshots of KEYS (taken > from the auto-generated data from id.apache.org) in the release dir of each > release... > http://www.apache.org/dist/lucene/solr/4.4.0/KEYS > http://www.apache.org/dist/lucene/java/4.4.0/KEYS > http://archive.apache.org/dist/lucene/java/4.3.0/KEYS > http://archive.apache.org/dist/lucene/solr/4.3.0/KEYS > etc... > But we also still have some "general" KEYS files... > https://www.apache.org/dist/lucene/KEYS > https://www.apache.org/dist/lucene/java/KEYS > https://www.apache.org/dist/lucene/solr/KEYS > ...which (as i discovered when i went to add my key to them today) are stale > and don't seem to be getting updated. > I vaguely remember someone (rmuir?) explaining to me at one point the reason > we started creating a fresh copy of KEYS in each release dir, but i no longer > remember what they said, and i can't find any mention of a reason in any of > the release docs, or in any sort of comment in buildAndPushRelease.py > we probably do one of the following: > * remove these "general" KEYS files > * add a disclaimer to the top of these files that they are legacy files for > verifying old releases and are no longer used for new releases > * ensure these files are up to date stop generating per-release KEYS file > copies > * update our release process to ensure that the general files get updated on > each release as well -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5143) rm or formalize dealing with "general" KEYS files in our dist dir
[ https://issues.apache.org/jira/browse/LUCENE-5143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated LUCENE-5143: Attachment: LUCENE_5143_KEYS.patch > rm or formalize dealing with "general" KEYS files in our dist dir > - > > Key: LUCENE-5143 > URL: https://issues.apache.org/jira/browse/LUCENE-5143 > Project: Lucene - Core > Issue Type: Task >Reporter: Hoss Man >Priority: Major > Attachments: LUCENE-5143.patch, LUCENE-5143.patch, LUCENE-5143.patch, > LUCENE-5143_READMEs.patch, LUCENE-5143_READMEs.patch, LUCENE_5143_KEYS.patch > > > At some point in the past, we started creating a snapshots of KEYS (taken > from the auto-generated data from id.apache.org) in the release dir of each > release... > http://www.apache.org/dist/lucene/solr/4.4.0/KEYS > http://www.apache.org/dist/lucene/java/4.4.0/KEYS > http://archive.apache.org/dist/lucene/java/4.3.0/KEYS > http://archive.apache.org/dist/lucene/solr/4.3.0/KEYS > etc... > But we also still have some "general" KEYS files... > https://www.apache.org/dist/lucene/KEYS > https://www.apache.org/dist/lucene/java/KEYS > https://www.apache.org/dist/lucene/solr/KEYS > ...which (as i discovered when i went to add my key to them today) are stale > and don't seem to be getting updated. > I vaguely remember someone (rmuir?) explaining to me at one point the reason > we started creating a fresh copy of KEYS in each release dir, but i no longer > remember what they said, and i can't find any mention of a reason in any of > the release docs, or in any sort of comment in buildAndPushRelease.py > we probably do one of the following: > * remove these "general" KEYS files > * add a disclaimer to the top of these files that they are legacy files for > verifying old releases and are no longer used for new releases > * ensure these files are up to date stop generating per-release KEYS file > copies > * update our release process to ensure that the general files get updated on > each release as well -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-11617) Expose Alias Properties CRUD in REST API
[ https://issues.apache.org/jira/browse/SOLR-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved SOLR-11617. - Resolution: Fixed > Expose Alias Properties CRUD in REST API > > > Key: SOLR-11617 > URL: https://issues.apache.org/jira/browse/SOLR-11617 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: master (8.0) >Reporter: Gus Heck >Assignee: David Smiley >Priority: Major > Fix For: 7.3 > > Attachments: SOLR_11617.patch, SOLR_11617.patch > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Note: Aliases metadata is now "properties". See the Ref Guide for final > documentation for V1 {{ALIASPROP}} or V2 introspect on {{set-alias-property}} > > SOLR-11487 is adding Java API for metadata on aliases, this task is to expose > that functionality to end-users via a REST API. > Some proposed commands, for initial discussion: > - *SETALIASMETA* - upsert, or delete if blank/null/white-space provided. > - *GETALIASMETA* - read existing alias metadata > Given that the parent ticket to this task is going to rely on the alias > metadata, and I suspect a user would potentially completely break their time > partitioned data configuration by editing system metadata directly, we should > either document these commands as "use at your own risk, great > power/responsibility etc" or consider protecting some subset of metadata. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11617) Expose Alias Properties CRUD in REST API
[ https://issues.apache.org/jira/browse/SOLR-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395324#comment-16395324 ] ASF subversion and git services commented on SOLR-11617: Commit 4a0d96974b4d5ee1e68036c6b3782e4f3f2136b8 in lucene-solr's branch refs/heads/branch_7_3 from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4a0d969 ] SOLR-11617: rename alias metadata to properties (cherry picked from commit 9957e0e) > Expose Alias Properties CRUD in REST API > > > Key: SOLR-11617 > URL: https://issues.apache.org/jira/browse/SOLR-11617 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: master (8.0) >Reporter: Gus Heck >Assignee: David Smiley >Priority: Major > Fix For: 7.3 > > Attachments: SOLR_11617.patch, SOLR_11617.patch > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Note: Aliases metadata is now "properties". See the Ref Guide for final > documentation for V1 {{ALIASPROP}} or V2 introspect on {{set-alias-property}} > > SOLR-11487 is adding Java API for metadata on aliases, this task is to expose > that functionality to end-users via a REST API. > Some proposed commands, for initial discussion: > - *SETALIASMETA* - upsert, or delete if blank/null/white-space provided. > - *GETALIASMETA* - read existing alias metadata > Given that the parent ticket to this task is going to rely on the alias > metadata, and I suspect a user would potentially completely break their time > partitioned data configuration by editing system metadata directly, we should > either document these commands as "use at your own risk, great > power/responsibility etc" or consider protecting some subset of metadata. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11617) Expose Alias Properties CRUD in REST API
[ https://issues.apache.org/jira/browse/SOLR-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395318#comment-16395318 ] ASF subversion and git services commented on SOLR-11617: Commit 9957e0eed2f93cc69abc132ec631a57decd22b77 in lucene-solr's branch refs/heads/branch_7x from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9957e0e ] SOLR-11617: rename alias metadata to properties (cherry picked from commit bf6503b) > Expose Alias Properties CRUD in REST API > > > Key: SOLR-11617 > URL: https://issues.apache.org/jira/browse/SOLR-11617 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: master (8.0) >Reporter: Gus Heck >Assignee: David Smiley >Priority: Major > Fix For: 7.3 > > Attachments: SOLR_11617.patch, SOLR_11617.patch > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Note: Aliases metadata is now "properties". See the Ref Guide for final > documentation for V1 {{ALIASPROP}} or V2 introspect on {{set-alias-property}} > > SOLR-11487 is adding Java API for metadata on aliases, this task is to expose > that functionality to end-users via a REST API. > Some proposed commands, for initial discussion: > - *SETALIASMETA* - upsert, or delete if blank/null/white-space provided. > - *GETALIASMETA* - read existing alias metadata > Given that the parent ticket to this task is going to rely on the alias > metadata, and I suspect a user would potentially completely break their time > partitioned data configuration by editing system metadata directly, we should > either document these commands as "use at your own risk, great > power/responsibility etc" or consider protecting some subset of metadata. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11617) Expose Alias Properties CRUD in REST API
[ https://issues.apache.org/jira/browse/SOLR-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395317#comment-16395317 ] ASF subversion and git services commented on SOLR-11617: Commit bf6503ba5871228692ca79f0b2204a935538e00a in lucene-solr's branch refs/heads/master from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bf6503b ] SOLR-11617: rename alias metadata to properties > Expose Alias Properties CRUD in REST API > > > Key: SOLR-11617 > URL: https://issues.apache.org/jira/browse/SOLR-11617 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: master (8.0) >Reporter: Gus Heck >Assignee: David Smiley >Priority: Major > Fix For: 7.3 > > Attachments: SOLR_11617.patch, SOLR_11617.patch > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Note: Aliases metadata is now "properties". See the Ref Guide for final > documentation for V1 {{ALIASPROP}} or V2 introspect on {{set-alias-property}} > > SOLR-11487 is adding Java API for metadata on aliases, this task is to expose > that functionality to end-users via a REST API. > Some proposed commands, for initial discussion: > - *SETALIASMETA* - upsert, or delete if blank/null/white-space provided. > - *GETALIASMETA* - read existing alias metadata > Given that the parent ticket to this task is going to rely on the alias > metadata, and I suspect a user would potentially completely break their time > partitioned data configuration by editing system metadata directly, we should > either document these commands as "use at your own risk, great > power/responsibility etc" or consider protecting some subset of metadata. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_144) - Build # 7218 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7218/ Java: 32bit/jdk1.8.0_144 -server -XX:+UseSerialGC 17 tests failed. FAILED: junit.framework.TestSuite.org.apache.lucene.index.TestBackwardsCompatibility Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_9ACA01BAFE82CD47-001\3.6.0-nocfs-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_9ACA01BAFE82CD47-001\3.6.0-nocfs-001 C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_9ACA01BAFE82CD47-001\2.0.0-cfs-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_9ACA01BAFE82CD47-001\2.0.0-cfs-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_9ACA01BAFE82CD47-001\3.6.0-nocfs-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_9ACA01BAFE82CD47-001\3.6.0-nocfs-001 C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_9ACA01BAFE82CD47-001\2.0.0-cfs-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_9ACA01BAFE82CD47-001\2.0.0-cfs-001 at __randomizedtesting.SeedInfo.seed([9ACA01BAFE82CD47]:0) at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329) at org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216) at com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: junit.framework.TestSuite.org.apache.lucene.store.TestMultiMMap Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J0\temp\lucene.store.TestMultiMMap_67336ADD32137F31-001\testSeekSliceZero-026: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J0\temp\lucene.store.TestMultiMMap_67336ADD32137F31-001\testSeekSliceZero-026 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J0\temp\lucene.store.TestMultiMMap_67336ADD32137F31-001\testSeekSliceZero-026: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J0\temp\lucene.store.TestMultiMMap_67336ADD32137F31-001\testSeekSliceZero-026 at __randomizedtesting.SeedInfo.seed([67336ADD32137F31]:0) at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329) at org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216) at com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
[jira] [Commented] (LUCENE-8198) Add ability to persist deletes across merges
[ https://issues.apache.org/jira/browse/LUCENE-8198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395265#comment-16395265 ] Simon Willnauer commented on LUCENE-8198: - [~rcmuir] I opened LUCENE-8200 > Add ability to persist deletes across merges > > > Key: LUCENE-8198 > URL: https://issues.apache.org/jira/browse/LUCENE-8198 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 7.3, master (8.0) >Reporter: Simon Willnauer >Assignee: Simon Willnauer >Priority: Major > Attachments: LUCENE-8198.patch > > > This allows conditionally persist deletes on a per document basis to prevent > them from being merged away. This expert feature is useful to maintain > history of documents in the index where otherwise a duplicate storage > mechanism would be needed. For instance features like CouchDBs changes API > can be build on top of persistent deletes. While using persistent deletes has > a considerably small overhead at merge time or when deletes applied to fully > deleted segments, there is no impact if persistent deletes are unused. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org