[jira] [Commented] (SOLR-10910) Clean up a few details left over from pluggable transient core and untangling CoreDescriptor/CoreContainer references

[Mikhail Khludnev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16068074#comment-16068074
 ] 

Mikhail Khludnev commented on SOLR-10910:
-

fyi

{code}
Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.x/979/

All tests passed

Build Log:
[...truncated 10237 lines...]
[javac] Compiling 1096 source files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/solr/build/solr-core/classes/java
[javac] 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/solr/core/src/java/org/apache/solr/core/SolrCore.java:2836:
 error: cannot find symbol
[javac] lst.add("aliases", coreContainer.getCoreNames(this));
[javac] ^
[javac]   symbol:   method getCoreNames(SolrCore)
[javac]   location: variable coreContainer of type CoreContainer
{code}

> Clean up a few details left over from pluggable transient core and untangling 
> CoreDescriptor/CoreContainer references
> -
>
> Key: SOLR-10910
> URL: https://issues.apache.org/jira/browse/SOLR-10910
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Attachments: SOLR-10910.patch, SOLR-10910.patch
>
>
> There are a few bits of the code from SOLR-10007, SOLR-8906 that could stand 
> some cleanup. For instance, the TransientSolrCoreCache is rather awkwardly 
> hanging around in CoreContainer and would fit more naturally in SolrCores.
> What I've seen so far shouldn't result in incorrect behavior, just cleaning 
> up for the future.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10973) SolrJ: ContentType is not parsed properly in HttpSolrClient

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16068051#comment-16068051
 ] 

ASF subversion and git services commented on SOLR-10973:


Commit 224f349857889d4ac8493cce0008eb51a2b7cb9b in lucene-solr's branch 
refs/heads/master from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=224f349 ]

SOLR-10973: Use the correct constructor for InputStreamBody.


