[jira] [Updated] (SOLR-11331) Ability to Debug Solr With Eclipse IDE

[Varun Thacker (JIRA)]

 [ 
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

[Varun Thacker (JIRA)]

 [ 
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

[Alex Ott]

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 Erickson  
wrote:

 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

[Koji Sekiguchi (JIRA)]

 [ 
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)

[David Smiley (JIRA)]

[ 
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)

[David Smiley (JIRA)]

[ 
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)

[David Smiley (JIRA)]

 [ 
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

[Cao Manh Dat (JIRA)]

 [ 
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!

[Policeman Jenkins Server]

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

[Apache Jenkins Server]

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

[ASF subversion and git services (JIRA)]

[ 
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

[ASF subversion and git services (JIRA)]

[ 
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

[mrkarthik]

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

[Karthik Ramachandran (JIRA)]

 [ 
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

[Karthik Ramachandran (JIRA)]

[ 
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

[David Smiley (JIRA)]

[ 
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

[David Smiley (JIRA)]

[ 
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

[ASF subversion and git services (JIRA)]

[ 
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

[ASF subversion and git services (JIRA)]

[ 
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

[Zheng Lin Edwin Yeo]

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

[Amrit Sarkar (JIRA)]

 [ 
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

[ASF subversion and git services (JIRA)]

[ 
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!

[Policeman Jenkins Server]

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

[Apache Jenkins Server]

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!

[Policeman Jenkins Server]

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 (JIRA)]

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

[Apache Jenkins Server]

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

[Apache Jenkins Server]

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!

[Policeman Jenkins Server]

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!

[Policeman Jenkins Server]

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

[Shawn Heisey (JIRA)]

[ 
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

[Shawn Heisey (JIRA)]

 [ 
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.

[Amrit Sarkar (JIRA)]

[ 
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!

[Policeman Jenkins Server]

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

[Apache Jenkins Server]

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

[Varun Thacker (JIRA)]

[ 
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

[Varun Thacker (JIRA)]

 [ 
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

[Alan Woodward (JIRA)]

 [ 
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 (JIRA)]

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

[David Smiley (JIRA)]

[ 
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)

[David Smiley (JIRA)]

[ 
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)

[David Smiley (JIRA)]

 [ 
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 (JIRA)]

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 (JIRA)]

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

[Apache Jenkins Server]

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!

[Policeman Jenkins Server]

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

[Michael McCandless (JIRA)]

[ 
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

[Varun Thacker (JIRA)]

[ 
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

[Steve Rowe (JIRA)]

 [ 
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

[Dawid Weiss (JIRA)]

[ 
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!

[Policeman Jenkins Server]

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 (JIRA)]

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

[Apache Jenkins Server]

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!

[Policeman Jenkins Server]

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

[Apache Jenkins Server]

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

[David Smiley (JIRA)]

[ 
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.

[Varun Thacker (JIRA)]

[ 
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 ...

[mrkarthik]

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 ...

[mrkarthik]

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

[Robert Muir (JIRA)]

[ 
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 ...

[dsmiley]

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

[Varun Thacker (JIRA)]

[ 
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

[ASF subversion and git services (JIRA)]

[ 
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

[ASF subversion and git services (JIRA)]

[ 
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

[Joel Bernstein (JIRA)]

[ 
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

[ASF subversion and git services (JIRA)]

[ 
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

[ASF subversion and git services (JIRA)]

[ 
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

[ASF subversion and git services (JIRA)]

[ 
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

[ASF subversion and git services (JIRA)]

[ 
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

[ASF subversion and git services (JIRA)]

[ 
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

[Varun Thacker (JIRA)]

 [ 
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

[Apache Jenkins Server]

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

[Joel Bernstein (JIRA)]

[ 
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!

[Policeman Jenkins Server]

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

[David Smiley (JIRA)]

[ 
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

[Erick Erickson (JIRA)]

[ 
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

[David Smiley (JIRA)]

[ 
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

[Cassandra Targett (JIRA)]

[ 
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

[Erick Erickson (JIRA)]

[ 
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!

[Policeman Jenkins Server]

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 ...

[dsmiley]

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 ...

[dsmiley]

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...

[dsmiley]

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

[JIRA]

 [ 
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

[Andrzej Bialecki (JIRA)]

 [ 
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

[JIRA]

 [ 
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 ...

[mrkarthik]

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 ...

[mrkarthik]

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 ...

[mrkarthik]

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 ...

[mrkarthik]

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 (JIRA)]

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

[JIRA]

 [ 
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

[JIRA]

[ 
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

[JIRA]

 [ 
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

[David Smiley (JIRA)]

 [ 
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

[ASF subversion and git services (JIRA)]

[ 
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

[ASF subversion and git services (JIRA)]

[ 
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

[ASF subversion and git services (JIRA)]

[ 
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!

[Policeman Jenkins Server]

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

[Simon Willnauer (JIRA)]

[ 
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