> SolrJ: ContentType is not parsed properly in HttpSolrClient
> ---
>
> Key: SOLR-10973
> URL: https://issues.apache.org/jira/browse/SOLR-10973
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 6.6
>Reporter: Karl Wright
>Assignee: Karl Wright
>
> When multipart posting is used, the content type is passed to the constructor 
> for InputStreamBody as a simple string:
> {code}
> parts.add(new FormBodyPart(name,
> new InputStreamBody(
> content.getStream(),
> contentType,
> content.getName(;
> {code}
> This is incorrect; HttpClient does not parse that contentType as anything 
> other than a mime type and thus blows up when you pass in something like 
> "text/plain; charset=utf-8".  The correct code is:
> {code}
> parts.add(new FormBodyPart(name,
> new InputStreamBody(
> content.getStream(),
> ContentType.parse(contentType),
> content.getName(;
> {code}
> This was discovered by a ManifoldCF user.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-Tests-6.x - Build # 979 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.x/979/

All tests passed

Build Log:
[...truncated 10237 lines...]
[javac] Compiling 1096 source files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/solr/build/solr-core/classes/java
[javac] 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/solr/core/src/java/org/apache/solr/core/SolrCore.java:2836:
 error: cannot find symbol
[javac] lst.add("aliases", coreContainer.getCoreNames(this));
[javac] ^
[javac]   symbol:   method getCoreNames(SolrCore)
[javac]   location: variable coreContainer of type CoreContainer
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/build.xml:810: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/build.xml:754: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/build.xml:59: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/solr/build.xml:267: 
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/solr/common-build.xml:549:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/solr/common-build.xml:497:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/solr/common-build.xml:398:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/lucene/common-build.xml:501:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/lucene/common-build.xml:1967:
 Compile failed; see the compiler error output for details.

Total time: 22 minutes 47 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10842) Move quickstart.html to Ref Guide

[JIRA]

[ 
https://issues.apache.org/jira/browse/SOLR-10842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16068083#comment-16068083
 ] 

Jan Høydahl commented on SOLR-10842:


I think all of these changes are very good. Some comments:

bq. *solr-system-requirements.adoc*: The instructions in this section should 
work for any platform, with a few exceptions for Windows as noted.
I cannot find any exceptions for windows in that file. Solr tests are also run 
on macOS (Uwe). I think this page should probably mention that Oracle JRE and 
OpenJDK are believed to have best test coverage and stability, and that some 
versions of Java shipping with some Linux distros do not work.

bq. *solr-configuration-files.adoc*: When Solr runs in an application server...
We should not talk about app servers. Solr is a standalone app

bq. *solr-quick-start.adoc*: wt=json=true...
No need for wt=json=true after it becomes the default in 7.0

> Move quickstart.html to Ref Guide
> -
>
> Key: SOLR-10842
> URL: https://issues.apache.org/jira/browse/SOLR-10842
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-10842.patch
>
>
> The Solr Quick Start at https://lucene.apache.org/solr/quickstart.html has 
> been problematic to keep up to date - until Ishan just updated it yesterday 
> for 6.6, it said "6.2.1", so hadn't been updated for several releases.
> Now that the Ref Guide is in AsciiDoc format, we can easily use variables for 
> package versions, and it could be released as part of the Ref Guide and kept 
> up to date. It could also integrate links to more information on topics, and 
> users would already be IN the docs, so they would not need to wonder where 
> the docs are.
> There are a few places on the site that will need to be updated to point to 
> the new location, but I can also put a redirect rule into .htaccess so people 
> are redirected to the new location if there are other links "in the wild" 
> that we cannot control. This allows it to be versioned also, if that becomes 
> necessary.
> As part of this, I would like to also update the entire "Getting Started" 
> section of the Ref Guide, which is effectively identical to what was in the 
> first release of the Ref Guide back in 2009 for Solr 1.4 and is in serious 
> need of reconsideration.
> My thought is that moving the page + redoing the Getting Started section 
> would be for 7.0, but if folks are excited about this idea I could move the 
> page for 6.6 and hold off redoing the larger section until 7.0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-2228) AES Encrypted Directory

[JIRA]

[ 
https://issues.apache.org/jira/browse/LUCENE-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16068101#comment-16068101
 ] 

Jan Høydahl commented on LUCENE-2228:
-

Is this encrypted directory in production somewhere? How secure is it? 
Performance overhead?

> AES Encrypted Directory
> ---
>
> Key: LUCENE-2228
> URL: https://issues.apache.org/jira/browse/LUCENE-2228
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/other
>Affects Versions: 3.1
>Reporter: Jay Mundrawala
> Attachments: LUCENE-2228.patch, lucene-encryption.tar.gz
>
>
> Provides an encryption solution for Lucene indexes, using the AES encryption 
> algorithm.
> You must have the JCE Unlimited Strength Jurisdiction Policy Files 6 Release 
> Candidate which
> you can get from java.sun.com.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: branch_6x does not build

[Mikhail Khludnev]

Hi,

I tried to fix

$ git diff

diff --git a/solr/core/src/java/org/apache/solr/core/SolrCore.java
b/solr/core/src/java/org/apache/solr/core/SolrCore.java

index c02c748..e60f9dd 100644

--- a/solr/core/src/java/org/apache/solr/core/SolrCore.java

+++ b/solr/core/src/java/org/apache/solr/core/SolrCore.java

@@ -2833,7 +2833,7 @@ public final class SolrCore implements SolrInfoMBean,
SolrMetricProducer, Closea

 CoreDescriptor cd = getCoreDescriptor();

 if (cd != null) {

   if (coreContainer != null) {

-lst.add("aliases", coreContainer.getCoreNames(this));

+lst.add("aliases", coreContainer.getNamesForCore(this));

   }

   CloudDescriptor cloudDesc = cd.getCloudDescriptor();

   if (cloudDesc != null) {


but got the next compile errors

common.compile-test:

[mkdir] Created dir: /home/
mikhail_khlud...@epam.com/lucene-solr/solr/build/solr-core/classes/test

[javac] Compiling 785 source files to /home/
mikhail_khlud...@epam.com/lucene-solr/solr/build/solr-core/classes/test

[javac] /home/
mikhail_khlud...@epam.com/lucene-solr/solr/core/src/test/org/apache/solr/cloud/BasicDistributedZkTest.java:524:
error: cannot find symbol

[javac] JettySolrRunner jetty = jettys.get(0);

[javac] ^

[javac]   symbol:   class JettySolrRunner

[javac]   location: class BasicDistributedZkTest

[javac] /home/
mikhail_khlud...@epam.com/lucene-solr/solr/core/src/test/org/apache/solr/cloud/BasicDistributedZkTest.java:569:
error: cannot find symbol

[javac]   assertEquals(0,
CollectionAdminRequest.createCollection(collection, "conf1", numShards, 1)

[javac]   ^

[javac]   symbol:   variable CollectionAdminRequest

[javac]   location: class BasicDistributedZkTest

[javac] /home/
mikhail_khlud...@epam.com/lucene-solr/solr/core/src/test/org/apache/solr/cloud/BasicDistributedZkTest.java:584:
error: cannot find symbol

[javac]
assertTrue(CollectionAdminRequest.addReplicaToShard(collection,
"shard"+((freezeI%numShards)+1))

[javac]  ^

[javac]   symbol:   variable CollectionAdminRequest

[javac]   location: class BasicDistributedZkTest

[javac] /home/
mikhail_khlud...@epam.com/lucene-solr/solr/core/src/test/org/apache/solr/cloud/UnloadDistributedZkTest.java:118:
error: cannot find symbol

[javac] SolrClient client = clients.get(0);

[javac] ^

[javac]   symbol:   class SolrClient

[javac]   location: class UnloadDistributedZkTest

[javac] /home/
mikhail_khlud...@epam.com/lucene-solr/solr/core/src/test/org/apache/solr/cloud/UnloadDistributedZkTest.java:170:
error: cannot find symbol

[javac] SolrClient client = clients.get(0);

[javac] ^

[javac]   symbol:   class SolrClient

[javac]   location: class UnloadDistributedZkTest

[javac] /home/
mikhail_khlud...@epam.com/lucene-solr/solr/core/src/test/org/apache/solr/cloud/UnloadDistributedZkTest.java:383:
error: cannot find symbol

[javac] JettySolrRunner jetty = jettys.get(0);

[javac] ^

[javac]   symbol:   class JettySolrRunner

[javac]   location: class UnloadDistributedZkTest

[javac] Note: Some input files use or override a deprecated API.

[javac] Note: Recompile with -Xlint:deprecation for details.

[javac] Note: Some input files use unchecked or unsafe operations.

[javac] Note: Recompile with -Xlint:unchecked for details.

[javac] 6 errors


common.compile-test:

[javac] Compiling 737 source files to /home/
mikhail_khlud...@epam.com/lucene-solr/solr/build/solr-core/classes/test

[javac] /home/
mikhail_khlud...@epam.com/lucene-solr/solr/core/src/test/org/apache/solr/cloud/BasicDistributedZkTest.java:587:
error: cannot find symbol

[javac]   .setCoreName(collection + freezeI)

[javac]   ^

[javac]   symbol:   method setCoreName(String)

[javac]   location: class AddReplica

On Thu, Jun 29, 2017 at 12:28 PM, Karl Wright  wrote:

> Problem is the following lines:
>
> >>
> acf30220 solr/core/src/java/org/apache/solr/core/SolrCore.java (Erick
> Erickson2017-04-12 21:55:52 -0700 2835)   if
> (coreContainer != null) {
> acf30220 solr/core/src/java/org/apache/solr/core/SolrCore.java (Erick
> Erickson2017-04-12 21:55:52 -0700 2836)
> lst.add("aliases", coreContainer.getCoreNames(this));
> c971f792 solr/core/src/java/org/apache/solr/core/SolrCore.java (Mark
> Robert Miller2012-07-05 20:36:05 + 2837)   }
> <<
>
> There is no getCoreNames() method in coreContainer.
>
> Could the perpetrator please fix this as fast as possible?  Thanks!!
>
> Karl
>
>


-- 
Sincerely yours
Mikhail Khludnev

[JENKINS] Lucene-Solr-6.x-Windows (32bit/jdk1.8.0_131) - Build # 1010 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/1010/
Java: 32bit/jdk1.8.0_131 -client -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 10256 lines...]
[javac] Compiling 1096 source files to 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\classes\java
[javac] 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\core\src\java\org\apache\solr\core\SolrCore.java:2836:
 error: cannot find symbol
[javac] lst.add("aliases", coreContainer.getCoreNames(this));
[javac] ^
[javac]   symbol:   method getCoreNames(SolrCore)
[javac]   location: variable coreContainer of type CoreContainer
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error

BUILD FAILED
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\build.xml:810: The following 
error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\build.xml:754: The following 
error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\build.xml:59: The following 
error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build.xml:267: The 
following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\common-build.xml:549: 
The following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\common-build.xml:497: 
The following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\common-build.xml:398: 
The following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\common-build.xml:501: 
The following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\common-build.xml:1967:
 Compile failed; see the compiler error output for details.

Total time: 16 minutes 32 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_131) - Build # 3850 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3850/
Java: 32bit/jdk1.8.0_131 -client -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 10267 lines...]
[javac] Compiling 1096 source files to 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/classes/java
[javac] 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/core/src/java/org/apache/solr/core/SolrCore.java:2836:
 error: cannot find symbol
[javac] lst.add("aliases", coreContainer.getCoreNames(this));
[javac] ^
[javac]   symbol:   method getCoreNames(SolrCore)
[javac]   location: variable coreContainer of type CoreContainer
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:810: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:754: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:59: The following error 
occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build.xml:267: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/common-build.xml:549: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/common-build.xml:497: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/common-build.xml:398: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/common-build.xml:501: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/common-build.xml:1967: 
Compile failed; see the compiler error output for details.

Total time: 30 minutes 18 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10973) SolrJ: ContentType is not parsed properly in HttpSolrClient

[Karl Wright (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16068077#comment-16068077
 ] 

Karl Wright commented on SOLR-10973:


[~erickerickson], I am blocked on committing this to the 6.x branch because of 
a compilation error due to a commit of yours:

{code}
acf30220 solr/core/src/java/org/apache/solr/core/SolrCore.java (Erick Erickson  
  2017-04-12 21:55:52 -0700 2835)   if (coreContainer != null) {
acf30220 solr/core/src/java/org/apache/solr/core/SolrCore.java (Erick Erickson  
  2017-04-12 21:55:52 -0700 2836) lst.add("aliases", 
coreContainer.getCoreNames(this));
c971f792 solr/core/src/java/org/apache/solr/core/SolrCore.java (Mark Robert 
Miller2012-07-05 20:36:05 + 2837)   }
{code}


> SolrJ: ContentType is not parsed properly in HttpSolrClient
> ---
>
> Key: SOLR-10973
> URL: https://issues.apache.org/jira/browse/SOLR-10973
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 6.6
>Reporter: Karl Wright
>Assignee: Karl Wright
>
> When multipart posting is used, the content type is passed to the constructor 
> for InputStreamBody as a simple string:
> {code}
> parts.add(new FormBodyPart(name,
> new InputStreamBody(
> content.getStream(),
> contentType,
> content.getName(;
> {code}
> This is incorrect; HttpClient does not parse that contentType as anything 
> other than a mime type and thus blows up when you pass in something like 
> "text/plain; charset=utf-8".  The correct code is:
> {code}
> parts.add(new FormBodyPart(name,
> new InputStreamBody(
> content.getStream(),
> ContentType.parse(contentType),
> content.getName(;
> {code}
> This was discovered by a ManifoldCF user.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (LUCENE-7887) TestIndexWriterWithThreads.testIOExceptionDuringWriteSegmentWithThreadsOnlyOnce() failure: numTerms2=0 vs -8

[Michael McCandless (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael McCandless resolved LUCENE-7887.

   Resolution: Fixed
Fix Version/s: master (7.0)

I found the cause: IW was in the process of aborting, while threads were 
concurrently still trying to apply deleted packets.  I simplified the code here 
to not bother clearing the delete counters from abort.

> TestIndexWriterWithThreads.testIOExceptionDuringWriteSegmentWithThreadsOnlyOnce()
>  failure: numTerms2=0 vs -8
> 
>
> Key: LUCENE-7887
> URL: https://issues.apache.org/jira/browse/LUCENE-7887
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
> Fix For: master (7.0)
>
>
> Non-reproducing failure from 
> [https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1338/]:
> {noformat}
> Checking out Revision 9f56698d33d1db9fab6a0d6f63b360b334f71583 
> (refs/remotes/origin/master)
> [...]
>[junit4] Suite: org.apache.lucene.index.TestIndexWriterWithThreads
>[junit4]   1> Thread-12393: ERROR: unexpected Throwable:
>[junit4]   1> java.lang.AssertionError: numTerms2=0 vs -8
>[junit4]   1>  at 
> org.apache.lucene.index.BufferedUpdatesStream.checkDeleteStats(BufferedUpdatesStream.java:376)
>[junit4]   1>  at 
> org.apache.lucene.index.BufferedUpdatesStream.push(BufferedUpdatesStream.java:85)
>[junit4]   1>  at 
> org.apache.lucene.index.IndexWriter.publishFrozenUpdates(IndexWriter.java:2655)
>[junit4]   1>  at 
> org.apache.lucene.index.DocumentsWriterFlushQueue$FlushTicket.finishFlush(DocumentsWriterFlushQueue.java:205)
>[junit4]   1>  at 
> org.apache.lucene.index.DocumentsWriterFlushQueue$SegmentFlushTicket.publish(DocumentsWriterFlushQueue.java:248)
>[junit4]   1>  at 
> org.apache.lucene.index.DocumentsWriterFlushQueue.innerPurge(DocumentsWriterFlushQueue.java:116)
>[junit4]   1>  at 
> org.apache.lucene.index.DocumentsWriterFlushQueue.forcePurge(DocumentsWriterFlushQueue.java:138)
>[junit4]   1>  at 
> org.apache.lucene.index.DocumentsWriter.purgeBuffer(DocumentsWriter.java:200)
>[junit4]   1>  at 
> org.apache.lucene.index.IndexWriter.purge(IndexWriter.java:5004)
>[junit4]   1>  at 
> org.apache.lucene.index.DocumentsWriter$ForcedPurgeEvent.process(DocumentsWriter.java:751)
>[junit4]   1>  at 
> org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:5061)
>[junit4]   1>  at 
> org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:5049)
>[junit4]   1>  at 
> org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1719)
>[junit4]   1>  at 
> org.apache.lucene.index.TestIndexWriterWithThreads$IndexerThread.run(TestIndexWriterWithThreads.java:86)
>[junit4]   2> NOTE: download the large Jenkins line-docs file by running 
> 'ant get-jenkins-line-docs' in the lucene directory.
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestIndexWriterWithThreads 
> -Dtests.method=testIOExceptionDuringWriteSegmentWithThreadsOnlyOnce 
> -Dtests.seed=66484822FD0371B5 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true 
> -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt
>  -Dtests.locale=es-CR -Dtests.timezone=America/Manaus -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 0.06s J2 | 
> TestIndexWriterWithThreads.testIOExceptionDuringWriteSegmentWithThreadsOnlyOnce
>  <<<
>[junit4]> Throwable #1: java.lang.AssertionError: hit unexpected 
> Throwable
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([66484822FD0371B5:2A23C9E43BA35250]:0)
>[junit4]>  at 
> org.apache.lucene.index.TestIndexWriterWithThreads._testMultipleThreadsFailure(TestIndexWriterWithThreads.java:300)
>[junit4]>  at 
> org.apache.lucene.index.TestIndexWriterWithThreads.testIOExceptionDuringWriteSegmentWithThreadsOnlyOnce(TestIndexWriterWithThreads.java:497)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
>[junit4]   2> NOTE: leaving temporary files on disk at: 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/lucene/build/core/test/J2/temp/lucene.index.TestIndexWriterWithThreads_66484822FD0371B5-001
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
> {date=PostingsFormat(name=LuceneVarGapFixedInterval), 
> field=PostingsFormat(name=LuceneVarGapFixedInterval), 
> docid=PostingsFormat(name=Asserting), 
> titleTokenized=PostingsFormat(name=LuceneFixedGap), 
> body=PostingsFormat(name=LuceneVarGapFixedInterval), 
> title=Lucene50(blocksize=128)}, 

[JENKINS] Lucene-Solr-6.x-MacOSX (64bit/jdk1.8.0) - Build # 974 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/974/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 10203 lines...]
[javac] Compiling 1096 source files to 
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/solr/build/solr-core/classes/java
[javac] 
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/solr/core/src/java/org/apache/solr/core/SolrCore.java:2836:
 error: cannot find symbol
[javac] lst.add("aliases", coreContainer.getCoreNames(this));
[javac] ^
[javac]   symbol:   method getCoreNames(SolrCore)
[javac]   location: variable coreContainer of type CoreContainer
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error

BUILD FAILED
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/build.xml:810: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/build.xml:754: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/build.xml:59: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/solr/build.xml:267: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/solr/common-build.xml:549: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/solr/common-build.xml:497: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/solr/common-build.xml:398: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene/common-build.xml:501: 
The following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene/common-build.xml:1967: 
Compile failed; see the compiler error output for details.

Total time: 18 minutes 6 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-1364) Distributed search return Solr shard header information (like qtime)

[JIRA]

[ 
https://issues.apache.org/jira/browse/SOLR-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16068035#comment-16068035
 ] 

Jan Høydahl commented on SOLR-1364:
---

Is this still needed in these days of SolrCloud, Metrics APIs and auto 
rebalance rules?

I could see the use of a {{debugShards=true}} perhaps?

> Distributed search return Solr shard header information (like qtime)
> 
>
> Key: SOLR-1364
> URL: https://issues.apache.org/jira/browse/SOLR-1364
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Affects Versions: 1.4
>Reporter: Jason Rutherglen
>Priority: Minor
> Fix For: 4.9, 6.0
>
> Attachments: SOLR-1364.patch
>
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> Distributed queries can expose the Solr shard query information
> such as qtime. The aggregate qtime can be broken up into the
> time required for each stage.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

branch_6x does not build

[Karl Wright]

Problem is the following lines:

>>
acf30220 solr/core/src/java/org/apache/solr/core/SolrCore.java (Erick
Erickson2017-04-12 21:55:52 -0700 2835)   if
(coreContainer != null) {
acf30220 solr/core/src/java/org/apache/solr/core/SolrCore.java (Erick
Erickson2017-04-12 21:55:52 -0700 2836)
lst.add("aliases", coreContainer.getCoreNames(this));
c971f792 solr/core/src/java/org/apache/solr/core/SolrCore.java (Mark Robert
Miller2012-07-05 20:36:05 + 2837)   }
<<

There is no getCoreNames() method in coreContainer.

Could the perpetrator please fix this as fast as possible?  Thanks!!

Karl

[GitHub] lucene-solr pull request #:

[m-khl]

Github user m-khl commented on the pull request:


https://github.com/apache/lucene-solr/commit/7f279bba2e4b954b95c59afa3525253b5d53b4a1#commitcomment-22828402
  
In solr/core/src/java/org/apache/solr/core/CoreContainer.java:
In solr/core/src/java/org/apache/solr/core/CoreContainer.java on line 1066:
it breaks the build 
`[javac] Compiling 1096 source files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/solr/build/solr-core/classes/java
[javac] 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/solr/core/src/java/org/apache/solr/core/SolrCore.java:2836:
 error: cannot find symbol
[javac] lst.add("aliases", coreContainer.getCoreNames(this));
[javac] ^
[javac]   symbol:   method getCoreNames(SolrCore)`



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7887) TestIndexWriterWithThreads.testIOExceptionDuringWriteSegmentWithThreadsOnlyOnce() failure: numTerms2=0 vs -8

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16068092#comment-16068092
 ] 

ASF subversion and git services commented on LUCENE-7887:
-

Commit c9c0121d9399ff0009c51d6a32632dd0962e8c8f in lucene-solr's branch 
refs/heads/master from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c9c0121 ]

LUCENE-7887: don't clear BufferedUpdatesStream on abort


> TestIndexWriterWithThreads.testIOExceptionDuringWriteSegmentWithThreadsOnlyOnce()
>  failure: numTerms2=0 vs -8
> 
>
> Key: LUCENE-7887
> URL: https://issues.apache.org/jira/browse/LUCENE-7887
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
>
> Non-reproducing failure from 
> [https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1338/]:
> {noformat}
> Checking out Revision 9f56698d33d1db9fab6a0d6f63b360b334f71583 
> (refs/remotes/origin/master)
> [...]
>[junit4] Suite: org.apache.lucene.index.TestIndexWriterWithThreads
>[junit4]   1> Thread-12393: ERROR: unexpected Throwable:
>[junit4]   1> java.lang.AssertionError: numTerms2=0 vs -8
>[junit4]   1>  at 
> org.apache.lucene.index.BufferedUpdatesStream.checkDeleteStats(BufferedUpdatesStream.java:376)
>[junit4]   1>  at 
> org.apache.lucene.index.BufferedUpdatesStream.push(BufferedUpdatesStream.java:85)
>[junit4]   1>  at 
> org.apache.lucene.index.IndexWriter.publishFrozenUpdates(IndexWriter.java:2655)
>[junit4]   1>  at 
> org.apache.lucene.index.DocumentsWriterFlushQueue$FlushTicket.finishFlush(DocumentsWriterFlushQueue.java:205)
>[junit4]   1>  at 
> org.apache.lucene.index.DocumentsWriterFlushQueue$SegmentFlushTicket.publish(DocumentsWriterFlushQueue.java:248)
>[junit4]   1>  at 
> org.apache.lucene.index.DocumentsWriterFlushQueue.innerPurge(DocumentsWriterFlushQueue.java:116)
>[junit4]   1>  at 
> org.apache.lucene.index.DocumentsWriterFlushQueue.forcePurge(DocumentsWriterFlushQueue.java:138)
>[junit4]   1>  at 
> org.apache.lucene.index.DocumentsWriter.purgeBuffer(DocumentsWriter.java:200)
>[junit4]   1>  at 
> org.apache.lucene.index.IndexWriter.purge(IndexWriter.java:5004)
>[junit4]   1>  at 
> org.apache.lucene.index.DocumentsWriter$ForcedPurgeEvent.process(DocumentsWriter.java:751)
>[junit4]   1>  at 
> org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:5061)
>[junit4]   1>  at 
> org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:5049)
>[junit4]   1>  at 
> org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1719)
>[junit4]   1>  at 
> org.apache.lucene.index.TestIndexWriterWithThreads$IndexerThread.run(TestIndexWriterWithThreads.java:86)
>[junit4]   2> NOTE: download the large Jenkins line-docs file by running 
> 'ant get-jenkins-line-docs' in the lucene directory.
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestIndexWriterWithThreads 
> -Dtests.method=testIOExceptionDuringWriteSegmentWithThreadsOnlyOnce 
> -Dtests.seed=66484822FD0371B5 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true 
> -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt
>  -Dtests.locale=es-CR -Dtests.timezone=America/Manaus -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 0.06s J2 | 
> TestIndexWriterWithThreads.testIOExceptionDuringWriteSegmentWithThreadsOnlyOnce
>  <<<
>[junit4]> Throwable #1: java.lang.AssertionError: hit unexpected 
> Throwable
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([66484822FD0371B5:2A23C9E43BA35250]:0)
>[junit4]>  at 
> org.apache.lucene.index.TestIndexWriterWithThreads._testMultipleThreadsFailure(TestIndexWriterWithThreads.java:300)
>[junit4]>  at 
> org.apache.lucene.index.TestIndexWriterWithThreads.testIOExceptionDuringWriteSegmentWithThreadsOnlyOnce(TestIndexWriterWithThreads.java:497)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
>[junit4]   2> NOTE: leaving temporary files on disk at: 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/lucene/build/core/test/J2/temp/lucene.index.TestIndexWriterWithThreads_66484822FD0371B5-001
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
> {date=PostingsFormat(name=LuceneVarGapFixedInterval), 
> field=PostingsFormat(name=LuceneVarGapFixedInterval), 
> docid=PostingsFormat(name=Asserting), 
> titleTokenized=PostingsFormat(name=LuceneFixedGap), 
> body=PostingsFormat(name=LuceneVarGapFixedInterval), 
> title=Lucene50(blocksize=128)}, 

[jira] [Commented] (SOLR-9910) Allow setting of additional jetty options in bin/solr and bin/solr.cmd

[Mano Kovacs (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16068129#comment-16068129
 ] 

Mano Kovacs commented on SOLR-9910:
---

bq. So if you cannot count on it fully except at a moment in time, it's a 
perhaps pretty flakey feature to build anything on.
Should we revert the patch?

> Allow setting of additional jetty options in bin/solr and bin/solr.cmd
> --
>
> Key: SOLR-9910
> URL: https://issues.apache.org/jira/browse/SOLR-9910
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mano Kovacs
>Assignee: Mark Miller
> Fix For: master (7.0), 6.7
>
> Attachments: SOLR-9910.patch, SOLR-9910.patch
>
>
> Command line tools allow the option {{-a}} to add JVM options to start 
> command. Proposing to add {{-j}} option to add additional config for jetty 
> (the part after {{start.jar}}).
> Motivation: jetty can be configured with start.ini in server directory. 
> Running multiple Solr instances, however, requires the configuration per 
> instance that cannot share the start.ini with other instances.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-6966) Contribution: Codec for index-level encryption

[JIRA]

[ 
https://issues.apache.org/jira/browse/LUCENE-6966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16068178#comment-16068178
 ] 

Jan Høydahl commented on LUCENE-6966:
-

[~rendel] I believe the reason you are not seeing more traction on this is not 
because it is not quality work or useful, but rather that 1) It is only a tiny 
percentage of Lucene users who need this level of security 2) The patch is huge 
and complex, so most committers won't have bandwidth (or expertise) to QA it.

There is obviously also a concern about future maintenance load if this needs 
to be touched for each version, and for each new index feature, with the risk 
of introducing a bug that breaks security. I'm sure that if a couple of 
developers with in-depth knowledge of the feature and security expertise were 
willing to contribute long-term on this you would probably be nominated as 
committers and the feature would have a safer future.

Have you considered starting by maintaining the project on GitHub, and produce 
releases (and maven artifacts), along with Lucene and Solr usage instructions? 
This would bring more focus, attract PRs, and I would expect it to be a popular 
project very soon. Of course, if there are lucene-core changes that are needed 
for the plungins to work, those would need to be committed first.

> Contribution: Codec for index-level encryption
> --
>
> Key: LUCENE-6966
> URL: https://issues.apache.org/jira/browse/LUCENE-6966
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/other
>Reporter: Renaud Delbru
>  Labels: codec, contrib
> Attachments: Encryption Codec Documentation.pdf, LUCENE-6966-1.patch, 
> LUCENE-6966-2-docvalues.patch, LUCENE-6966-2.patch
>
>
> We would like to contribute a codec that enables the encryption of sensitive 
> data in the index that has been developed as part of an engagement with a 
> customer. We think that this could be of interest for the community.
> Below is a description of the project.
> h1. Introduction
> In comparison with approaches where all data is encrypted (e.g., file system 
> encryption, index output / directory encryption), encryption at a codec level 
> enables more fine-grained control on which block of data is encrypted. This 
> is more efficient since less data has to be encrypted. This also gives more 
> flexibility such as the ability to select which field to encrypt.
> Some of the requirements for this project were:
> * The performance impact of the encryption should be reasonable.
> * The user can choose which field to encrypt.
> * Key management: During the life cycle of the index, the user can provide a 
> new version of his encryption key. Multiple key versions should co-exist in 
> one index.
> h1. What is supported ?
> - Block tree terms index and dictionary
> - Compressed stored fields format
> - Compressed term vectors format
> - Doc values format (prototype based on an encrypted index output) - this 
> will be submitted as a separated patch
> - Index upgrader: command to upgrade all the index segments with the latest 
> key version available.
> h1. How it is implemented ?
> h2. Key Management
> One index segment is encrypted with a single key version. An index can have 
> multiple segments, each one encrypted using a different key version. The key 
> version for a segment is stored in the segment info.
> The provided codec is abstract, and a subclass is responsible in providing an 
> implementation of the cipher factory. The cipher factory is responsible of 
> the creation of a cipher instance based on a given key version.
> h2. Encryption Model
> The encryption model is based on AES/CBC with padding. Initialisation vector 
> (IV) is reused for performance reason, but only on a per format and per 
> segment basis.
> While IV reuse is usually considered a bad practice, the CBC mode is somehow 
> resilient to IV reuse. The only "leak" of information that this could lead to 
> is being able to know that two encrypted blocks of data starts with the same 
> prefix. However, it is unlikely that two data blocks in an index segment will 
> start with the same data:
> - Stored Fields Format: Each encrypted data block is a compressed block 
> (~4kb) of one or more documents. It is unlikely that two compressed blocks 
> start with the same data prefix.
> - Term Vectors: Each encrypted data block is a compressed block (~4kb) of 
> terms and payloads from one or more documents. It is unlikely that two 
> compressed blocks start with the same data prefix.
> - Term Dictionary Index: The term dictionary index is encoded and encrypted 
> in one single data block.
> - Term Dictionary Data: Each data block of the term dictionary encodes a set 
> of suffixes. It is unlikely to have two dictionary data blocks sharing the 
> same prefix 

Re: branch_6x does not build

[Karl Wright]

I pushed your core code fix along with my change.  I have no idea who broke
the tests; the test class itself hasn't been touched in a while, so I
suspect it was broken due to the changes Mr. Erickson committed.

Karl


On Thu, Jun 29, 2017 at 6:30 AM, Mikhail Khludnev  wrote:

> Hi,
>
> I tried to fix
>
> $ git diff
>
> diff --git a/solr/core/src/java/org/apache/solr/core/SolrCore.java
> b/solr/core/src/java/org/apache/solr/core/SolrCore.java
>
> index c02c748..e60f9dd 100644
>
> --- a/solr/core/src/java/org/apache/solr/core/SolrCore.java
>
> +++ b/solr/core/src/java/org/apache/solr/core/SolrCore.java
>
> @@ -2833,7 +2833,7 @@ public final class SolrCore implements
> SolrInfoMBean, SolrMetricProducer, Closea
>
>  CoreDescriptor cd = getCoreDescriptor();
>
>  if (cd != null) {
>
>if (coreContainer != null) {
>
> -lst.add("aliases", coreContainer.getCoreNames(this));
>
> +lst.add("aliases", coreContainer.getNamesForCore(this));
>
>}
>
>CloudDescriptor cloudDesc = cd.getCloudDescriptor();
>
>if (cloudDesc != null) {
>
>
> but got the next compile errors
>
> common.compile-test:
>
> [mkdir] Created dir: /home/mikhail_khludnev@epam.
> com/lucene-solr/solr/build/solr-core/classes/test
>
> [javac] Compiling 785 source files to /home/mikhail_khludnev@epam.
> com/lucene-solr/solr/build/solr-core/classes/test
>
> [javac] /home/mikhail_khlud...@epam.com/lucene-solr/solr/core/src/
> test/org/apache/solr/cloud/BasicDistributedZkTest.java:524: error: cannot
> find symbol
>
> [javac] JettySolrRunner jetty = jettys.get(0);
>
> [javac] ^
>
> [javac]   symbol:   class JettySolrRunner
>
> [javac]   location: class BasicDistributedZkTest
>
> [javac] /home/mikhail_khlud...@epam.com/lucene-solr/solr/core/src/
> test/org/apache/solr/cloud/BasicDistributedZkTest.java:569: error: cannot
> find symbol
>
> [javac]   assertEquals(0, 
> CollectionAdminRequest.createCollection(collection,
> "conf1", numShards, 1)
>
> [javac]   ^
>
> [javac]   symbol:   variable CollectionAdminRequest
>
> [javac]   location: class BasicDistributedZkTest
>
> [javac] /home/mikhail_khlud...@epam.com/lucene-solr/solr/core/src/
> test/org/apache/solr/cloud/BasicDistributedZkTest.java:584: error: cannot
> find symbol
>
> [javac]   
> assertTrue(CollectionAdminRequest.addReplicaToShard(collection,
> "shard"+((freezeI%numShards)+1))
>
> [javac]  ^
>
> [javac]   symbol:   variable CollectionAdminRequest
>
> [javac]   location: class BasicDistributedZkTest
>
> [javac] /home/mikhail_khlud...@epam.com/lucene-solr/solr/core/src/
> test/org/apache/solr/cloud/UnloadDistributedZkTest.java:118: error:
> cannot find symbol
>
> [javac] SolrClient client = clients.get(0);
>
> [javac] ^
>
> [javac]   symbol:   class SolrClient
>
> [javac]   location: class UnloadDistributedZkTest
>
> [javac] /home/mikhail_khlud...@epam.com/lucene-solr/solr/core/src/
> test/org/apache/solr/cloud/UnloadDistributedZkTest.java:170: error:
> cannot find symbol
>
> [javac] SolrClient client = clients.get(0);
>
> [javac] ^
>
> [javac]   symbol:   class SolrClient
>
> [javac]   location: class UnloadDistributedZkTest
>
> [javac] /home/mikhail_khlud...@epam.com/lucene-solr/solr/core/src/
> test/org/apache/solr/cloud/UnloadDistributedZkTest.java:383: error:
> cannot find symbol
>
> [javac] JettySolrRunner jetty = jettys.get(0);
>
> [javac] ^
>
> [javac]   symbol:   class JettySolrRunner
>
> [javac]   location: class UnloadDistributedZkTest
>
> [javac] Note: Some input files use or override a deprecated API.
>
> [javac] Note: Recompile with -Xlint:deprecation for details.
>
> [javac] Note: Some input files use unchecked or unsafe operations.
>
> [javac] Note: Recompile with -Xlint:unchecked for details.
>
> [javac] 6 errors
>
>
> common.compile-test:
>
> [javac] Compiling 737 source files to /home/mikhail_khludnev@epam.
> com/lucene-solr/solr/build/solr-core/classes/test
>
> [javac] /home/mikhail_khlud...@epam.com/lucene-solr/solr/core/src/
> test/org/apache/solr/cloud/BasicDistributedZkTest.java:587: error: cannot
> find symbol
>
> [javac]   .setCoreName(collection + freezeI)
>
> [javac]   ^
>
> [javac]   symbol:   method setCoreName(String)
>
> [javac]   location: class AddReplica
>
> On Thu, Jun 29, 2017 at 12:28 PM, Karl Wright  wrote:
>
>> Problem is the following lines:
>>
>> >>
>> acf30220 solr/core/src/java/org/apache/solr/core/SolrCore.java (Erick
>> Erickson2017-04-12 21:55:52 -0700 2835)   if
>> (coreContainer != null) {
>> acf30220 solr/core/src/java/org/apache/solr/core/SolrCore.java (Erick
>> Erickson2017-04-12 21:55:52 -0700 2836)
>> lst.add("aliases", 

[jira] [Updated] (LUCENE-7891) Default LRUType of LruTaxonomyWriterCache should be guaranteed to be correct

[Jan-Willem van den Broek (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan-Willem van den Broek updated LUCENE-7891:
-
Attachment: LUCENE-7891.patch

> Default LRUType of LruTaxonomyWriterCache should be guaranteed to be correct
> 
>
> Key: LUCENE-7891
> URL: https://issues.apache.org/jira/browse/LUCENE-7891
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Affects Versions: 6.4, 6.5, 6.4.1, 6.4.2, 6.6, 6.5.1
>Reporter: Jan-Willem van den Broek
> Attachments: LUCENE-7891.patch
>
>
> LruTaxonomyWriterCache uses LRUType.LRU_HASHED by default. This has a very 
> small but non-zero chance of producing incorrect results due to collisions in 
> the longHashCode of FacetLabel. If such a collision occurs, then an affected 
> document will get an incorrect facet.
> This has happened to us in production. While it is a rare occurrence, the 
> consequences could be significant, and it was not immediately obvious what 
> caused the problem. Therefore I think it is better if the default is changed 
> to LRUType.LRU_STRING, which is guaranteed to be correct.
> I will add a patch containing this change as well as a test for the issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-10973) SolrJ: ContentType is not parsed properly in HttpSolrClient

[Karl Wright (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Wright resolved SOLR-10973.

   Resolution: Fixed
Fix Version/s: 6.7
   master (7.0)

> SolrJ: ContentType is not parsed properly in HttpSolrClient
> ---
>
> Key: SOLR-10973
> URL: https://issues.apache.org/jira/browse/SOLR-10973
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 6.6
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: master (7.0), 6.7
>
>
> When multipart posting is used, the content type is passed to the constructor 
> for InputStreamBody as a simple string:
> {code}
> parts.add(new FormBodyPart(name,
> new InputStreamBody(
> content.getStream(),
> contentType,
> content.getName(;
> {code}
> This is incorrect; HttpClient does not parse that contentType as anything 
> other than a mime type and thus blows up when you pass in something like 
> "text/plain; charset=utf-8".  The correct code is:
> {code}
> parts.add(new FormBodyPart(name,
> new InputStreamBody(
> content.getStream(),
> ContentType.parse(contentType),
> content.getName(;
> {code}
> This was discovered by a ManifoldCF user.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 385 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/385/

All tests passed

Build Log:
[...truncated 10673 lines...]
[javac] Compiling 1096 source files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-6.x/checkout/solr/build/solr-core/classes/java
[javac] 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-6.x/checkout/solr/core/src/java/org/apache/solr/core/SolrCore.java:2836:
 error: cannot find symbol
[javac] lst.add("aliases", coreContainer.getCoreNames(this));
[javac] ^
[javac]   symbol:   method getCoreNames(SolrCore)
[javac]   location: variable coreContainer of type CoreContainer
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-6.x/checkout/build.xml:818:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-6.x/checkout/build.xml:754:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-6.x/checkout/build.xml:59:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-6.x/checkout/solr/build.xml:267:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-6.x/checkout/solr/common-build.xml:549:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-6.x/checkout/solr/common-build.xml:497:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-6.x/checkout/solr/common-build.xml:398:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-6.x/checkout/lucene/common-build.xml:501:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-6.x/checkout/lucene/common-build.xml:1967:
 Compile failed; see the compiler error output for details.

Total time: 144 minutes 12 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
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 # 1408 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1408/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.TestConfigSetsAPI.testUserAndTestDefaultConfigsetsAreSame

Error Message:
Mismatch in files expected:<[[lang, elevate.xml, currency.xml, managed-schema, 
params.json, protwords.txt, stopwords.txt, synonyms.txt, solrconfig.xml]]> but 
was:<[[params.json, solrconfig.xml, lang, currency.xml, stopwords.txt, 
elevate.xml, protwords.txt, managed-schema, synonyms.txt]]>

Stack Trace:
org.junit.ComparisonFailure: Mismatch in files expected:<[[lang, elevate.xml, 
currency.xml, managed-schema, params.json, protwords.txt, stopwords.txt, 
synonyms.txt, solrconfig.xml]]> but was:<[[params.json, solrconfig.xml, lang, 
currency.xml, stopwords.txt, elevate.xml, protwords.txt, managed-schema, 
synonyms.txt]]>
at 
__randomizedtesting.SeedInfo.seed([DBE6E9A12E3D770:72C37467A4C75D3]:0)
at org.junit.Assert.assertEquals(Assert.java:125)
at 
org.apache.solr.cloud.TestConfigSetsAPI$1.preVisitDirectory(TestConfigSetsAPI.java:747)
at 
org.apache.solr.cloud.TestConfigSetsAPI$1.preVisitDirectory(TestConfigSetsAPI.java:741)
at java.nio.file.Files.walkFileTree(Files.java:2677)
at java.nio.file.Files.walkFileTree(Files.java:2742)
at 
org.apache.solr.cloud.TestConfigSetsAPI.compareDirectories(TestConfigSetsAPI.java:741)
at 
org.apache.solr.cloud.TestConfigSetsAPI.testUserAndTestDefaultConfigsetsAreSame(TestConfigSetsAPI.java:732)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 

[JENKINS-MAVEN] Lucene-Solr-Maven-6.x #359: POMs out of sync

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-6.x/359/

No tests ran.

Build Log:
[...truncated 27005 lines...]
  [mvn] [INFO] -
  [mvn] [INFO] -
  [mvn] [ERROR] COMPILATION ERROR : 
  [mvn] [INFO] -

[...truncated 765 lines...]
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/build.xml:835: The 
following error occurred while executing this line:
: Java returned: 1

Total time: 14 minutes 42 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7891) Default LRUType of LruTaxonomyWriterCache should be guaranteed to be correct

[Jan-Willem van den Broek (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16068244#comment-16068244
 ] 

Jan-Willem van den Broek commented on LUCENE-7891:
--

As discussed on the mailing list: 
http://mail-archives.apache.org/mod_mbox/lucene-dev/201706.mbox/%3CCAPz8bx0%3Dtg_DnPCdjFoVi1R8x-PaEv2TffdGudvLvjVz%2BCJgKw%40mail.gmail.com%3E

> Default LRUType of LruTaxonomyWriterCache should be guaranteed to be correct
> 
>
> Key: LUCENE-7891
> URL: https://issues.apache.org/jira/browse/LUCENE-7891
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Affects Versions: 6.4, 6.5, 6.4.1, 6.4.2, 6.6, 6.5.1
>Reporter: Jan-Willem van den Broek
> Attachments: LUCENE-7891.patch
>
>
> LruTaxonomyWriterCache uses LRUType.LRU_HASHED by default. This has a very 
> small but non-zero chance of producing incorrect results due to collisions in 
> the longHashCode of FacetLabel. If such a collision occurs, then an affected 
> document will get an incorrect facet.
> This has happened to us in production. While it is a rare occurrence, the 
> consequences could be significant, and it was not immediately obvious what 
> caused the problem. Therefore I think it is better if the default is changed 
> to LRUType.LRU_STRING, which is guaranteed to be correct.
> I will add a patch containing this change as well as a test for the issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-6.x-Solaris (64bit/jdk1.8.0) - Build # 934 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/934/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC

All tests passed

Build Log:
[...truncated 10888 lines...]
[javac] Compiling 785 source files to 
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/solr/build/solr-core/classes/test
[javac] 
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/solr/core/src/test/org/apache/solr/cloud/BasicDistributedZkTest.java:524:
 error: cannot find symbol
[javac] JettySolrRunner jetty = jettys.get(0);
[javac] ^
[javac]   symbol:   class JettySolrRunner
[javac]   location: class BasicDistributedZkTest
[javac] 
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/solr/core/src/test/org/apache/solr/cloud/BasicDistributedZkTest.java:569:
 error: cannot find symbol
[javac]   assertEquals(0, 
CollectionAdminRequest.createCollection(collection, "conf1", numShards, 1)
[javac]   ^
[javac]   symbol:   variable CollectionAdminRequest
[javac]   location: class BasicDistributedZkTest
[javac] 
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/solr/core/src/test/org/apache/solr/cloud/BasicDistributedZkTest.java:584:
 error: cannot find symbol
[javac]   
assertTrue(CollectionAdminRequest.addReplicaToShard(collection, 
"shard"+((freezeI%numShards)+1))
[javac]  ^
[javac]   symbol:   variable CollectionAdminRequest
[javac]   location: class BasicDistributedZkTest
[javac] 
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/solr/core/src/test/org/apache/solr/cloud/UnloadDistributedZkTest.java:118:
 error: cannot find symbol
[javac] SolrClient client = clients.get(0);
[javac] ^
[javac]   symbol:   class SolrClient
[javac]   location: class UnloadDistributedZkTest
[javac] 
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/solr/core/src/test/org/apache/solr/cloud/UnloadDistributedZkTest.java:170:
 error: cannot find symbol
[javac] SolrClient client = clients.get(0);
[javac] ^
[javac]   symbol:   class SolrClient
[javac]   location: class UnloadDistributedZkTest
[javac] 
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/solr/core/src/test/org/apache/solr/cloud/UnloadDistributedZkTest.java:383:
 error: cannot find symbol
[javac] JettySolrRunner jetty = jettys.get(0);
[javac] ^
[javac]   symbol:   class JettySolrRunner
[javac]   location: class UnloadDistributedZkTest
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 6 errors

BUILD FAILED
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/build.xml:810: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/build.xml:754: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/build.xml:59: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/solr/build.xml:267: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/solr/common-build.xml:549:
 The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/lucene/common-build.xml:795:
 The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/lucene/common-build.xml:807:
 The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/lucene/common-build.xml:1967:
 Compile failed; see the compiler error output for details.

Total time: 13 minutes 35 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_131) - Build # 3851 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3851/
Java: 32bit/jdk1.8.0_131 -client -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 10263 lines...]
[javac] Compiling 1096 source files to 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/classes/java
[javac] 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/core/src/java/org/apache/solr/core/SolrCore.java:2836:
 error: cannot find symbol
[javac] lst.add("aliases", coreContainer.getCoreNames(this));
[javac] ^
[javac]   symbol:   method getCoreNames(SolrCore)
[javac]   location: variable coreContainer of type CoreContainer
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:810: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:754: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:59: The following error 
occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build.xml:267: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/common-build.xml:549: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/common-build.xml:497: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/common-build.xml:398: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/common-build.xml:501: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/common-build.xml:1967: 
Compile failed; see the compiler error output for details.

Total time: 22 minutes 36 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10973) SolrJ: ContentType is not parsed properly in HttpSolrClient

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16068195#comment-16068195
 ] 

ASF subversion and git services commented on SOLR-10973:


Commit fdd6205df9054c0498bd8846d66db6f30d5d8476 in lucene-solr's branch 
refs/heads/branch_6x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fdd6205 ]

SOLR-10973: Use the correct constructor for InputStreamBody.


> SolrJ: ContentType is not parsed properly in HttpSolrClient
> ---
>
> Key: SOLR-10973
> URL: https://issues.apache.org/jira/browse/SOLR-10973
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 6.6
>Reporter: Karl Wright
>Assignee: Karl Wright
>
> When multipart posting is used, the content type is passed to the constructor 
> for InputStreamBody as a simple string:
> {code}
> parts.add(new FormBodyPart(name,
> new InputStreamBody(
> content.getStream(),
> contentType,
> content.getName(;
> {code}
> This is incorrect; HttpClient does not parse that contentType as anything 
> other than a mime type and thus blows up when you pass in something like 
> "text/plain; charset=utf-8".  The correct code is:
> {code}
> parts.add(new FormBodyPart(name,
> new InputStreamBody(
> content.getStream(),
> ContentType.parse(contentType),
> content.getName(;
> {code}
> This was discovered by a ManifoldCF user.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-7891) Default LRUType of LruTaxonomyWriterCache should be guaranteed to be correct

[Jan-Willem van den Broek (JIRA)]

Jan-Willem van den Broek created LUCENE-7891:


 Summary: Default LRUType of LruTaxonomyWriterCache should be 
guaranteed to be correct
 Key: LUCENE-7891
 URL: https://issues.apache.org/jira/browse/LUCENE-7891
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/other
Affects Versions: 6.5.1, 6.6, 6.4.2, 6.4.1, 6.5, 6.4
Reporter: Jan-Willem van den Broek


LruTaxonomyWriterCache uses LRUType.LRU_HASHED by default. This has a very 
small but non-zero chance of producing incorrect results due to collisions in 
the longHashCode of FacetLabel. If such a collision occurs, then an affected 
document will get an incorrect facet.

This has happened to us in production. While it is a rare occurrence, the 
consequences could be significant, and it was not immediately obvious what 
caused the problem. Therefore I think it is better if the default is changed to 
LRUType.LRU_STRING, which is guaranteed to be correct.

I will add a patch containing this change as well as a test for the issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10842) Move quickstart.html to Ref Guide

[Cassandra Targett (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16068346#comment-16068346
 ] 

Cassandra Targett commented on SOLR-10842:
--

Thanks Jan for the review so far. 

These are pretty minor points, but wanted to reply directly.

bq. No need for wt=json=true after it becomes the default in 7.0

Sure, but it's not committed yet so there is a (maybe slim) chance it won't be. 
Also, the whole tutorial is broken right now; this is the least of the worries 
there since it needs to be redone anyway.

bq. We should not talk about app servers. Solr is a standalone app

I'm reasonably sure that was already there in whatever original file I pulled 
from - I wouldn't have added it (at least I hope I wouldn't!) - but I'll keep 
my eye out to fix it before it's final.

> Move quickstart.html to Ref Guide
> -
>
> Key: SOLR-10842
> URL: https://issues.apache.org/jira/browse/SOLR-10842
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-10842.patch
>
>
> The Solr Quick Start at https://lucene.apache.org/solr/quickstart.html has 
> been problematic to keep up to date - until Ishan just updated it yesterday 
> for 6.6, it said "6.2.1", so hadn't been updated for several releases.
> Now that the Ref Guide is in AsciiDoc format, we can easily use variables for 
> package versions, and it could be released as part of the Ref Guide and kept 
> up to date. It could also integrate links to more information on topics, and 
> users would already be IN the docs, so they would not need to wonder where 
> the docs are.
> There are a few places on the site that will need to be updated to point to 
> the new location, but I can also put a redirect rule into .htaccess so people 
> are redirected to the new location if there are other links "in the wild" 
> that we cannot control. This allows it to be versioned also, if that becomes 
> necessary.
> As part of this, I would like to also update the entire "Getting Started" 
> section of the Ref Guide, which is effectively identical to what was in the 
> first release of the Ref Guide back in 2009 for Solr 1.4 and is in serious 
> need of reconsideration.
> My thought is that moving the page + redoing the Getting Started section 
> would be for 7.0, but if folks are excited about this idea I could move the 
> page for 6.6 and hold off redoing the larger section until 7.0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10910) Clean up a few details left over from pluggable transient core and untangling CoreDescriptor/CoreContainer references

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16067860#comment-16067860
 ] 

ASF subversion and git services commented on SOLR-10910:


Commit 7f279bba2e4b954b95c59afa3525253b5d53b4a1 in lucene-solr's branch 
refs/heads/branch_6x from [~erickerickson]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7f279bb ]

SOLR-10910: Clean up a few details left over from pluggable transient core and 
untangling CoreDescriptor/CoreContainer references

(cherry picked from commit 8f71bb40a55f6e7906e596938d0bf13900f77a94)


> Clean up a few details left over from pluggable transient core and untangling 
> CoreDescriptor/CoreContainer references
> -
>
> Key: SOLR-10910
> URL: https://issues.apache.org/jira/browse/SOLR-10910
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Attachments: SOLR-10910.patch, SOLR-10910.patch
>
>
> There are a few bits of the code from SOLR-10007, SOLR-8906 that could stand 
> some cleanup. For instance, the TransientSolrCoreCache is rather awkwardly 
> hanging around in CoreContainer and would fit more naturally in SolrCores.
> What I've seen so far shouldn't result in incorrect behavior, just cleaning 
> up for the future.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (LUCENE-7274) Add LogisticRegressionDocumentClassifier

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili resolved LUCENE-7274.
-
Resolution: Won't Fix

> Add LogisticRegressionDocumentClassifier
> 
>
> Key: LUCENE-7274
> URL: https://issues.apache.org/jira/browse/LUCENE-7274
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/classification
>Reporter: Cao Manh Dat
>Assignee: Tommaso Teofili
> Attachments: LUCENE-7274.patch
>
>
> Add LogisticRegressionDocumentClassifier for Lucene.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7838) Add a knn classifier based on fuzzy like this

[Tommaso Teofili (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16067962#comment-16067962
 ] 

Tommaso Teofili commented on LUCENE-7838:
-

I've removed the dependency on the sandbox module and created a dedicated 
version of FLT named NearestFuzzyQuery in 
org.apache.lucene.classification.utils package.
The goal now is to refine NearestFuzzyQuery in order to get better 
classification results and remove some specifics of FLT.

> Add a knn classifier based on fuzzy like this
> -
>
> Key: LUCENE-7838
> URL: https://issues.apache.org/jira/browse/LUCENE-7838
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/classification
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: master (7.0)
>
>
> FLT mixes fuzzy and MLT, in the context of Lucene based classification it 
> might be useful to add such a fuzziness to a dedicated KNN classifier (based 
> on FLT queries).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-10974) Replication - Unable to download tlog

[JIRA]

Rénald Koch created SOLR-10974:
--

 Summary: Replication - Unable to download tlog
 Key: SOLR-10974
 URL: https://issues.apache.org/jira/browse/SOLR-10974
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: replication (java)
Affects Versions: 6.7
 Environment: Redhat 7.2
Reporter: Rénald Koch


When I activate the replication of a shard via the web interface, the data will 
replicate well on the new shard, but once all the data has been copied, the 
data will be erased and the synchronization will start again indefinitely.

When I look in the logs, I have this error:
2017-06-29 10:51:39.768 ERROR 
(recoveryExecutor-3-thread-1-processing-n:X.X.X.X:8983_solr 
x:collection_shard2_replica2 s:shard2 c:collection r:core_node4) [c:collection 
s:shard2 r:core_node4 x:collection_shard2_replica2] o.a.s.h.ReplicationHandler 
Index fetch failed :org.apache.solr.common.SolrException: Unable to download 
tlog.2131263.1571535118797897728 completely. Downloaded 0!=871
   at 
org.apache.solr.handler.IndexFetcher$FileFetcher.cleanup(IndexFetcher.java:1591)
   at 
org.apache.solr.handler.IndexFetcher$FileFetcher.fetch(IndexFetcher.java:1474)
   at 
org.apache.solr.handler.IndexFetcher$FileFetcher.fetchFile(IndexFetcher.java:1449)
   at 
org.apache.solr.handler.IndexFetcher.downloadTlogFiles(IndexFetcher.java:893)
   at 
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:494)
   at 
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:301)
   at 
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:400)
   at 
org.apache.solr.cloud.RecoveryStrategy.replicate(RecoveryStrategy.java:219)
   at 
org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:471)
   at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:284)
   at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
   at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
   at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
   at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
   at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
   at java.lang.Thread.run(Thread.java:748)


I tried to extend the tlog retention time (especially with the 
commitReserveDuration option), but it does not work.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+175) - Build # 3852 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3852/
Java: 32bit/jdk-9-ea+175 -server -XX:+UseConcMarkSweepGC --illegal-access=deny

All tests passed

Build Log:
[...truncated 1699 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/build/core/test/temp/junit4-J1-20170629_124034_29110454544932844044986.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 9 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/build/core/test/temp/junit4-J0-20170629_124034_29111558777295963331987.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 3 lines...]
   [junit4] JVM J2: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/build/core/test/temp/junit4-J2-20170629_124034_29114991250505368519876.syserr
   [junit4] >>> JVM J2 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J2: EOF 

[...truncated 286 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/build/test-framework/test/temp/junit4-J1-20170629_124605_3262293059790275617526.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 3 lines...]
   [junit4] JVM J2: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/build/test-framework/test/temp/junit4-J2-20170629_124605_3263771820011727612671.syserr
   [junit4] >>> JVM J2 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J2: EOF 

[...truncated 3 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/build/test-framework/test/temp/junit4-J0-20170629_124605_3267964278042686307321.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 1051 lines...]
   [junit4] JVM J2: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/build/analysis/common/test/temp/junit4-J2-20170629_124710_8072435684402393911298.syserr
   [junit4] >>> JVM J2 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J2: EOF 

   [junit4] JVM J1: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/build/analysis/common/test/temp/junit4-J1-20170629_124710_80714717474277984217952.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 3 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/build/analysis/common/test/temp/junit4-J0-20170629_124710_8076095458014261169644.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 213 lines...]
   [junit4] JVM J2: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/build/analysis/icu/test/temp/junit4-J2-20170629_124852_99216650960343952044079.syserr
   [junit4] >>> JVM J2 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J2: EOF 

   [junit4] JVM J1: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/build/analysis/icu/test/temp/junit4-J1-20170629_124852_9928206848602798430528.syserr
   [junit4] >>> 

[jira] [Resolved] (LUCENE-7890) MemoryIndex should allow doc values iterator to be reset to the current docid

[Martijn van Groningen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Martijn van Groningen resolved LUCENE-7890.
---
Resolution: Fixed

Pushed to master branch. I did not add an entry to CHANGES.txt, because this 
bug only existed in 7.0, which hasn't been released yet.

> MemoryIndex should allow doc values iterator to be reset to the current docid
> -
>
> Key: LUCENE-7890
> URL: https://issues.apache.org/jira/browse/LUCENE-7890
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: master (7.0)
>Reporter: Martijn van Groningen
> Attachments: LUCENE-7890.patch
>
>
> The `SortedSetDocValues` and `SortedNumericDocValues` instances returned by 
> the MemoryIndex should support subsequent `advanceExact(0)` invocations.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-10975) New Admin UI Query does not URL-encode the query produced in the URL box

[Elaine Cario (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Elaine Cario updated SOLR-10975:

Summary: New Admin UI Query does not URL-encode the query produced in the 
URL box  (was: New Admin UUI Query does not URL-encode the query produced in 
the URL box)

> New Admin UI Query does not URL-encode the query produced in the URL box
> 
>
> Key: SOLR-10975
> URL: https://issues.apache.org/jira/browse/SOLR-10975
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 6.4.2
>Reporter: Elaine Cario
>
> We found that the new Admin UI (we're using 6.4.2) properly submits a query 
> with non-alphanumeric for searching, but that the clickable URL for that 
> query does not contain URL-encoded characters.  If using that URL to execute 
> the query later, an incorrect query is executed.
> If you revert back to using the deprecated Admin UI, it works fine.
> To reproduce:
> Open the Query form in the Admin UI, and enter a query string containing 
> punctuation characters, e.g. "http://someuri#123;, and click on debugQuery. 
> The debug shows the correct query in the raw query string. 
> {code}"\"http://someuri#123\""{code}
> The URL produced for the query however is not properly URL-encoded:
> {code}
> http://.../solr/collectionX/select?debugQuery=on=body=on=%22http://someuri#123"=json
> {code}
> If you click on this, the browser munges the query, and depending on the 
> query and query parser,  you may get a syntax error, the query string may get 
> cut off, or you may get different results.
> Drop back to the old deprecated UI and do the same thing, and the URL 
> produced is fully encoded:
> {code}
> http://.../solr/shardX/select?q=%22http%3A%2F%2Fsomeuri%23123%22=body=json=true=true
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7890) MemoryIndex should allow doc values iterator to be reset to the current docid

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16068302#comment-16068302
 ] 

ASF subversion and git services commented on LUCENE-7890:
-

Commit 9f096200b23ca1ff7b9d3c864c27a5b2b707f62a in lucene-solr's branch 
refs/heads/master from [~martijn]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9f09620 ]

LUCENE-7890: The `SortedSetDocValues` and `SortedNumericDocValues` instances 
returned by the MemoryIndex should support subsequent `advanceExact(0)` 
invocations.


> MemoryIndex should allow doc values iterator to be reset to the current docid
> -
>
> Key: LUCENE-7890
> URL: https://issues.apache.org/jira/browse/LUCENE-7890
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: master (7.0)
>Reporter: Martijn van Groningen
> Attachments: LUCENE-7890.patch
>
>
> The `SortedSetDocValues` and `SortedNumericDocValues` instances returned by 
> the MemoryIndex should support subsequent `advanceExact(0)` invocations.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-SmokeRelease-6.x - Build # 358 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-6.x/358/

No tests ran.

Build Log:
[...truncated 25903 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (26.7 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-6.7.0-src.tgz...
   [smoker] 29.6 MB in 0.03 sec (1146.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.7.0.tgz...
   [smoker] 69.3 MB in 0.07 sec (1010.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.7.0.zip...
   [smoker] 79.8 MB in 0.07 sec (1114.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-6.7.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6252 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.7.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6252 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.7.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.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 229 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [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 (292.4 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-6.7.0-src.tgz...
   [smoker] 50.5 MB in 0.05 sec (1078.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.7.0.tgz...
   [smoker] 141.3 MB in 0.13 sec (1112.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.7.0.zip...
   [smoker] 142.3 MB in 0.14 sec (1011.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-6.7.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-6.7.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.7.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-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.7.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-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.7.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.7.0-java8
   [smoker] Creating Solr home directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.7.0-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] "bin/solr" start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 180 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]  
   [smoker] Started Solr server on port 8983 (pid=32245). Happy searching!
   [smoker] 
   [smoker] 

[jira] [Created] (SOLR-10975) New Admin UUI Query does not URL-encode the query produced in the URL box

[Elaine Cario (JIRA)]

Elaine Cario created SOLR-10975:
---

 Summary: New Admin UUI Query does not URL-encode the query 
produced in the URL box
 Key: SOLR-10975
 URL: https://issues.apache.org/jira/browse/SOLR-10975
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Admin UI
Affects Versions: 6.4.2
Reporter: Elaine Cario


We found that the new Admin UI (we're using 6.4.2) properly submits a query 
with non-alphanumeric for searching, but that the clickable URL for that query 
does not contain URL-encoded characters.  If using that URL to execute the 
query later, an incorrect query is executed.

If you revert back to using the deprecated Admin UI, it works fine.

To reproduce:

Open the Query form in the Admin UI, and enter a query string containing 
punctuation characters, e.g. "http://someuri#123;, and click on debugQuery. 

The debug shows the correct query in the raw query string. 

{code}"\"http://someuri#123\""{code}

The URL produced for the query however is not properly URL-encoded:

{code}
http://.../solr/collectionX/select?debugQuery=on=body=on=%22http://someuri#123"=json
{code}

If you click on this, the browser munges the query, and depending on the query 
and query parser,  you may get a syntax error, the query string may get cut 
off, or you may get different results.

Drop back to the old deprecated UI and do the same thing, and the URL produced 
is fully encoded:

{code}
http://.../solr/shardX/select?q=%22http%3A%2F%2Fsomeuri%23123%22=body=json=true=true
{code}











--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-9963) Add Apache Calcite Avatica handler to Solr

[Kevin Risden (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-9963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kevin Risden updated SOLR-9963:
---
Security: (was: Public)

> Add Apache Calcite Avatica handler to Solr
> --
>
> Key: SOLR-9963
> URL: https://issues.apache.org/jira/browse/SOLR-9963
> Project: Solr
>  Issue Type: Improvement
>  Components: Parallel SQL
>Reporter: Kevin Risden
>Assignee: Kevin Risden
> Attachments: SOLR-9963.patch, SOLR-9963.patch, SOLR-9963.patch, 
> SOLR-9963.patch, test_avatica_solr.sh
>
>
> Apache Calcite Avatica has an http endpoint which allows Avatica drivers to 
> connect to the server. This can be wired in as a handler to Solr. This would 
> allow Solr to be used by any Avatica JDBC/ODBC driver. This depends on the 
> Calcite work from SOLR-8593.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-10976) StreamExpressionTest.testParallelTerminatingDaemonUpdateStream() failures: Boolean cannot be cast to Map

[Steve Rowe (JIRA)]

Steve Rowe created SOLR-10976:
-

 Summary: 
StreamExpressionTest.testParallelTerminatingDaemonUpdateStream() failures: 
Boolean cannot be cast to Map
 Key: SOLR-10976
 URL: https://issues.apache.org/jira/browse/SOLR-10976
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Steve Rowe


Non-reproducing failure from Policeman Jenkins 
[https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6688/]:

{noformat}
Checking out Revision 85069cacf40e757b3eb4d4d211b1783faf800bc5 
(refs/remotes/origin/master)
[...]
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=StreamExpressionTest 
-Dtests.method=testParallelTerminatingDaemonUpdateStream 
-Dtests.seed=340B5BCF2D4B369 -Dtests.slow=true -Dtests.locale=ca 
-Dtests.timezone=Europe/Kiev -Dtests.asserts=true -Dtests.file.encoding=Cp1252
   [junit4] ERROR   3.62s J0 | 
StreamExpressionTest.testParallelTerminatingDaemonUpdateStream <<<
   [junit4]> Throwable #1: java.io.IOException: --> 
http://127.0.0.1:63090/solr/collection1: An exception has occurred on the 
server, refer to server log for details.
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([340B5BCF2D4B369:F2246DD4A6BE7C77]:0)
   [junit4]>at 
org.apache.solr.client.solrj.io.stream.SolrStream.read(SolrStream.java:222)
   [junit4]>at 
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testParallelTerminatingDaemonUpdateStream(StreamExpressionTest.java:4364)
   [junit4]>at java.lang.Thread.run(Thread.java:748)
   [junit4]> Caused by: java.lang.ClassCastException: java.lang.Boolean 
cannot be cast to java.util.Map
   [junit4]>at 
org.apache.solr.client.solrj.io.stream.JavabinTupleStreamParser.next(JavabinTupleStreamParser.java:182)
   [junit4]>at 
org.apache.solr.client.solrj.io.stream.SolrStream.read(SolrStream.java:191)
[...]
   [junit4]   2> NOTE: test params are: 
codec=FastDecompressionCompressingStoredFields(storedFieldsFormat=CompressingStoredFieldsFormat(compressionMode=FAST_DECOMPRESSION,
 chunkSize=21931, maxDocsPerChunk=394, blockSize=393), 
termVectorsFormat=CompressingTermVectorsFormat(compressionMode=FAST_DECOMPRESSION,
 chunkSize=21931, blockSize=393)), sim=RandomSimilarity(queryNorm=false): {}, 
locale=ca, timezone=Europe/Kiev
   [junit4]   2> NOTE: Windows 10 10.0 amd64/Oracle Corporation 1.8.0_131 
(64-bit)/cpus=3,threads=6,free=185977552,total=341770240
   [junit4]   2> NOTE: All tests run in this JVM: [TestPathTrie, 
SolrExampleEmbeddedTest, CollectionAdminRequestRequiredParamsTest, 
GreaterThanEqualToEvaluatorTest, ArrayEvaluatorTest, 
StreamExpressionParserTest, SolrPingTest, TestHash, TestSolrProperties, 
ConcurrentUpdateSolrClientTest, TestZkConfigManager, 
StreamExpressionToExplanationTest, NaturalLogEvaluatorTest, 
ModuloEvaluatorTest, JsonValidatorTest, BasicHttpSolrClientTest, 
EqualsEvaluatorTest, OrEvaluatorTest, HyperbolicCosineEvaluatorTest, 
TestBatchUpdate, SolrExampleStreamingTest, SolrDocumentTest, TestXMLEscaping, 
TermsResponseTest, TestClusteringResponse, SineEvaluatorTest, 
GraphExpressionTest, HyperbolicTangentEvaluatorTest, TestEmbeddedSolrServer, 
ArcSineEvaluatorTest, CubedRootEvaluatorTest, JdbcDriverTest, 
SolrExampleBinaryTest, SolrExampleXMLTest, JettyWebappTest, 
TestSpellCheckResponse, SolrParamTest, MergeIndexesEmbeddedTest, 
QueryResponseTest, TestCoreAdmin, TestNamedListCodec, TestJavaBinCodec, 
TestDocumentObjectBinder, SolrQueryTest, ContentStreamTest, 
ModifiableSolrParamsTest, DocumentAnalysisResponseTest, TestUpdateRequestCodec, 
FieldAnalysisResponseTest, NamedListTest, FacetFieldTest, GetByIdTest, 
SolrSchemalessExampleTest, TestSolrJErrorHandling, CloudSolrClientBuilderTest, 
CloudSolrClientCacheTest, CloudSolrClientTest, HttpSolrClientBuilderTest, 
HttpSolrClientConPoolTest, LBHttpSolrClientBuilderTest, 
TestCloudSolrClientConnections, GraphTest, StreamExpressionTest]
{noformat}




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9963) Add Apache Calcite Avatica handler to Solr

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16068378#comment-16068378
 ] 

Kevin Risden commented on SOLR-9963:


Maybe at some point. The SolrJ driver could just wrap Avatica too so the client 
API doesn't really change.

> Add Apache Calcite Avatica handler to Solr
> --
>
> Key: SOLR-9963
> URL: https://issues.apache.org/jira/browse/SOLR-9963
> Project: Solr
>  Issue Type: Improvement
>  Components: Parallel SQL
>Reporter: Kevin Risden
>Assignee: Kevin Risden
> Attachments: SOLR-9963.patch, SOLR-9963.patch, SOLR-9963.patch, 
> SOLR-9963.patch, test_avatica_solr.sh
>
>
> Apache Calcite Avatica has an http endpoint which allows Avatica drivers to 
> connect to the server. This can be wired in as a handler to Solr. This would 
> allow Solr to be used by any Avatica JDBC/ODBC driver. This depends on the 
> Calcite work from SOLR-8593.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10976) StreamExpressionTest.testParallelTerminatingDaemonUpdateStream() failures: Boolean cannot be cast to Map

[Steve Rowe (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16068388#comment-16068388
 ] 

Steve Rowe commented on SOLR-10976:
---

Another Policeman failure 
[https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2711/] (from January 22, 
2017, so only the email notification is still accessible):

{noformat}
FAILED:  
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testParallelTerminatingDaemonUpdateStream

Error Message:
--> http://127.0.0.1:34900/solr/collection1: An exception has occurred on the 
server, refer to server log for details.

Stack Trace:
java.io.IOException: --> http://127.0.0.1:34900/solr/collection1: An exception 
has occurred on the server, refer to server log for details.
at 
__randomizedtesting.SeedInfo.seed([3E0A16E04BD9A583:CF6ECE881FB36A9D]:0)
at 
org.apache.solr.client.solrj.io.stream.SolrStream.read(SolrStream.java:238)
at 
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testParallelTerminatingDaemonUpdateStream(StreamExpressionTest.java:3765)
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:543)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 

[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.

[Steve Rowe (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16068402#comment-16068402
 ] 

Steve Rowe commented on SOLR-10272:
---

Policeman Jenkins failure 
[https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1408/] - doesn't 
reproduce for me on Linux, but I suspect the Solaris platform is relevant here, 
and that the failing directory comparison is depending on a sort that's not 
stable across platforms, since the directory contents are the same, just in a 
different order:

{noformat}
Checking out Revision c9c0121d9399ff0009c51d6a32632dd0962e8c8f 
(refs/remotes/origin/master)
[...]
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestConfigSetsAPI 
-Dtests.method=testUserAndTestDefaultConfigsetsAreSame 
-Dtests.seed=DBE6E9A12E3D770 -Dtests.slow=true -Dtests.locale=zh 
-Dtests.timezone=Africa/Sao_Tome -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] FAILURE 2.02s J1 | 
TestConfigSetsAPI.testUserAndTestDefaultConfigsetsAreSame <<<
   [junit4]> Throwable #1: org.junit.ComparisonFailure: Mismatch in files 
expected:<[[lang, elevate.xml, currency.xml, managed-schema, params.json, 
protwords.txt, stopwords.txt, synonyms.txt, solrconfig.xml]]> but 
was:<[[params.json, solrconfig.xml, lang, currency.xml, stopwords.txt, 
elevate.xml, protwords.txt, managed-schema, synonyms.txt]]>
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([DBE6E9A12E3D770:72C37467A4C75D3]:0)
   [junit4]>at 
org.apache.solr.cloud.TestConfigSetsAPI$1.preVisitDirectory(TestConfigSetsAPI.java:747)
   [junit4]>at 
org.apache.solr.cloud.TestConfigSetsAPI$1.preVisitDirectory(TestConfigSetsAPI.java:741)
   [junit4]>at java.nio.file.Files.walkFileTree(Files.java:2677)
   [junit4]>at java.nio.file.Files.walkFileTree(Files.java:2742)
   [junit4]>at 
org.apache.solr.cloud.TestConfigSetsAPI.compareDirectories(TestConfigSetsAPI.java:741)
   [junit4]>at 
org.apache.solr.cloud.TestConfigSetsAPI.testUserAndTestDefaultConfigsetsAreSame(TestConfigSetsAPI.java:732)
   [junit4]>at java.lang.Thread.run(Thread.java:748)
   [junit4]   2> NOTE: leaving temporary files on disk at: 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/build/solr-core/test/J1/temp/solr.cloud.TestConfigSetsAPI_DBE6E9A12E3D770-001
   [junit4]   2> Jun 29, 2017 11:31:15 AM 
com.carrotsearch.randomizedtesting.ThreadLeakControl checkThreadLeaks
   [junit4]   2> WARNING: Will linger awaiting termination of 1 leaked 
thread(s).
   [junit4]   2> NOTE: test params are: codec=Lucene70, 
sim=RandomSimilarity(queryNorm=false): {}, locale=zh, timezone=Africa/Sao_Tome
   [junit4]   2> NOTE: SunOS 5.11 amd64/Oracle Corporation 1.8.0_131 
(64-bit)/cpus=3,threads=1,free=176703120,total=518979584
   [junit4]   2> NOTE: All tests run in this JVM: [TestQueryUtils, 
MoveReplicaTest, EchoParamsTest, SparseHLLTest, TestPayloadScoreQParserPlugin, 
TestLegacyFieldCache, SimpleMLTQParserTest, TestLockTree, V2StandaloneTest, 
TestPushWriter, TestDynamicFieldCollectionResource, BasicAuthStandaloneTest, 
TestPerFieldSimilarity, TestFieldCollectionResource, 
OverseerModifyCollectionTest, TestPostingsSolrHighlighter, 
TestMultiValuedNumericRangeQuery, TestUseDocValuesAsStored, TestStressLucene, 
TestInPlaceUpdatesStandalone, SolrGraphiteReporterTest, 
DistributedFacetPivotSmallTest, TestChildDocTransformer, TestFastWriter, 
TestSolrJ, TestDistributedGrouping, TestDynamicLoading, 
DistribDocExpirationUpdateProcessorTest, FieldMutatingUpdateProcessorTest, 
SolrPluginUtilsTest, TestFiltering, TestSizeLimitedDistributedMap, 
SolrCmdDistributorTest, TestSolrConfigHandlerCloud, 
DocumentAnalysisRequestHandlerTest, HdfsTlogReplayBufferedWhileIndexingTest, 
TestCryptoKeys, DirectSolrSpellCheckerTest, TestPolicyCloud, 
LukeRequestHandlerTest, TestReplicaProperties, BasicZkTest, 
SolrCoreCheckLockOnStartupTest, ParsingFieldUpdateProcessorsTest, 
DistributedQueryComponentCustomSortTest, SpellCheckCollatorTest, 
DistributedFacetPivotLongTailTest, SolrIndexConfigTest, 
TlogReplayBufferedWhileIndexingTest, TestRandomCollapseQParserPlugin, 
TestRequestStatusCollectionAPI, CurrencyFieldTypeTest, 
TestExclusionRuleCollectionAccess, HdfsSyncSliceTest, 
HdfsChaosMonkeySafeLeaderTest, ReplicationFactorTest, TestAnalyzedSuggestions, 
TermsComponentTest, TestWordDelimiterFilterFactory, 
ClassificationUpdateProcessorTest, TestManagedSynonymGraphFilterFactory, 
FileBasedSpellCheckerTest, TestSchemaNameResource, 
TestSlowCompositeReaderWrapper, SolrCloudExampleTest, TestInitQParser, 
CachingDirectoryFactoryTest, TestTolerantUpdateProcessorCloud, 
TestCloudRecovery, SolrShardReporterTest, TestRecovery, BlockCacheTest, 
TestInfoStreamLogging, TestConfigSetsAPIExclusivity, TestSolrFieldCacheBean, 
FullSolrCloudDistribCmdsTest, TestValueSourceCache, 
OpenExchangeRatesOrgProviderTest, 

Re: 7x, and 7.0 branches

[Anshum Gupta]

Thanks Adrien, I’d want to try and do this myself as long as you can validate 
the correctness :).

I’ll be working on this in a few hours and should have an update later today 
and hopefully we’d wrap it up soon.

-Anshum



> On Jun 28, 2017, at 10:39 AM, Adrien Grand  wrote:
> 
> If you don't want to do it, I can do it tomorrow but if you'd like to give it 
> a try I'd be happy to help if you need any guidance.
> 
> Le mer. 28 juin 2017 à 19:38, Adrien Grand  > a écrit :
> Hi Anshum,
> 
> This looks like a good start to me. You would also need to remove the 6.x 
> version constants so that TestBackwardCompatibility does not think they are 
> worth testing, as well as all codecs, postings formats and doc values formats 
> that are defined in the lucene/backward-codecs module since they are only 
> about 6.x codecs.
> 
> Le mer. 28 juin 2017 à 09:57, Anshum Gupta  > a écrit :
> Thanks for confirming that Alan, I had similar thoughts but wasn’t sure. 
> 
> I don’t want to change anything that I’m not confident about so I’m just 
> going to create remove those and commit it to my fork. If someone who’s 
> confident agrees with what I’m doing, I’ll go ahead and make those changes to 
> the upstream :).
> 
> -Anshum
> 
> 
> 
>> On Jun 28, 2017, at 12:54 AM, Alan Woodward > > wrote:
>> 
>> We don’t need to support lucene5x codecs in 7, so you should be able to just 
>> remove those tests (and the the relevant packages from backwards-codecs 
>> too), I think?
>> 
>> 
>>> On 28 Jun 2017, at 08:38, Anshum Gupta >> > wrote:
>>> 
>>> I tried to move forward to see this work before automatically computing the 
>>> versions but I have about 30 odd failing test. I’ve made those changes and 
>>> pushed to my local GitHub account in case you have the time to look: 
>>> https://github.com/anshumg/lucene-solr 
>>>  
>>> 
>>> Here’s the build summary if that helps:
>>> 
>>>[junit4] Tests with failures [seed: 31C3B60E557C7E14] (first 10 out of 
>>> 31):
>>>[junit4]   - 
>>> org.apache.lucene.codecs.lucene53.TestLucene53NormsFormat.testOutliers2
>>>[junit4]   - 
>>> org.apache.lucene.codecs.lucene53.TestLucene53NormsFormat.testShortRange
>>>[junit4]   - 
>>> org.apache.lucene.codecs.lucene53.TestLucene53NormsFormat.testFewValues
>>>[junit4]   - 
>>> org.apache.lucene.codecs.lucene53.TestLucene53NormsFormat.testFullLongRange
>>>[junit4]   - 
>>> org.apache.lucene.codecs.lucene53.TestLucene53NormsFormat.testRamBytesUsed
>>>[junit4]   - 
>>> org.apache.lucene.codecs.lucene53.TestLucene53NormsFormat.testFewLargeValues
>>>[junit4]   - 
>>> org.apache.lucene.codecs.lucene53.TestLucene53NormsFormat.testByteRange
>>>[junit4]   - 
>>> org.apache.lucene.codecs.lucene53.TestLucene53NormsFormat.testLongRange
>>>[junit4]   - 
>>> org.apache.lucene.codecs.lucene50.TestLucene50SegmentInfoFormat.testRandomExceptions
>>>[junit4]   - 
>>> org.apache.lucene.codecs.lucene62.TestLucene62SegmentInfoFormat.testRandomExceptions
>>>[junit4] 
>>>[junit4] 
>>>[junit4] JVM J0: 0.56 .. 9.47 = 8.91s
>>>[junit4] JVM J1: 0.56 .. 4.13 = 3.57s
>>>[junit4] JVM J2: 0.56 ..47.28 =46.73s
>>>[junit4] JVM J3: 0.56 .. 3.89 = 3.33s
>>>[junit4] Execution time total: 47 seconds
>>>[junit4] Tests summary: 8 suites, 215 tests, 30 errors, 1 failure, 24 
>>> ignored (24 assumptions)
>>> 
>>> 
>>> -Anshum
>>> 
>>> 
>>> 
 On Jun 27, 2017, at 4:15 AM, Adrien Grand > wrote:
 
 The test***BackwardCompatibility cases can be removed since they make sure 
 that Lucene 7 can read Lucene 6 norms, while Lucene 8 doesn't have to be 
 able to read Lucene 6 norms.
 
 TestSegmentInfos needs to be adapted to the new versions, we need to 
 replace 5 with 6 and 8 with 9. Maybe we should compute those numbers 
 automatically based on Version.LATEST.major so that it does not require 
 manual changes when moving to a new major version. That would give 5 -> 
 Version.LATEST.major-2 and 8 -> Version.LATEST.major+1.
 
 I can do those changes on Thursday if you don't feel comfortable doing 
 them.
 
 
 
 Le mar. 27 juin 2017 à 08:12, Anshum Gupta > a écrit :
 Without making any changes at all and just bumping up the version, I hit 
 these errors when running the tests:
 
[junit4]   2> NOTE: reproduce with: ant test  
 -Dtestcase=TestSegmentInfos -Dtests.method=testIllegalCreatedVersion 
 -Dtests.seed=C818A61FA6C293A1 -Dtests.slow=true -Dtests.locale=es-PR 
 -Dtests.timezone=Etc/GMT+4 -Dtests.asserts=true 
 

[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.

[David Smiley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16068406#comment-16068406
 ] 

David Smiley commented on SOLR-10272:
-

Wow that's an insightful catch [~steve_rowe]!

> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz, 
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience 
> better for users.
> To create a collection we need to specify a configName that needs to be 
> present in ZK. When a new user is starting Solr why should he worry about 
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a 
> configset and references it. This is great. We should extend this idea to API 
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if 
> "/configs/_baseConfigSet" znode is present . If not it uploads the 
> "basic_configs". 
> We can discuss if its the "basic_configs" or something other default config 
> set. 
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API  
> {{admin/collections?action=CREATE=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy 
> over the default config set to a configset with the name of the collection 
> specified.
> collection.configName can truly be an optional parameter. If its specified we 
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do 
> the same thing.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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_131) - Build # 6689 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6689/
Java: 32bit/jdk1.8.0_131 -client -XX:+UseParallelGC

3 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.search.LargeFieldTest

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.search.LargeFieldTest_D08018D297FDE389-001\init-core-data-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.search.LargeFieldTest_D08018D297FDE389-001\init-core-data-001

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.search.LargeFieldTest_D08018D297FDE389-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.search.LargeFieldTest_D08018D297FDE389-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\solr-core\test\J1\temp\solr.search.LargeFieldTest_D08018D297FDE389-001\init-core-data-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.search.LargeFieldTest_D08018D297FDE389-001\init-core-data-001
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.search.LargeFieldTest_D08018D297FDE389-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.search.LargeFieldTest_D08018D297FDE389-001

at __randomizedtesting.SeedInfo.seed([D08018D297FDE389]: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:  org.apache.solr.handler.V2ApiIntegrationTest.testCollectionsApi

Error Message:
Error from server at http://127.0.0.1:57805/solr: 
java.nio.file.InvalidPathException: Illegal char <�> at index 53: 
C:UsersjenkinsworkspaceLucene-Solr-master-Windowssolr�uildsolr-core estJ0 
empsolr.handler.V2ApiIntegrationTest_D08018D297FDE389-001 empDir-002

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException: 
Error from server at http://127.0.0.1:57805/solr: 
java.nio.file.InvalidPathException: Illegal char <�> at index 53: 
C:UsersjenkinsworkspaceLucene-Solr-master-Windowssolr�uildsolr-core  estJ0  
 empsolr.handler.V2ApiIntegrationTest_D08018D297FDE389-001   empDir-002
at 
__randomizedtesting.SeedInfo.seed([D08018D297FDE389:C1EFF532FE48737]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException.create(HttpSolrClient.java:804)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:600)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:250)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:239)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:470)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:400)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1102)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:843)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:774)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.handler.V2ApiIntegrationTest.testCollectionsApi(V2ApiIntegrationTest.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at