[JENKINS] Lucene-Solr-4.x-Linux (64bit/jdk1.8.0-ea-b65) - Build # 3782 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/3782/
Java: 64bit/jdk1.8.0-ea-b65 -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 23620 lines...]
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] warning: [options] bootstrap class path not set in conjunction with 
-source 1.7
  [javadoc] Loading source files for package org.apache.lucene...
  [javadoc] Loading source files for package org.apache.lucene.analysis...
  [javadoc] Loading source files for package 
org.apache.lucene.analysis.tokenattributes...
  [javadoc] Loading source files for package org.apache.lucene.codecs...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.compressing...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene3x...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene40...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene40.values...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene41...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.perfield...
  [javadoc] Loading source files for package org.apache.lucene.document...
  [javadoc] Loading source files for package org.apache.lucene.index...
  [javadoc] Loading source files for package org.apache.lucene.search...
  [javadoc] Loading source files for package 
org.apache.lucene.search.payloads...
  [javadoc] Loading source files for package 
org.apache.lucene.search.similarities...
  [javadoc] Loading source files for package org.apache.lucene.search.spans...
  [javadoc] Loading source files for package org.apache.lucene.store...
  [javadoc] Loading source files for package org.apache.lucene.util...
  [javadoc] Loading source files for package org.apache.lucene.util.automaton...
  [javadoc] Loading source files for package org.apache.lucene.util.fst...
  [javadoc] Loading source files for package org.apache.lucene.util.mutable...
  [javadoc] Loading source files for package org.apache.lucene.util.packed...
  [javadoc] Constructing Javadoc information...
  [javadoc] Standard Doclet version 1.8.0-ea
  [javadoc] Building tree for all the packages and classes...
  [javadoc] Generating 
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/docs/core/org/apache/lucene/search/package-summary.html...
  [javadoc] Copying file 
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/core/src/java/org/apache/lucene/search/doc-files/nrq-formula-1.png
 to directory 
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/docs/core/org/apache/lucene/search/doc-files...
  [javadoc] Copying file 
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/core/src/java/org/apache/lucene/search/doc-files/nrq-formula-2.png
 to directory 
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/docs/core/org/apache/lucene/search/doc-files...
  [javadoc] Building index for all the packages and classes...
  [javadoc] Building index for all classes...
  [javadoc] Generating 
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/docs/core/help-doc.html...
  [javadoc] 1 warning

[...truncated 45 lines...]
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Loading source files for package org.apache.lucene.analysis.ar...
  [javadoc] warning: [options] bootstrap class path not set in conjunction with 
-source 1.7
  [javadoc] Loading source files for package org.apache.lucene.analysis.bg...
  [javadoc] Loading source files for package org.apache.lucene.analysis.br...
  [javadoc] Loading source files for package org.apache.lucene.analysis.ca...
  [javadoc] Loading source files for package 
org.apache.lucene.analysis.charfilter...
  [javadoc] Loading source files for package org.apache.lucene.analysis.cjk...
  [javadoc] Loading source files for package org.apache.lucene.analysis.cn...
  [javadoc] Loading source files for package 
org.apache.lucene.analysis.commongrams...
  [javadoc] Loading source files for package 
org.apache.lucene.analysis.compound...
  [javadoc] Loading source files for package 
org.apache.lucene.analysis.compound.hyphenation...
  [javadoc] Loading source files for package org.apache.lucene.analysis.core...
  [javadoc] Loading source files for package org.apache.lucene.analysis.cz...
  [javadoc] Loading source files for package org.apache.lucene.analysis.da...
  [javadoc] Loading source files for package org.apache.lucene.analysis.de...
  [javadoc] Loading source files for package org.apache.lucene.analysis.el...
  [javadoc] Loading source files for package org.apache.lucene.analysis.en...
  [javadoc] Loading source files for package org.apache.lucene.analysis.es...
  [javadoc] Loading source files for package org.apache.lucene.analysis.eu...
  [javadoc] Loading source files for package org.apache.lucene.analysis.fa...
  [javadoc] Loading source files for package org.apache.lucene.analysis.fi...
  [javadoc] Loading source files for package org.apache.l

[jira] [Commented] (SOLR-2649) MM ignored in edismax queries with operators

[Thomas Egense (JIRA)]

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

Thomas Egense commented on SOLR-2649:
-

Thank you! We have been waiting a long time for this fix.

> MM ignored in edismax queries with operators
> 
>
> Key: SOLR-2649
> URL: https://issues.apache.org/jira/browse/SOLR-2649
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Reporter: Magnus Bergmark
>Priority: Minor
> Fix For: 4.2, 5.0
>
>
> Hypothetical scenario:
>   1. User searches for "stocks oil gold" with MM set to "50%"
>   2. User adds "-stockings" to the query: "stocks oil gold -stockings"
>   3. User gets no hits since MM was ignored and all terms where AND-ed 
> together
> The behavior seems to be intentional, although the reason why is never 
> explained:
>   // For correct lucene queries, turn off mm processing if there
>   // were explicit operators (except for AND).
>   boolean doMinMatched = (numOR + numNOT + numPluses + numMinuses) == 0; 
> (lines 232-234 taken from 
> tags/lucene_solr_3_3/solr/src/java/org/apache/solr/search/ExtendedDismaxQParserPlugin.java)
> This makes edismax unsuitable as an replacement to dismax; mm is one of the 
> primary features of dismax.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0-ea-b65) - Build # 3802 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/3802/
Java: 64bit/jdk1.8.0-ea-b65 -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 23737 lines...]
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] warning: [options] bootstrap class path not set in conjunction with 
-source 1.7
  [javadoc] Loading source files for package org.apache.lucene...
  [javadoc] Loading source files for package org.apache.lucene.analysis...
  [javadoc] Loading source files for package 
org.apache.lucene.analysis.tokenattributes...
  [javadoc] Loading source files for package org.apache.lucene.codecs...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.compressing...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene40...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene40.values...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene41...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.perfield...
  [javadoc] Loading source files for package org.apache.lucene.document...
  [javadoc] Loading source files for package org.apache.lucene.index...
  [javadoc] Loading source files for package org.apache.lucene.search...
  [javadoc] Loading source files for package 
org.apache.lucene.search.payloads...
  [javadoc] Loading source files for package 
org.apache.lucene.search.similarities...
  [javadoc] Loading source files for package org.apache.lucene.search.spans...
  [javadoc] Loading source files for package org.apache.lucene.store...
  [javadoc] Loading source files for package org.apache.lucene.util...
  [javadoc] Loading source files for package org.apache.lucene.util.automaton...
  [javadoc] Loading source files for package org.apache.lucene.util.fst...
  [javadoc] Loading source files for package org.apache.lucene.util.mutable...
  [javadoc] Loading source files for package org.apache.lucene.util.packed...
  [javadoc] Constructing Javadoc information...
  [javadoc] Standard Doclet version 1.8.0-ea
  [javadoc] Building tree for all the packages and classes...
  [javadoc] Generating 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/docs/core/org/apache/lucene/search/package-summary.html...
  [javadoc] Copying file 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/core/src/java/org/apache/lucene/search/doc-files/nrq-formula-1.png
 to directory 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/docs/core/org/apache/lucene/search/doc-files...
  [javadoc] Copying file 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/core/src/java/org/apache/lucene/search/doc-files/nrq-formula-2.png
 to directory 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/docs/core/org/apache/lucene/search/doc-files...
  [javadoc] Building index for all the packages and classes...
  [javadoc] Building index for all classes...
  [javadoc] Generating 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/docs/core/help-doc.html...
  [javadoc] 1 warning

[...truncated 45 lines...]
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] warning: [options] bootstrap class path not set in conjunction with 
-source 1.7
  [javadoc] Loading source files for package org.apache.lucene.analysis.ar...
  [javadoc] Loading source files for package org.apache.lucene.analysis.bg...
  [javadoc] Loading source files for package org.apache.lucene.analysis.br...
  [javadoc] Loading source files for package org.apache.lucene.analysis.ca...
  [javadoc] Loading source files for package 
org.apache.lucene.analysis.charfilter...
  [javadoc] Loading source files for package org.apache.lucene.analysis.cjk...
  [javadoc] Loading source files for package 
org.apache.lucene.analysis.commongrams...
  [javadoc] Loading source files for package 
org.apache.lucene.analysis.compound...
  [javadoc] Loading source files for package 
org.apache.lucene.analysis.compound.hyphenation...
  [javadoc] Loading source files for package org.apache.lucene.analysis.core...
  [javadoc] Loading source files for package org.apache.lucene.analysis.cz...
  [javadoc] Loading source files for package org.apache.lucene.analysis.da...
  [javadoc] Loading source files for package org.apache.lucene.analysis.de...
  [javadoc] Loading source files for package org.apache.lucene.analysis.el...
  [javadoc] Loading source files for package org.apache.lucene.analysis.en...
  [javadoc] Loading source files for package org.apache.lucene.analysis.es...
  [javadoc] Loading source files for package org.apache.lucene.analysis.eu...
  [javadoc] Loading source files for package org.apache.lucene.analysis.fa...
  [javadoc] Loading source files for package org.apache.lucene.analysis.fi...
  [javadoc] Loading source files for package org.apache.lucene.analysis.fr...
  [javadoc] Loading source files for package org.apache.lucene.analysis.ga...
  [javadoc] Loading source files for package

[JENKINS] Lucene-Solr-Tests-4.x-java7 - Build # 899 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-4.x-java7/899/

All tests passed

Build Log:
[...truncated 25672 lines...]
-documentation-lint:
 [echo] checking for broken html...
[jtidy] Checking for broken html (such as invalid tags)...
   [delete] Deleting directory 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/lucene/build/jtidy_tmp
 [echo] Checking for broken links...
 [exec] 
 [exec] Crawl/parse...
 [exec] 
 [exec] Verify...
 [echo] Checking for missing docs...
 [exec] 
 [exec] 
build/docs/suggest/org/apache/lucene/search/spell/package-summary.html
 [exec]   missing: DirectSpellChecker.ScoreTerm
 [exec] 
 [exec] Missing javadocs were found!

BUILD FAILED
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/build.xml:60:
 The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/lucene/build.xml:245:
 The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/lucene/common-build.xml:1971:
 exec returned: 1

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



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

Re: problem with 'ant precommit'

[Steve Rowe]

Shai,

Uwe dealt with this exact (apparently J9-specific) issue on his Jenkins box a 
couple of months ago:



Steve
 
On Jan 16, 2013, at 12:52 AM, Shai Erera  wrote:

> I always get this error in the end:
> 
> lucene\common-build.xml:1990: javax.net.ssl.SSLKeyException: RSA premaster 
> secret error
> at com.ibm.jsse2.jb.(jb.java:22)
> at com.ibm.jsse2.lb.a(lb.java:208)
> at com.ibm.jsse2.lb.a(lb.java:459)
> at com.ibm.jsse2.kb.s(kb.java:11)
> at com.ibm.jsse2.kb.a(kb.java:394)
> at com.ibm.jsse2.SSLSocketImpl.a(SSLSocketImpl.java:44)
> at com.ibm.jsse2.SSLSocketImpl.h(SSLSocketImpl.java:496)
> at com.ibm.jsse2.SSLSocketImpl.a(SSLSocketImpl.java:528)
> at com.ibm.jsse2.SSLSocketImpl.startHandshake(SSLSocketImpl.java:505)
> at com.ibm.net.ssl.www2.protocol.https.c.afterConnect(c.java:83)
> at com.ibm.net.ssl.www2.protocol.https.d.connect(d.java:31)
> at com.ibm.net.ssl.www2.protocol.https.b.connect(b.java:31)
> at 
> org.apache.tools.ant.taskdefs.Get$GetThread.openConnection(Get.java:660)
> at org.apache.tools.ant.taskdefs.Get$GetThread.get(Get.java:579)
> at org.apache.tools.ant.taskdefs.Get$GetThread.run(Get.java:569)
> Caused by: java.security.InvalidKeyException: Illegal key size or default 
> parameters
> at javax.crypto.Cipher.a(Unknown Source)
> at javax.crypto.Cipher.a(Unknown Source)
> at javax.crypto.Cipher.a(Unknown Source)
> at javax.crypto.Cipher.init(Unknown Source)
> at com.ibm.jsse2.jb.(jb.java:105)
> ... 14 more
> 
> Anyone knows what do I need to fix in my system?
> 
> Shai


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

problem with 'ant precommit'

[Shai Erera]

I always get this error in the end:

lucene\common-build.xml:1990: javax.net.ssl.SSLKeyException: RSA premaster
secret error
at com.ibm.jsse2.jb.(jb.java:22)
at com.ibm.jsse2.lb.a(lb.java:208)
at com.ibm.jsse2.lb.a(lb.java:459)
at com.ibm.jsse2.kb.s(kb.java:11)
at com.ibm.jsse2.kb.a(kb.java:394)
at com.ibm.jsse2.SSLSocketImpl.a(SSLSocketImpl.java:44)
at com.ibm.jsse2.SSLSocketImpl.h(SSLSocketImpl.java:496)
at com.ibm.jsse2.SSLSocketImpl.a(SSLSocketImpl.java:528)
at
com.ibm.jsse2.SSLSocketImpl.startHandshake(SSLSocketImpl.java:505)
at com.ibm.net.ssl.www2.protocol.https.c.afterConnect(c.java:83)
at com.ibm.net.ssl.www2.protocol.https.d.connect(d.java:31)
at com.ibm.net.ssl.www2.protocol.https.b.connect(b.java:31)
at
org.apache.tools.ant.taskdefs.Get$GetThread.openConnection(Get.java:660)
at org.apache.tools.ant.taskdefs.Get$GetThread.get(Get.java:579)
at org.apache.tools.ant.taskdefs.Get$GetThread.run(Get.java:569)
Caused by: java.security.InvalidKeyException: Illegal key size or default
parameters
at javax.crypto.Cipher.a(Unknown Source)
at javax.crypto.Cipher.a(Unknown Source)
at javax.crypto.Cipher.a(Unknown Source)
at javax.crypto.Cipher.init(Unknown Source)
at com.ibm.jsse2.jb.(jb.java:105)
... 14 more

Anyone knows what do I need to fix in my system?

Shai

[jira] [Commented] (LUCENE-4636) Upgrade ivy for IVY-1388 - build hangs at "resolve:"

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on LUCENE-4636:
--

I filed this as an improvement, but I wonder now if it should be a bug.

> Upgrade ivy for IVY-1388 - build hangs at "resolve:"
> 
>
> Key: LUCENE-4636
> URL: https://issues.apache.org/jira/browse/LUCENE-4636
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 3.6, 4.0
>Reporter: Shawn Heisey
> Fix For: 4.2, 5.0
>
>
> For certain failures during a lucene/solr build, or if you press ctrl-c at 
> the wrong moment during the build, ivy may leave a lockfile behind.  The next 
> time you run a build, ivy will hang with "resolve:" on the screen.
> The ivy project has a fix, currently not yet released.  When it does get 
> released, the version installed by the ivy-bootstrap target needs to be 
> updated.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Re: problem with 'ant resolve'

[Shawn Heisey]

On 1/15/2013 9:30 PM, Shai Erera wrote:

thanks guys, that solved it.

Shai


On Wed, Jan 16, 2013 at 6:27 AM, Steve Rowe mailto:sar...@gmail.com>> wrote:

Hi Shai,

Nuking your ivy cache dir will probably fix the problem - by default
this is at ~/.ivy2/cache/.


There is a fix for this issue in ivy, just not released yet.  The issue 
on this side of the fence is LUCENE-4636, linked to IVY-1388.


I'm not sure what the holdup is for release of ivy 2.3.0.  According to 
jira, there are no open issues on that version, and this has been the 
case for quite some time now.


On my systems, I checked out the ivy 2.3.0 branch, built it, and have 
replaced the ivy jar in ~/.ant/lib.  I haven't had this problem in a 
while now, and I often ctrl-c a build because I've realized I forgot to 
do something.


Thanks,
Shawn


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

[jira] [Commented] (SOLR-4300) Possible race condition in CoreContainer.getCore() when lazily loading cores.

[Commit Tag Bot (JIRA)]

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

Commit Tag Bot commented on SOLR-4300:
--

[branch_4x commit] Steven Rowe
http://svn.apache.org/viewvc?view=revision&revision=1433824

SOLR-4300: In TestLazyCores, convert static field into local variable to avoid 
post-test memory retention


> Possible race condition in CoreContainer.getCore() when lazily loading cores.
> -
>
> Key: SOLR-4300
> URL: https://issues.apache.org/jira/browse/SOLR-4300
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.1, 5.0
>Reporter: Erick Erickson
>Assignee: Steve Rowe
>Priority: Blocker
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4300.patch
>
>
> Yonik pointed out in SOLR-1028 that there is a possible race condition here, 
> he's right not to my surprise. Calling it a "blocker" for now so we make a 
> decision on it rather than let it fall through the cracks. I should be able 
> to get a patch up tonight (Sunday).
> That said, there's potential here to introduce deadlocks, is it worth rushing 
> into 4.1?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4300) Possible race condition in CoreContainer.getCore() when lazily loading cores.

[Commit Tag Bot (JIRA)]

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

Commit Tag Bot commented on SOLR-4300:
--

[trunk commit] Steven Rowe
http://svn.apache.org/viewvc?view=revision&revision=1433823

SOLR-4300: In TestLazyCores, convert static field into local variable to avoid 
post-test memory retention


> Possible race condition in CoreContainer.getCore() when lazily loading cores.
> -
>
> Key: SOLR-4300
> URL: https://issues.apache.org/jira/browse/SOLR-4300
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.1, 5.0
>Reporter: Erick Erickson
>Assignee: Steve Rowe
>Priority: Blocker
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4300.patch
>
>
> Yonik pointed out in SOLR-1028 that there is a possible race condition here, 
> he's right not to my surprise. Calling it a "blocker" for now so we make a 
> decision on it rather than let it fall through the cracks. I should be able 
> to get a patch up tonight (Sunday).
> That said, there's potential here to introduce deadlocks, is it worth rushing 
> into 4.1?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Resolved] (SOLR-4300) Possible race condition in CoreContainer.getCore() when lazily loading cores.

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-4300.
--

Resolution: Fixed

Committed the above patch to TestLazyCores on trunk, branch_4x and 
lucene_solr_4_1.

> Possible race condition in CoreContainer.getCore() when lazily loading cores.
> -
>
> Key: SOLR-4300
> URL: https://issues.apache.org/jira/browse/SOLR-4300
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.1, 5.0
>Reporter: Erick Erickson
>Assignee: Steve Rowe
>Priority: Blocker
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4300.patch
>
>
> Yonik pointed out in SOLR-1028 that there is a possible race condition here, 
> he's right not to my surprise. Calling it a "blocker" for now so we make a 
> decision on it rather than let it fall through the cracks. I should be able 
> to get a patch up tonight (Sunday).
> That said, there's potential here to introduce deadlocks, is it worth rushing 
> into 4.1?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Reopened] (SOLR-4300) Possible race condition in CoreContainer.getCore() when lazily loading cores.

[Steve Rowe (JIRA)]

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

Steve Rowe reopened SOLR-4300:
--

  Assignee: Steve Rowe  (was: Erick Erickson)

Jenkins is unhappy:

{noformat}
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/92/
Java: 64bit/jdk1.7.0 -XX:+UseSerialGC

1 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
Clean up static fields (in @AfterClass?), your test seems to hang on to 
approximately 13,549,312 bytes (threshold is 10,485,760). Field reference sizes 
(counted individually):   - 14,228,288 bytes, static java.util.List 
org.apache.solr.core.TestLazyCores._theCores   - 720 bytes, private static 
java.lang.String[] org.apache.solr.core.TestLazyCores._necessaryConfs   - 280 
bytes, public static org.junit.rules.TestRule 
org.apache.solr.SolrTestCaseJ4.solrClassRules   - 240 bytes, protected static 
java.lang.String org.apache.solr.SolrTestCaseJ4.testSolrHome   - 128 bytes, 
private static java.lang.String org.apache.solr.SolrTestCaseJ4.factoryProp   - 
64 bytes, private static java.lang.String 
org.apache.solr.SolrTestCaseJ4.coreName

Stack Trace:
junit.framework.AssertionFailedError: Clean up static fields (in @AfterClass?), 
your test seems to hang on to approximately 13,549,312 bytes (threshold is 
10,485,760). Field reference sizes (counted individually):
 - 14,228,288 bytes, static java.util.List 
org.apache.solr.core.TestLazyCores._theCores
...
{noformat}

I can reproduce this on my Mac.

After applying the patch below converting the static field {{_theCores}} into a 
local variable of the only method it's used in, I was able to successfully run 
{{ant test -Dtestcase=TestLazyCores -Dtests.dups=100}}:

{code:java}
Index: solr/core/src/test/org/apache/solr/core/TestLazyCores.java
===
--- solr/core/src/test/org/apache/solr/core/TestLazyCores.java  (revision 
1433815)
+++ solr/core/src/test/org/apache/solr/core/TestLazyCores.java  (working copy)
@@ -248,10 +248,10 @@
 }
   }
 
-  static List _theCores = new ArrayList();
   // Test case for SOLR-4300
   @Test
   public void testRace() throws Exception {
+final List _theCores = new ArrayList();
 final CoreContainer cc = init();
 try {
{code}

I'll commit this shortly.

> Possible race condition in CoreContainer.getCore() when lazily loading cores.
> -
>
> Key: SOLR-4300
> URL: https://issues.apache.org/jira/browse/SOLR-4300
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.1, 5.0
>Reporter: Erick Erickson
>Assignee: Steve Rowe
>Priority: Blocker
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4300.patch
>
>
> Yonik pointed out in SOLR-1028 that there is a possible race condition here, 
> he's right not to my surprise. Calling it a "blocker" for now so we make a 
> decision on it rather than let it fall through the cracks. I should be able 
> to get a patch up tonight (Sunday).
> That said, there's potential here to introduce deadlocks, is it worth rushing 
> into 4.1?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Resolved] (SOLR-4016) Deduplication is broken by partial update

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar resolved SOLR-4016.
-

Resolution: Fixed

Fixed in 4.1 and trunk.

Thanks Joel and Yonik.

> Deduplication is broken by partial update
> -
>
> Key: SOLR-4016
> URL: https://issues.apache.org/jira/browse/SOLR-4016
> Project: Solr
>  Issue Type: Bug
>  Components: update
>Affects Versions: 4.0
> Environment: Tomcat6 / Catalina on Ubuntu 12.04 LTS
>Reporter: Joel Nothman
>Assignee: Shalin Shekhar Mangar
>  Labels: 4.0.1_Candidate
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4016-disallow-partial-update.patch, 
> SOLR-4016-disallow-partial-update.patch, SOLR-4016.patch
>
>
> The SignatureUpdateProcessorFactory used (primarily?) for deduplication does 
> not consider partial update semantics.
> The below uses the following solrconfig.xml excerpt:
> {noformat}
>  
>
>  true
>  text_hash
>  false
>  text
>  solr.processor.TextProfileSignature
>
>
>
>  
> {noformat}
> Firstly, the processor treats {noformat}{"set": "value"}{noformat} as a 
> string and hashes it, instead of the value alone:
> {noformat}
> $ curl '$URL/update?commit=true' -H 'Content-type:application/json' -d 
> '{"add":{"doc":{"id": "abcde", "text": {"set": "hello world"' && curl 
> '$URL/select?q=id:abcde'
> {"responseHeader":{"status":0,"QTime":30}}
>  name="responseHeader">01 name="params">id:abcde numFound="1" start="0">abcdehello 
> worldad48c7ad60ac22cc name="_version_">1417247434224959488
> 
> $
> $ curl '$URL/update?commit=true' -H 'Content-type:application/json' -d 
> '{"add":{"doc":{"id": "abcde", "text": "hello world"}}}' && curl 
> '$URL/select?q=id:abcde'
> {"responseHeader":{"status":0,"QTime":27}}
> 
> 
> 0 name="QTime">1 name="q">id:abcde start="0">abcdehello 
> worldb169c743d220da8d name="_version_">141724802221564
> 
> {noformat}
> Note the different text_hash value.
> Secondly, when updating a field other than those used to create the signature 
> (which I imagine is a more common use-case), the signature is recalculated 
> from no values:
> {noformat}
> $ curl '$URL/update?commit=true' -H 'Content-type:application/json' -d 
> '{"add":{"doc":{"id": "abcde", "title": {"set": "new title"' && curl 
> '$URL/select?q=id:abcde'
> {"responseHeader":{"status":0,"QTime":39}}
> 
> 
> 0 name="QTime">1 name="q">id:abcde start="0">abcdehello 
> worldnew 
> title1417248120480202752
> 
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Re: problem with 'ant resolve'

[Shai Erera]

thanks guys, that solved it.

Shai


On Wed, Jan 16, 2013 at 6:27 AM, Steve Rowe  wrote:

> Hi Shai,
>
> Nuking your ivy cache dir will probably fix the problem - by default this
> is at ~/.ivy2/cache/.
>
> Steve
>
> On Jan 15, 2013, at 11:08 PM, Shai Erera  wrote:
>
> > Hi
> >
> > I'm trying to run, unsuccessfully since last night, 'ant resolve' and
> always hitting this error:
> >
> >
> > resolve:
> > [ivy:retrieve]
> > [ivy:retrieve] :: problems summary ::
> > [ivy:retrieve]  WARNINGS
> > [ivy:retrieve]  module not found:
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
> > [ivy:retrieve]   local: tried
> > [ivy:retrieve]
>  
> C:\Users\shaie\.ivy2/local/org.eclipse.jetty/jetty-jmx/8.1.8.v20121106/ivys/ivy.xml
> > [ivy:retrieve]-- artifact
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106!jetty-jmx.jar:
> > [ivy:retrieve]
>  
> C:\Users\shaie\.ivy2/local/org.eclipse.jetty/jetty-jmx/8.1.8.v20121106/jars/jetty-jmx.jar
> > [ivy:retrieve]   shared: tried
> > [ivy:retrieve]
>  
> C:\Users\shaie\.ivy2/shared/org.eclipse.jetty/jetty-jmx/8.1.8.v20121106/ivys/ivy.xml
> > [ivy:retrieve]-- artifact
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106!jetty-jmx.jar:
> > [ivy:retrieve]
>  
> C:\Users\shaie\.ivy2/shared/org.eclipse.jetty/jetty-jmx/8.1.8.v20121106/jars/jetty-jmx.jar
> > [ivy:retrieve]   public: tried
> > [ivy:retrieve]
> http://repo1.maven.org/maven2/org/eclipse/jetty/jetty-jmx/8.1.8.v20121106/jetty-jmx-8.1.8.v20121106.pom
> > [ivy:retrieve]   sonatype-releases: tried
> > [ivy:retrieve]
> http://oss.sonatype.org/content/repositories/releases/org/eclipse/jetty/jetty-jmx/8.1.8.v20121106/jetty-jmx-8.1.8.v20121106.pom
> > [ivy:retrieve]-- artifact
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106!jetty-jmx.jar:
> > [ivy:retrieve]
> http://oss.sonatype.org/content/repositories/releases/org/eclipse/jetty/jetty-jmx/8.1.8.v20121106/jetty-jmx-8.1.8.v20121106.jar
> > [ivy:retrieve]   working-chinese-mirror: tried
> > [ivy:retrieve]
> http://mirror.netcologne.de/maven2/org/eclipse/jetty/jetty-jmx/8.1.8.v20121106/jetty-jmx-8.1.8.v20121106.pom
> > [ivy:retrieve]-- artifact
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106!jetty-jmx.jar:
> > [ivy:retrieve]
> http://mirror.netcologne.de/maven2/org/eclipse/jetty/jetty-jmx/8.1.8.v20121106/jetty-jmx-8.1.8.v20121106.jar
> > [ivy:retrieve]  ::
> > [ivy:retrieve]  ::  UNRESOLVED DEPENDENCIES ::
> > [ivy:retrieve]  ::
> > [ivy:retrieve]  :: org.eclipse.jetty#jetty-jmx;8.1.8.v20121106:
> not found
> > [ivy:retrieve]  ::
> > [ivy:retrieve]
> > [ivy:retrieve]  ERRORS
> > [ivy:retrieve]  impossible to acquire lock for
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
> > [ivy:retrieve]  impossible to acquire lock for
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
> > [ivy:retrieve]  impossible to acquire lock for
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
> > [ivy:retrieve]  impossible to acquire lock for
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
> > [ivy:retrieve]  impossible to acquire lock for
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
> > [ivy:retrieve]  impossible to acquire lock for
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
> > [ivy:retrieve]  impossible to acquire lock for
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
> > [ivy:retrieve]
> >
> > I tried to access
> http://repo1.maven.org/maven2/org/eclipse/jetty/jetty-jmx/8.1.8.v20121106/and 
> it's up, and the files don't look too big. Any ideas? Perhaps I need to
> clear something in my local Ivy?
> >
> > Shai
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: 4.1 RC plan

[Robert Muir]

Sounds great. Thanks for working toward this... Release long overdue imo
On Jan 15, 2013 6:12 PM, "Steve Rowe"  wrote:

> I've pushed most JIRAs marked with 4.1 Fix Version to 4.2.  Only one
> marked as Blocker remains: LUCENE-4134 <
> https://issues.apache.org/jira/browse/LUCENE-4134>: "modify release
> process/scripts to use svn for rc/release publishing (svnpubsub)".
>
> For most of the remaining 7 issues with 4.1 Fix Version, I've left
> comments asking the assignee about the status.  (I'm looking at you, Mark!
> :)
>
> If I've moved out an issue you really want in 4.1, please move it back and
> mark it as a Blocker.
>
> I plan on cutting an RC tomorrow at around 5:00pm US EST, assuming
> everybody's remaining 4.1 issues have been incorporated and nothing new
> comes up.
>
> Thanks,
> Steve
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: problem with 'ant resolve'

[Steve Rowe]

Hi Shai,

Nuking your ivy cache dir will probably fix the problem - by default this is at 
~/.ivy2/cache/.

Steve

On Jan 15, 2013, at 11:08 PM, Shai Erera  wrote:

> Hi
> 
> I'm trying to run, unsuccessfully since last night, 'ant resolve' and always 
> hitting this error:
> 
> 
> resolve:
> [ivy:retrieve]
> [ivy:retrieve] :: problems summary ::
> [ivy:retrieve]  WARNINGS
> [ivy:retrieve]  module not found: 
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
> [ivy:retrieve]   local: tried
> [ivy:retrieve]
> C:\Users\shaie\.ivy2/local/org.eclipse.jetty/jetty-jmx/8.1.8.v20121106/ivys/ivy.xml
> [ivy:retrieve]-- artifact 
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106!jetty-jmx.jar:
> [ivy:retrieve]
> C:\Users\shaie\.ivy2/local/org.eclipse.jetty/jetty-jmx/8.1.8.v20121106/jars/jetty-jmx.jar
> [ivy:retrieve]   shared: tried
> [ivy:retrieve]
> C:\Users\shaie\.ivy2/shared/org.eclipse.jetty/jetty-jmx/8.1.8.v20121106/ivys/ivy.xml
> [ivy:retrieve]-- artifact 
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106!jetty-jmx.jar:
> [ivy:retrieve]
> C:\Users\shaie\.ivy2/shared/org.eclipse.jetty/jetty-jmx/8.1.8.v20121106/jars/jetty-jmx.jar
> [ivy:retrieve]   public: tried
> [ivy:retrieve]
> http://repo1.maven.org/maven2/org/eclipse/jetty/jetty-jmx/8.1.8.v20121106/jetty-jmx-8.1.8.v20121106.pom
> [ivy:retrieve]   sonatype-releases: tried
> [ivy:retrieve]
> http://oss.sonatype.org/content/repositories/releases/org/eclipse/jetty/jetty-jmx/8.1.8.v20121106/jetty-jmx-8.1.8.v20121106.pom
> [ivy:retrieve]-- artifact 
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106!jetty-jmx.jar:
> [ivy:retrieve]
> http://oss.sonatype.org/content/repositories/releases/org/eclipse/jetty/jetty-jmx/8.1.8.v20121106/jetty-jmx-8.1.8.v20121106.jar
> [ivy:retrieve]   working-chinese-mirror: tried
> [ivy:retrieve]
> http://mirror.netcologne.de/maven2/org/eclipse/jetty/jetty-jmx/8.1.8.v20121106/jetty-jmx-8.1.8.v20121106.pom
> [ivy:retrieve]-- artifact 
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106!jetty-jmx.jar:
> [ivy:retrieve]
> http://mirror.netcologne.de/maven2/org/eclipse/jetty/jetty-jmx/8.1.8.v20121106/jetty-jmx-8.1.8.v20121106.jar
> [ivy:retrieve]  ::
> [ivy:retrieve]  ::  UNRESOLVED DEPENDENCIES ::
> [ivy:retrieve]  ::
> [ivy:retrieve]  :: org.eclipse.jetty#jetty-jmx;8.1.8.v20121106: not 
> found
> [ivy:retrieve]  ::
> [ivy:retrieve]
> [ivy:retrieve]  ERRORS
> [ivy:retrieve]  impossible to acquire lock for 
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
> [ivy:retrieve]  impossible to acquire lock for 
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
> [ivy:retrieve]  impossible to acquire lock for 
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
> [ivy:retrieve]  impossible to acquire lock for 
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
> [ivy:retrieve]  impossible to acquire lock for 
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
> [ivy:retrieve]  impossible to acquire lock for 
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
> [ivy:retrieve]  impossible to acquire lock for 
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
> [ivy:retrieve]
> 
> I tried to access 
> http://repo1.maven.org/maven2/org/eclipse/jetty/jetty-jmx/8.1.8.v20121106/ 
> and it's up, and the files don't look too big. Any ideas? Perhaps I need to 
> clear something in my local Ivy?
> 
> Shai


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

Re: problem with 'ant resolve'

[Robert Muir]

Currently ivy has a limited set of "LockFactory" available. Unfortunately
only none or simple. There is no "native". So short term, nuke .lck file
leftover from maybe a control-c'ed JVM! You can use fine in .ivy to locate
the offendor.
On Jan 15, 2013 8:09 PM, "Shai Erera"  wrote:

> Hi
>
> I'm trying to run, unsuccessfully since last night, 'ant resolve' and
> always hitting this error:
>
>
> resolve:
> [ivy:retrieve]
> [ivy:retrieve] :: problems summary ::
> [ivy:retrieve]  WARNINGS
> [ivy:retrieve]  module not found:
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
> [ivy:retrieve]   local: tried
> [ivy:retrieve]
> C:\Users\shaie\.ivy2/local/org.eclipse.jetty/jetty-jmx/8.1.8.v20121106/ivys/ivy.xml
> [ivy:retrieve]-- artifact
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106!jetty-jmx.jar:
> [ivy:retrieve]
> C:\Users\shaie\.ivy2/local/org.eclipse.jetty/jetty-jmx/8.1.8.v20121106/jars/jetty-jmx.jar
> [ivy:retrieve]   shared: tried
> [ivy:retrieve]
> C:\Users\shaie\.ivy2/shared/org.eclipse.jetty/jetty-jmx/8.1.8.v20121106/ivys/ivy.xml
> [ivy:retrieve]-- artifact
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106!jetty-jmx.jar:
> [ivy:retrieve]
> C:\Users\shaie\.ivy2/shared/org.eclipse.jetty/jetty-jmx/8.1.8.v20121106/jars/jetty-jmx.jar
> [ivy:retrieve]   public: tried
> [ivy:retrieve]
> http://repo1.maven.org/maven2/org/eclipse/jetty/jetty-jmx/8.1.8.v20121106/jetty-jmx-8.1.8.v20121106.pom
> [ivy:retrieve]   sonatype-releases: tried
> [ivy:retrieve]
> http://oss.sonatype.org/content/repositories/releases/org/eclipse/jetty/jetty-jmx/8.1.8.v20121106/jetty-jmx-8.1.8.v20121106.pom
> [ivy:retrieve]-- artifact
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106!jetty-jmx.jar:
> [ivy:retrieve]
> http://oss.sonatype.org/content/repositories/releases/org/eclipse/jetty/jetty-jmx/8.1.8.v20121106/jetty-jmx-8.1.8.v20121106.jar
> [ivy:retrieve]   working-chinese-mirror: tried
> [ivy:retrieve]
> http://mirror.netcologne.de/maven2/org/eclipse/jetty/jetty-jmx/8.1.8.v20121106/jetty-jmx-8.1.8.v20121106.pom
> [ivy:retrieve]-- artifact
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106!jetty-jmx.jar:
> [ivy:retrieve]
> http://mirror.netcologne.de/maven2/org/eclipse/jetty/jetty-jmx/8.1.8.v20121106/jetty-jmx-8.1.8.v20121106.jar
> [ivy:retrieve]  ::
> [ivy:retrieve]  ::  UNRESOLVED DEPENDENCIES ::
> [ivy:retrieve]  ::
> [ivy:retrieve]  :: org.eclipse.jetty#jetty-jmx;8.1.8.v20121106:
> not found
> [ivy:retrieve]  ::
> [ivy:retrieve]
> [ivy:retrieve]  ERRORS
> [ivy:retrieve]  impossible to acquire lock for
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
> [ivy:retrieve]  impossible to acquire lock for
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
> [ivy:retrieve]  impossible to acquire lock for
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
> [ivy:retrieve]  impossible to acquire lock for
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
> [ivy:retrieve]  impossible to acquire lock for
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
> [ivy:retrieve]  impossible to acquire lock for
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
> [ivy:retrieve]  impossible to acquire lock for
> org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
> [ivy:retrieve]
>
> I tried to access
> http://repo1.maven.org/maven2/org/eclipse/jetty/jetty-jmx/8.1.8.v20121106/and 
> it's up, and the files don't look too big. Any ideas? Perhaps I need to
> clear something in my local Ivy?
>
> Shai
>

problem with 'ant resolve'

[Shai Erera]

Hi

I'm trying to run, unsuccessfully since last night, 'ant resolve' and
always hitting this error:


resolve:
[ivy:retrieve]
[ivy:retrieve] :: problems summary ::
[ivy:retrieve]  WARNINGS
[ivy:retrieve]  module not found:
org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
[ivy:retrieve]   local: tried
[ivy:retrieve]
C:\Users\shaie\.ivy2/local/org.eclipse.jetty/jetty-jmx/8.1.8.v20121106/ivys/ivy.xml
[ivy:retrieve]-- artifact
org.eclipse.jetty#jetty-jmx;8.1.8.v20121106!jetty-jmx.jar:
[ivy:retrieve]
C:\Users\shaie\.ivy2/local/org.eclipse.jetty/jetty-jmx/8.1.8.v20121106/jars/jetty-jmx.jar
[ivy:retrieve]   shared: tried
[ivy:retrieve]
C:\Users\shaie\.ivy2/shared/org.eclipse.jetty/jetty-jmx/8.1.8.v20121106/ivys/ivy.xml
[ivy:retrieve]-- artifact
org.eclipse.jetty#jetty-jmx;8.1.8.v20121106!jetty-jmx.jar:
[ivy:retrieve]
C:\Users\shaie\.ivy2/shared/org.eclipse.jetty/jetty-jmx/8.1.8.v20121106/jars/jetty-jmx.jar
[ivy:retrieve]   public: tried
[ivy:retrieve]
http://repo1.maven.org/maven2/org/eclipse/jetty/jetty-jmx/8.1.8.v20121106/jetty-jmx-8.1.8.v20121106.pom
[ivy:retrieve]   sonatype-releases: tried
[ivy:retrieve]
http://oss.sonatype.org/content/repositories/releases/org/eclipse/jetty/jetty-jmx/8.1.8.v20121106/jetty-jmx-8.1.8.v20121106.pom
[ivy:retrieve]-- artifact
org.eclipse.jetty#jetty-jmx;8.1.8.v20121106!jetty-jmx.jar:
[ivy:retrieve]
http://oss.sonatype.org/content/repositories/releases/org/eclipse/jetty/jetty-jmx/8.1.8.v20121106/jetty-jmx-8.1.8.v20121106.jar
[ivy:retrieve]   working-chinese-mirror: tried
[ivy:retrieve]
http://mirror.netcologne.de/maven2/org/eclipse/jetty/jetty-jmx/8.1.8.v20121106/jetty-jmx-8.1.8.v20121106.pom
[ivy:retrieve]-- artifact
org.eclipse.jetty#jetty-jmx;8.1.8.v20121106!jetty-jmx.jar:
[ivy:retrieve]
http://mirror.netcologne.de/maven2/org/eclipse/jetty/jetty-jmx/8.1.8.v20121106/jetty-jmx-8.1.8.v20121106.jar
[ivy:retrieve]  ::
[ivy:retrieve]  ::  UNRESOLVED DEPENDENCIES ::
[ivy:retrieve]  ::
[ivy:retrieve]  :: org.eclipse.jetty#jetty-jmx;8.1.8.v20121106: not
found
[ivy:retrieve]  ::
[ivy:retrieve]
[ivy:retrieve]  ERRORS
[ivy:retrieve]  impossible to acquire lock for
org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
[ivy:retrieve]  impossible to acquire lock for
org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
[ivy:retrieve]  impossible to acquire lock for
org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
[ivy:retrieve]  impossible to acquire lock for
org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
[ivy:retrieve]  impossible to acquire lock for
org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
[ivy:retrieve]  impossible to acquire lock for
org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
[ivy:retrieve]  impossible to acquire lock for
org.eclipse.jetty#jetty-jmx;8.1.8.v20121106
[ivy:retrieve]

I tried to access
http://repo1.maven.org/maven2/org/eclipse/jetty/jetty-jmx/8.1.8.v20121106/and
it's up, and the files don't look too big. Any ideas? Perhaps I need
to
clear something in my local Ivy?

Shai

Re: default updateLog setting in Solr 4 example solrconfig.xml needs warning documentation for possible very large logs

[Yonik Seeley]

Thanks Tom,
I just updated the comments in solrconfig.xml and moved the updateLog
section right next to the autoCommit section.

-Yonik
http://lucidworks.com


On Tue, Jan 15, 2013 at 12:42 PM, Tom Burton-West  wrote:
> Hello all,
>
> We have been using Solr 4.0 for a while and suddenly we couldn't get Solr to
> come up.   As Solr was starting up it hung after opening a Searcher.  There
> wasn't anything else obvious in the logs.  Eventually we realized that the
> problem was that the updatelog was being read and that the update log
> contained the entire text of all 800,000+ books that we indexed (About
> 837GB).
>
> We looked and didn't find any obvious note in the Solr 4.0 Release notes on
> upgrading from 3.6 or any documentation in the example solrconfig.xml that
> mentioned that perhaps if you have large documents and you aren't using
> real-time get, you may want to turn this off/comment this out to avoid
> transactions logs that can exceed the size of your index.
>
> In the latest 4.0 example/solrconfig.xml (r 1433064) , updateLog is enabled
> in the default Solr updateHandler by default and the only comment is:
> 
>
>
>  Some users who are either new to Solr or upgrading from earlier versions of
> Solr may not understand whether or not they need "real-time get" and they
> may not want to delve into the details of near- realtime search or using
> Solr as an NoSQL server in order to determine whether they should comment
> out the updateLog entry.
>
> I think that either the updateLog should not be enabled by default (don't
> know the pros and cons of this), or at the very least, something should
> mention that this can lead to large transaction logs and there should be a
> pointer to some documentation that would enable the user to decide whether
> or not to enable/disable this.
>
> Is there documentation of this in some obvious place that I just missed?
>
> I did find the text below on the wiki
> http://wiki.apache.org/solr/SolrConfigXml#Update_Handler_Section, but a
> user-friendly translation would be helpful or a pointer to where someone
> could read to determine what this means would be helpful.
>
> false 
>
> I did see that several new Solr 4 users created very large logs before they
> asked the mailing list how to avoid this:
> http://lucene.472066.n3.nabble.com/Documentation-on-the-new-updateLog-transaction-log-feature-tc4000537.html#a4000538
>
> Perhaps some of the information in this thread on the mailing list might be
> added to the documentation somewhere.
>
> http://lucene.472066.n3.nabble.com/Testing-Solr4-first-impressions-and-problems-tc4013628.html#a4013814
>
> I think I almost understand the
> hard-commit/soft-commit/autocommit/opensearcher discussion in the above
> thread and it would seem that this could be put in the wiki or the comments
> in the config file as appropriate.
>
> Should I open a JIRA issue?
>
> Tom
>
>
>
> 
> Log entry.
> "Jan 14, 2013 12:40:31 PM org.apache.solr.search.SolrIndexSearcher 
> INFO: Opening Searcher@59db9f45 main
>

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

[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.7.0_10) - Build # 3799 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/3799/
Java: 64bit/jdk1.7.0_10 -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 25871 lines...]
-documentation-lint:
 [echo] checking for broken html...
[jtidy] Checking for broken html (such as invalid tags)...
   [delete] Deleting directory 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/jtidy_tmp
 [echo] Checking for broken links...
 [exec] 
 [exec] Crawl/parse...
 [exec] 
 [exec] Verify...
 [echo] Checking for missing docs...
 [exec] 
 [exec] 
build/docs/suggest/org/apache/lucene/search/spell/package-summary.html
 [exec]   missing: DirectSpellChecker.ScoreTerm
 [exec] 
 [exec] Missing javadocs were found!

BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:60: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:245: The 
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1972:
 exec returned: 1

Total time: 37 minutes 51 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Description set: Java: 64bit/jdk1.7.0_10 -XX:+UseConcMarkSweepGC
Email was triggered for: Failure
Sending email for trigger: Failure



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

Re: default updateLog setting in Solr 4 example solrconfig.xml needs warning documentation for possible very large logs

[Otis Gospodnetic]

Hi Tom,

That must have been a fun surprise!  Maybe just add info to the SolrCloud
Wiki page?

Otis
Solr & ElasticSearch Support
http://sematext.com/
On Jan 15, 2013 12:43 PM, "Tom Burton-West"  wrote:

> Hello all,
>
> We have been using Solr 4.0 for a while and suddenly we couldn't get Solr
> to come up.   As Solr was starting up it hung after opening a Searcher.
>  There wasn't anything else obvious in the logs.  Eventually we realized
> that the problem was that the updatelog was being read and that the update
> log contained the entire text of all 800,000+ books that we indexed (About
> 837GB).
>
> We looked and didn't find any obvious note in the Solr 4.0 Release notes
> on upgrading from 3.6 or any documentation in the example solrconfig.xml
> that mentioned that perhaps if you have large documents and you aren't
> using real-time get, you may want to turn this off/comment this out to
> avoid transactions logs that can exceed the size of your index.
>
> In the latest 4.0 example/solrconfig.xml (r 
> *1433064)
> , updateLog is enabled in the default Solr updateHandler by default and the
> only comment is:*
> *
> 
> *
>
>
>  Some users who are either new to Solr or upgrading from earlier versions
> of Solr may not understand whether or not they need "real-time get" and
> they may not want to delve into the details of near- realtime search or
> using Solr as an NoSQL server in order to determine whether they should
> comment out the updateLog entry.
>
> I think that either the updateLog should not be enabled by default (don't
> know the pros and cons of this), or at the very least, something should
> mention that this can lead to large transaction logs and there should be a
> pointer to some documentation that would enable the user to decide whether
> or not to enable/disable this.
>
> Is there documentation of this in some obvious place that I just missed?
>
> I did find the text below on the wiki
> http://wiki.apache.org/solr/SolrConfigXml#Update_Handler_Section, but a
> user-friendly translation would be helpful or a pointer to where someone
> could read to determine what this means would be helpful.
>
> false 
>
> I did see that several new Solr 4 users created very large logs before
> they asked the mailing list how to avoid this:
>
> http://lucene.472066.n3.nabble.com/Documentation-on-the-new-updateLog-transaction-log-feature-tc4000537.html#a4000538
>
> Perhaps some of the information in this thread on the mailing list might
> be added to the documentation somewhere.
>
> http://lucene.472066.n3.nabble.com/Testing-Solr4-first-impressions-and-problems-tc4013628.html#a4013814
>
> I think I almost understand the
> hard-commit/soft-commit/autocommit/opensearcher discussion in the above
> thread and it would seem that this could be put in the wiki or the comments
> in the config file as appropriate.
>
> Should I open a JIRA issue?
>
> Tom
>
>
>
> 
> Log entry.
> "Jan 14, 2013 12:40:31 PM org.apache.solr.search.SolrIndexSearcher 
> INFO: Opening Searcher@59db9f45 main
>
>

[JENKINS] Lucene-Solr-4.x-Windows (64bit/jdk1.7.0_10) - Build # 2399 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Windows/2399/
Java: 64bit/jdk1.7.0_10 -XX:+UseParallelGC

All tests passed

Build Log:
[...truncated 25677 lines...]
-documentation-lint:
 [echo] checking for broken html...
[jtidy] Checking for broken html (such as invalid tags)...
   [delete] Deleting directory 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build\jtidy_tmp
 [echo] Checking for broken links...
 [exec] 
 [exec] Crawl/parse...
 [exec] 
 [exec] Verify...
 [echo] Checking for missing docs...
 [exec] 
 [exec] 
build/docs\suggest\org\apache\lucene\search\spell/package-summary.html
 [exec]   missing: DirectSpellChecker.ScoreTerm
 [exec] 
 [exec] Missing javadocs were found!

BUILD FAILED
C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\build.xml:60: The 
following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build.xml:245: 
The following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\common-build.xml:1971:
 exec returned: 1

Total time: 63 minutes 46 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Description set: Java: 64bit/jdk1.7.0_10 -XX:+UseParallelGC
Email was triggered for: Failure
Sending email for trigger: Failure



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

Re: 4.1 RC plan

[Steve Rowe]

FYI, here is a JIRA filter for unresolved 4.1 issues:



On Jan 15, 2013, at 9:12 PM, Steve Rowe  wrote:

> I've pushed most JIRAs marked with 4.1 Fix Version to 4.2.  Only one marked 
> as Blocker remains: LUCENE-4134 
> : "modify release 
> process/scripts to use svn for rc/release publishing (svnpubsub)".
> 
> For most of the remaining 7 issues with 4.1 Fix Version, I've left comments 
> asking the assignee about the status.  (I'm looking at you, Mark! :)
> 
> If I've moved out an issue you really want in 4.1, please move it back and 
> mark it as a Blocker.
> 
> I plan on cutting an RC tomorrow at around 5:00pm US EST, assuming 
> everybody's remaining 4.1 issues have been incorporated and nothing new comes 
> up.
> 
> Thanks,
> Steve
> 


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

4.1 RC plan

[Steve Rowe]

I've pushed most JIRAs marked with 4.1 Fix Version to 4.2.  Only one marked as 
Blocker remains: LUCENE-4134 
: "modify release 
process/scripts to use svn for rc/release publishing (svnpubsub)".

For most of the remaining 7 issues with 4.1 Fix Version, I've left comments 
asking the assignee about the status.  (I'm looking at you, Mark! :)

If I've moved out an issue you really want in 4.1, please move it back and mark 
it as a Blocker.

I plan on cutting an RC tomorrow at around 5:00pm US EST, assuming everybody's 
remaining 4.1 issues have been incorporated and nothing new comes up.

Thanks,
Steve


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

[jira] [Updated] (SOLR-3926) solrj should support better way of finding active sorts

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-3926:
-

Fix Version/s: (was: 4.1)
   4.2

> solrj should support better way of finding active sorts
> ---
>
> Key: SOLR-3926
> URL: https://issues.apache.org/jira/browse/SOLR-3926
> Project: Solr
>  Issue Type: Improvement
>  Components: clients - java
>Affects Versions: 4.0
>Reporter: Eirik Lygre
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 4.2
>
> Attachments: SOLR-3926.patch, SOLR-3926.patch, SOLR-3926.patch, 
> SOLR-3926.patch
>
>
> The Solrj api uses ortogonal concepts for setting/removing and getting sort 
> information. Setting/removing uses a combination of (name,order), while 
> getters return a String "name order":
> {code}
> public SolrQuery setSortField(String field, ORDER order);
> public SolrQuery addSortField(String field, ORDER order);
> public SolrQuery removeSortField(String field, ORDER order);
> public String[] getSortFields();
> public String getSortField();
> {code}
> If you want to use the current sort information to present a list of active 
> sorts, with the possibility to remove then, you need to manually parse the 
> string(s) returned from getSortFields, to recreate the information required 
> by removeSortField(). Not difficult, but not convenient either :-)
> Therefore this suggestion: Add a new method {{public Map 
> getSortFieldMap();}} which returns an ordered map of active sort fields. This 
> will make introspection of the current sort setup much easier.
> {code}
>   public Map getSortFieldMap() {
> String[] actualSortFields = getSortFields();
> if (actualSortFields == null || actualSortFields.length == 0)
>   return Collections.emptyMap();
> Map sortFieldMap = new LinkedHashMap();
> for (String sortField : actualSortFields) {
>   String[] fieldSpec = sortField.trim().split(" ");
>   sortFieldMap.put(fieldSpec[0], ORDER.valueOf(fieldSpec[1]));
> }
> return Collections.unmodifiableMap(sortFieldMap);
>   }
> {code}
> For what it's worth, this is possible client code:
> {code}
> System.out.println("Active sorts");
> Map fieldMap = getSortFieldMap(query);
> for (String field : fieldMap.keySet()) {
>System.out.println("- " + field + "; dir=" + fieldMap.get(field));
> }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4300) Possible race condition in CoreContainer.getCore() when lazily loading cores.

[Commit Tag Bot (JIRA)]

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

Commit Tag Bot commented on SOLR-4300:
--

[branch_4x commit] Erick Erickson
http://svn.apache.org/viewvc?view=revision&revision=1433790

fix for SOLR-4300, race condition when loading lazy cores from multiple threads


> Possible race condition in CoreContainer.getCore() when lazily loading cores.
> -
>
> Key: SOLR-4300
> URL: https://issues.apache.org/jira/browse/SOLR-4300
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.1, 5.0
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Blocker
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4300.patch
>
>
> Yonik pointed out in SOLR-1028 that there is a possible race condition here, 
> he's right not to my surprise. Calling it a "blocker" for now so we make a 
> decision on it rather than let it fall through the cracks. I should be able 
> to get a patch up tonight (Sunday).
> That said, there's potential here to introduce deadlocks, is it worth rushing 
> into 4.1?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Resolved] (SOLR-4300) Possible race condition in CoreContainer.getCore() when lazily loading cores.

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-4300.
--

   Resolution: Fixed
Fix Version/s: 5.0
   4.1

trunk: r - 1433778
4.x:   r - 1433790
4.1:   r - 1433787

> Possible race condition in CoreContainer.getCore() when lazily loading cores.
> -
>
> Key: SOLR-4300
> URL: https://issues.apache.org/jira/browse/SOLR-4300
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.1, 5.0
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Blocker
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4300.patch
>
>
> Yonik pointed out in SOLR-1028 that there is a possible race condition here, 
> he's right not to my surprise. Calling it a "blocker" for now so we make a 
> decision on it rather than let it fall through the cracks. I should be able 
> to get a patch up tonight (Sunday).
> That said, there's potential here to introduce deadlocks, is it worth rushing 
> into 4.1?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Re: 4.1 release

[Steve Rowe]

Thanks Jack, I committed Simon's patch on the 4.1 branch just now. - Steve

On Jan 15, 2013, at 6:13 PM, Jack Krupansky  wrote:

> I saw the branch_4x commit go by for this, but I believe it was AFTER the 4.1 
> branch was made.
> 
> So, is it okay that 4.1 does not have this fix?
> 
> But this is just a test change, anyway.
> 
> -- Jack Krupansky
> 
> -Original Message- From: Robert Muir
> Sent: Friday, January 11, 2013 7:52 AM
> To: dev@lucene.apache.org
> Subject: Re: 4.1 release
> 
> I'd also like for Simon to have a chance to look at this bug:
> https://issues.apache.org/jira/browse/LUCENE-4676
> 
> I know he isnt back until next week...
> 
> On Fri, Jan 11, 2013 at 7:50 AM, Erick Erickson  
> wrote:
>> P.S. Let's give dedicated souls the weekend to get stuff in for 4.1 if they
>> want and cut the first RC early next week
>> 
>> 
>> On Fri, Jan 11, 2013 at 7:48 AM, Erick Erickson 
>> wrote:
>>> 
>>> I'll take are of SOLR-4112 this morning, probably create another JIRA to
>>> track unit tests. There aren't any today and I have evidence from the field
>>> that it makes DIH usable so
>>> 
>>> Erick
>>> 
>>> 
>>> On Thu, Jan 10, 2013 at 5:58 PM, Jack Krupansky 
>>> wrote:
 
 The window of Monday through Wednesday sounds like a great target.
 Nothing says that the first RC has to be final. If whoever is doing the
 branch wants to do it on Monday rather than Tuesday, fine. If one or more 
 of
 these nasty "blockers" gets fixed on Tuesday, we should still be open to a
 re-spin to put quality over a mere day or two of delay. But draw a hard 
 line
 on Wednesday.
 
 -- Jack Krupansky
 
 -Original Message- From: Mark Miller
 Sent: Thursday, January 10, 2013 3:36 PM
 To: dev@lucene.apache.org
 Subject: Re: 4.1 release
 
 
 Saying tomorrow without any date that gives anyone any time to do
 anything is out of nowhere to me. People in Europe and east of that will
 wake up and find out, oh today. While pressure has been building towards a
 release, no one has proposed a date for a cutoff. I think that is always
 only fair. I think that if you were desperate to cut off to blockers
 tomorrow, you should have called for that last week.
 
 Robert Muir's short term releases are not threatened by allowing people
 to plan and execute a release together. You can take that too far and do
 damage from the opposite direction. Giving people time to tie things up 
 with
 a real deadline is only fair. We all know a nebulous deadline is not
 conducive to finishing up work.
 
 I think all releases should have a known date that we agree on that gives
 developers some time to finish what they are working on or what they 
 believe
 is important for the release. At a minimum there should be a few days for
 this. A weekend involved only seems fair. This doesn't have to be a long
 time, but it should not require we file blockers and just seems like a
 friendly way to develop together.
 
 Monday is fine by me if others buy into it.
 
 Otherwise, we have taken 4 or 5 months for 4.1. Let's not drag it out
 another month. But let's not do the reverse and release it tonight. The
 sensible approach always seems like we should plan out some target dates on
 the list - dates that actually give devs a chance to respond to - and then
 follow through on those dates.
 
 - Mark
 
 On Jan 10, 2013, at 3:26 PM, Steve Rowe  wrote:
 
> Okay - I can see your logic, Mark, but this is not even close to out of
> nowhere.  You yourself have been vocal about making a 4.1 release for a
> couple weeks now.
> 
> I agree with Robert Muir that we should be promoting short turnaround
> releases.  If it doesn't make this release, it'll make the next one, which
> will come out in a relatively short span of time.  In this model, Blocker
> issues are the drivers, not "Fix Version".If people want stuff in the
> release, they should mark their issue as Blocker.
> 
> How about a compromise - next Monday we branch and only allow Blockers
> to block the release?
> 
> Steve
> 
> On Jan 10, 2013, at 3:08 PM, Mark Miller  wrote:
> 
>> -1 from me - I don't like not giving people a target date to clean
>> things up by. No one has given a proposed date to try and tie things up 
>> by -
>> just calling 'hike is tomorrow' out of nowhere doesn't seem right to me.
>> 
>> We have a lot of people working on this over a lot of timezones. I
>> think we should do the right thing and give everyone at least a few days 
>> and
>> a weekend to finish getting their issues into 4.1.
>> 
>> - Mark
>> 
>> On Jan 10, 2013, at 2:36 PM, Steve Rowe  wrote:
>> 
>>> I'd like to start sooner than next Tuesday.
>>> 
>>> I propose to make th

[jira] [Commented] (SOLR-4300) Possible race condition in CoreContainer.getCore() when lazily loading cores.

[Commit Tag Bot (JIRA)]

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

Commit Tag Bot commented on SOLR-4300:
--

[trunk commit] Erick Erickson
http://svn.apache.org/viewvc?view=revision&revision=1433778

Fix for SOLR-4300, possible race condition when loading lazy cores


> Possible race condition in CoreContainer.getCore() when lazily loading cores.
> -
>
> Key: SOLR-4300
> URL: https://issues.apache.org/jira/browse/SOLR-4300
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.1, 5.0
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Blocker
> Attachments: SOLR-4300.patch
>
>
> Yonik pointed out in SOLR-1028 that there is a possible race condition here, 
> he's right not to my surprise. Calling it a "blocker" for now so we make a 
> decision on it rather than let it fall through the cracks. I should be able 
> to get a patch up tonight (Sunday).
> That said, there's potential here to introduce deadlocks, is it worth rushing 
> into 4.1?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[JENKINS-MAVEN] Lucene-Solr-Maven-trunk #739: POMs out of sync

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/739/

1 tests failed.
REGRESSION:  org.apache.solr.cloud.SyncSliceTest.testDistribSearch

Error Message:
shard1 should have just been set up to be inconsistent - but it's still 
consistent

Stack Trace:
java.lang.AssertionError: shard1 should have just been set up to be 
inconsistent - but it's still consistent
at 
__randomizedtesting.SeedInfo.seed([26223C01D538027D:A7C4B219A2676241]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at org.apache.solr.cloud.SyncSliceTest.doTest(SyncSliceTest.java:214)
at 
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:794)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
 

[jira] [Updated] (SOLR-4061) CREATE action in Collections API should allow to upload a new configuration

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-4061:
-

Fix Version/s: (was: 4.1)
   4.2

bq. FYI, I don't have more than what I uploaded in the patch. This still 
doesn't upload local configuration, at least from my side.

Okay, Tomás, so this isn't going to make it into 4.1 - pushing to 4.2.

> CREATE action in Collections API should allow to upload a new configuration
> ---
>
> Key: SOLR-4061
> URL: https://issues.apache.org/jira/browse/SOLR-4061
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Tomás Fernández Löbbe
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4061.patch
>
>
> When creating new collections with the Collection API, the only option is to 
> point to an existing configuration in ZK. It would be nice to be able to 
> upload a new configuration in the same command. 
> For more details see 
> http://lucene.472066.n3.nabble.com/Error-with-SolrCloud-td4019351.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (LUCENE-4491) Make analyzing suggester more flexible

[Steve Rowe (JIRA)]

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

Steve Rowe updated LUCENE-4491:
---

Affects Version/s: (was: 4.2)
   4.1
Fix Version/s: (was: 4.1)
   4.2

> Make analyzing suggester more flexible
> --
>
> Key: LUCENE-4491
> URL: https://issues.apache.org/jira/browse/LUCENE-4491
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/other
>Affects Versions: 4.1
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: 4.2, 5.0
>
> Attachments: LUCENE-4491.patch, LUCENE-4491.patch
>
>
> Today we have a analyzing suggester that is bound to a single key. Yet, if 
> you want to have a totally different surface form compared to the key used to 
> find the suggestion you either have to copy the code or play some super ugly 
> analyzer tricks. For example I want to suggest "Barbar Streisand" if somebody 
> types "strei" in that case the surface form is totally different from the 
> analyzed form. 
> Even one step further I want to embed some meta-data in the suggested key 
> like a user id or some type my surface form could look like "Barbar 
> Streisand|15". Ideally I want to encode this as binary and that might not be 
> a valid UTF-8 byte sequence.
> I'm actually doing this in production and my only option was to copy the 
> analyzing suggester and some of it's related classes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4234) Add support for binary files in ZooKeeper.

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-4234:
--

Mark, Erik, Eric: can we push this to 4.2?

> Add support for binary files in ZooKeeper.
> --
>
> Key: SOLR-4234
> URL: https://issues.apache.org/jira/browse/SOLR-4234
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.0
>Reporter: Eric Pugh
>Assignee: Mark Miller
> Fix For: 4.1, 5.0
>
> Attachments: binary_upload_download.patch, 
> fix_show_file_handler_with_binaries.patch, SOLR4234_binary_files.patch, 
> solr.png
>
>
> I was attempting to get the ShowFileHandler to show a .png file, and it was 
> failing.  But in non-ZK mode it worked just fine!   It took a while, but it 
> seems that we upload to zk as a text, and download as well.  I've attached a 
> unit test that demonstrates the problem, and a fix.  You have to have a 
> binary file in the conf directory to make the test work, I put solr.png in 
> the collection1/conf/velocity directory.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4016) Deduplication is broken by partial update

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-4016:
--

Shalin, this can be resolved as fixed, right?

> Deduplication is broken by partial update
> -
>
> Key: SOLR-4016
> URL: https://issues.apache.org/jira/browse/SOLR-4016
> Project: Solr
>  Issue Type: Bug
>  Components: update
>Affects Versions: 4.0
> Environment: Tomcat6 / Catalina on Ubuntu 12.04 LTS
>Reporter: Joel Nothman
>Assignee: Shalin Shekhar Mangar
>  Labels: 4.0.1_Candidate
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4016-disallow-partial-update.patch, 
> SOLR-4016-disallow-partial-update.patch, SOLR-4016.patch
>
>
> The SignatureUpdateProcessorFactory used (primarily?) for deduplication does 
> not consider partial update semantics.
> The below uses the following solrconfig.xml excerpt:
> {noformat}
>  
>
>  true
>  text_hash
>  false
>  text
>  solr.processor.TextProfileSignature
>
>
>
>  
> {noformat}
> Firstly, the processor treats {noformat}{"set": "value"}{noformat} as a 
> string and hashes it, instead of the value alone:
> {noformat}
> $ curl '$URL/update?commit=true' -H 'Content-type:application/json' -d 
> '{"add":{"doc":{"id": "abcde", "text": {"set": "hello world"' && curl 
> '$URL/select?q=id:abcde'
> {"responseHeader":{"status":0,"QTime":30}}
>  name="responseHeader">01 name="params">id:abcde numFound="1" start="0">abcdehello 
> worldad48c7ad60ac22cc name="_version_">1417247434224959488
> 
> $
> $ curl '$URL/update?commit=true' -H 'Content-type:application/json' -d 
> '{"add":{"doc":{"id": "abcde", "text": "hello world"}}}' && curl 
> '$URL/select?q=id:abcde'
> {"responseHeader":{"status":0,"QTime":27}}
> 
> 
> 0 name="QTime">1 name="q">id:abcde start="0">abcdehello 
> worldb169c743d220da8d name="_version_">141724802221564
> 
> {noformat}
> Note the different text_hash value.
> Secondly, when updating a field other than those used to create the signature 
> (which I imagine is a more common use-case), the signature is recalculated 
> from no values:
> {noformat}
> $ curl '$URL/update?commit=true' -H 'Content-type:application/json' -d 
> '{"add":{"doc":{"id": "abcde", "title": {"set": "new title"' && curl 
> '$URL/select?q=id:abcde'
> {"responseHeader":{"status":0,"QTime":39}}
> 
> 
> 0 name="QTime">1 name="q">id:abcde start="0">abcdehello 
> worldnew 
> title1417248120480202752
> 
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-3118) We need a better error message when failing due to a slice that is part of collection is not available

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-3118:
---

If I can get to it tonight - at least the one error message.

> We need a better error message when failing due to a slice that is part of 
> collection is not available
> --
>
> Key: SOLR-3118
> URL: https://issues.apache.org/jira/browse/SOLR-3118
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 4.0-ALPHA
>Reporter: Sami Siren
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-3118.patch
>
>
> When indexing to/searching from an incomplete collection (for example a slice 
> does not have any shards registered/available) a cruel error without a proper 
> explanation is shown to the user. These errors are from running example1.sh 
> and creating a new collection with coreadminhandler:
> Slices with no shards:
> Indexing:
> {code}
> Error 500 No registered leader was found, collection:collection2 slice:shard4
> java.lang.RuntimeException: No registered leader was found, 
> collection:collection2 slice:shard4
>   at 
> org.apache.solr.common.cloud.ZkStateReader.getLeaderProps(ZkStateReader.java:408)
>   at 
> org.apache.solr.common.cloud.ZkStateReader.getLeaderProps(ZkStateReader.java:393)
>   at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.setupRequest(DistributedUpdateProcessor.java:154)
>   at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:210)
>   at 
> org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:115)
>   at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:135)
>   at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:79)
>   at 
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:59)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1523)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:339)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:234)
>   at 
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
>   at 
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
>   at 
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
>   at 
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
>   at 
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
>   at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
>   at 
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
>   at 
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
>   at 
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>   at org.mortbay.jetty.Server.handle(Server.java:326)
>   at 
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
>   at 
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:945)
>   at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756)
>   at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
>   at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
>   at 
> org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
>   at 
> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
> {code}
> Searching:
> {code}
> HTTP ERROR 503
> Problem accessing /solr/coreX/select/. Reason:
> no servers hosting shard: 
> Powered by Jetty://
> {code}
> Surprisingly the error is different when searching from a collection after 
> removing a core from an collection that was in OK condition:
> {code}
> HTTP ERROR 500
> Problem accessing /solr/coreX/select/. Reason:
> null
> java.util.concurrent.RejectedExecutionException
>   at 
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1768)
>   at 
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)
>   at 
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)
>   at 
> java.util.concurrent.ExecutorCompletionService.submit(ExecutorCompletionService.java:152)
>   at 
> org.apache.solr.handler.component.H

[jira] [Updated] (SOLR-4043) Add ability to get success/failure responses from Collections API.

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-4043:
-

Fix Version/s: (was: 4.1)
   4.2

> Add ability to get success/failure responses from Collections API.
> --
>
> Key: SOLR-4043
> URL: https://issues.apache.org/jira/browse/SOLR-4043
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0
> Environment: Solr cloud cluster
>Reporter: Raintung Li
>Assignee: Mark Miller
> Fix For: 4.2, 5.0
>
> Attachments: patch-4043.txt, SOLR-4043_brach4.x.txt, SOLR-4043.patch
>
>
> The create/delete/reload collections are asynchronous process, the client 
> can't get the right response, only make sure the information have been saved 
> into the OverseerCollectionQueue. The client will get the response directly 
> that don't wait the result of behavior(create/delete/reload collection) 
> whatever successful. 
> The easy solution is client wait until the asynchronous process success, the 
> create/delete/reload collection thread will save the response into 
> OverseerCollectionQueue, then notify client to get the response. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (LUCENE-4417) Re-Add the backwards compatibility tests to 4.1 branch

[Steve Rowe (JIRA)]

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

Steve Rowe updated LUCENE-4417:
---

 Priority: Major  (was: Blocker)
Fix Version/s: (was: 4.1)
   4.2

Blocker->Major, Fix Version -> 4.2

> Re-Add the backwards compatibility tests to 4.1 branch
> --
>
> Key: LUCENE-4417
> URL: https://issues.apache.org/jira/browse/LUCENE-4417
> Project: Lucene - Core
>  Issue Type: Task
>  Components: general/test
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: 4.2
>
>
> In 4.0 we have no backwards compatibility, but in 4.1 we must again 
> ivy-retrieve the 4.0 JAR file and run the core tests again (like in 3.6). We 
> may think about other modules, too, so all modules that must be backwards 
> compatible should be added to this build.
> I will work on this once we have a release candidate in Maven Central.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (LUCENE-4246) Fix IndexWriter.close() to not commit or wait for pending merges

[Steve Rowe (JIRA)]

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

Steve Rowe updated LUCENE-4246:
---

Fix Version/s: (was: 4.1)
   4.2

> Fix IndexWriter.close() to not commit or wait for pending merges
> 
>
> Key: LUCENE-4246
> URL: https://issues.apache.org/jira/browse/LUCENE-4246
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Robert Muir
> Fix For: 4.2
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4165) Queries blocked when stopping and starting a node

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-4165:
--

Mark, can this be resolved as a duplicate of SOLR-3655?

> Queries blocked when stopping and starting a node
> -
>
> Key: SOLR-4165
> URL: https://issues.apache.org/jira/browse/SOLR-4165
> Project: Solr
>  Issue Type: Bug
>  Components: search, SolrCloud
>Affects Versions: 5.0
> Environment: 5.0-SNAPSHOT 1366361:1420056M - markus - 2012-12-11 
> 11:52:06
>Reporter: Markus Jelsma
>Assignee: Mark Miller
>Priority: Critical
> Fix For: 4.1, 5.0
>
>
> Our 10 node test cluster (10 shards, 20 cores) blocks incoming queries 
> briefly when a node is stopped gracefully and again blocks queries for at 
> least a few seconds when the node is started again.
> We're using siege to send roughly 10 queries per second to a pair a load 
> balancers. Those load balancers ping (admin/ping) each node every few hundres 
> milliseconds. The ping queries continue to operate normally while the 
> requests to our main request handler is blocked. A manual request directly to 
> a live Solr node is also blocked for the same duration.
> There are no errors logged. But it is clear that the the entire cluster 
> blocks queries as soon as the starting node is reading its config from 
> Zookeeper, likely even slightly earlier.
> The blocking time when stopping a node varies between 1 or 5 seconds. The 
> blocking time when starting a node varies between 10 up to 30 seconds. The 
> blocked queries come rushing in again after a queue of ping requests are 
> served. The ping request sets the main request handler via the qt parameter.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-3491) PeerSync & SyncStrategy use an HttpShardHandlerFactory that they never close

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-3491:
-

Fix Version/s: (was: 4.1)
   4.2

> PeerSync & SyncStrategy use an HttpShardHandlerFactory that they never close
> 
>
> Key: SOLR-3491
> URL: https://issues.apache.org/jira/browse/SOLR-3491
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Yonik Seeley
> Fix For: 4.2, 5.0
>
>
> Discovered while making sense of SOLR-3423...
> * PeerSync & SyncStrategy each use their own private instance of 
> HttpShardHandlerFactory, which are never close()ed (so the threadpool is 
> never closed)
> * should these classes be using the ShardHandler configured on the SolrCore

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Resolved] (LUCENE-4431) License of servlet-api.jar is NOT ASF, it is CDDL! We must fix and add NOTICE.txt

[Steve Rowe (JIRA)]

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

Steve Rowe resolved LUCENE-4431.


Resolution: Fixed

Committed to {{branches/lucene_solr_3_6/}}.

> License of servlet-api.jar is NOT ASF, it is CDDL! We must fix and add 
> NOTICE.txt
> -
>
> Key: LUCENE-4431
> URL: https://issues.apache.org/jira/browse/LUCENE-4431
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/other
>Affects Versions: 3.6.1, 4.0-BETA
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 4.1, 5.0, 3.6.3, 4.0
>
> Attachments: LUCENE-4431.lucene_solr_3_6.patch, LUCENE-4431.patch, 
> LUCENE-4431.patch, LUCENE-4431.patch
>
>
> - The demo module has sevlet-api.jar with a ASF-named license file and the 
> text "TODO: fill in"
> - This also affects Solr: It has a full ASF license file, but that is wrong.
> The servlet-apoi file is CDDL license: 
> http://download.oracle.com/otndocs/jcp/servlet-3.0-fr-eval-oth-JSpec/ (same 
> for 2.4). The 3.0.1 JAR file also contains License in its META-INF folder.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-2649) MM ignored in edismax queries with operators

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-2649:


The 3.5 schema also contains this: 

That has been removed from the 4.1 schema, q.op in solrconfig.xml is used 
instead.


> MM ignored in edismax queries with operators
> 
>
> Key: SOLR-2649
> URL: https://issues.apache.org/jira/browse/SOLR-2649
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Reporter: Magnus Bergmark
>Priority: Minor
> Fix For: 4.2, 5.0
>
>
> Hypothetical scenario:
>   1. User searches for "stocks oil gold" with MM set to "50%"
>   2. User adds "-stockings" to the query: "stocks oil gold -stockings"
>   3. User gets no hits since MM was ignored and all terms where AND-ed 
> together
> The behavior seems to be intentional, although the reason why is never 
> explained:
>   // For correct lucene queries, turn off mm processing if there
>   // were explicit operators (except for AND).
>   boolean doMinMatched = (numOR + numNOT + numPluses + numMinuses) == 0; 
> (lines 232-234 taken from 
> tags/lucene_solr_3_3/solr/src/java/org/apache/solr/search/ExtendedDismaxQParserPlugin.java)
> This makes edismax unsuitable as an replacement to dismax; mm is one of the 
> primary features of dismax.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (LUCENE-4431) License of servlet-api.jar is NOT ASF, it is CDDL! We must fix and add NOTICE.txt

[Steve Rowe (JIRA)]

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

Steve Rowe updated LUCENE-4431:
---

Attachment: LUCENE-4431.lucene_solr_3_6.patch

Patch for the 3.6 branch.  Only Solr changes are included, since Lucene doesn't 
have include servlet-api.jar in this branch.

Committing shortly.

> License of servlet-api.jar is NOT ASF, it is CDDL! We must fix and add 
> NOTICE.txt
> -
>
> Key: LUCENE-4431
> URL: https://issues.apache.org/jira/browse/LUCENE-4431
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/other
>Affects Versions: 3.6.1, 4.0-BETA
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 4.0, 4.1, 5.0, 3.6.3
>
> Attachments: LUCENE-4431.lucene_solr_3_6.patch, LUCENE-4431.patch, 
> LUCENE-4431.patch, LUCENE-4431.patch
>
>
> - The demo module has sevlet-api.jar with a ASF-named license file and the 
> text "TODO: fill in"
> - This also affects Solr: It has a full ASF license file, but that is wrong.
> The servlet-apoi file is CDDL license: 
> http://download.oracle.com/otndocs/jcp/servlet-3.0-fr-eval-oth-JSpec/ (same 
> for 2.4). The 3.0.1 JAR file also contains License in its META-INF folder.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Re: 4.1 release

[Jack Krupansky]

I saw the branch_4x commit go by for this, but I believe it was AFTER the 
4.1 branch was made.


So, is it okay that 4.1 does not have this fix?

But this is just a test change, anyway.

-- Jack Krupansky

-Original Message- 
From: Robert Muir

Sent: Friday, January 11, 2013 7:52 AM
To: dev@lucene.apache.org
Subject: Re: 4.1 release

I'd also like for Simon to have a chance to look at this bug:
https://issues.apache.org/jira/browse/LUCENE-4676

I know he isnt back until next week...

On Fri, Jan 11, 2013 at 7:50 AM, Erick Erickson  
wrote:
P.S. Let's give dedicated souls the weekend to get stuff in for 4.1 if 
they

want and cut the first RC early next week


On Fri, Jan 11, 2013 at 7:48 AM, Erick Erickson 
wrote:


I'll take are of SOLR-4112 this morning, probably create another JIRA to
track unit tests. There aren't any today and I have evidence from the 
field

that it makes DIH usable so

Erick


On Thu, Jan 10, 2013 at 5:58 PM, Jack Krupansky 
wrote:


The window of Monday through Wednesday sounds like a great target.
Nothing says that the first RC has to be final. If whoever is doing the
branch wants to do it on Monday rather than Tuesday, fine. If one or 
more of
these nasty "blockers" gets fixed on Tuesday, we should still be open to 
a
re-spin to put quality over a mere day or two of delay. But draw a hard 
line

on Wednesday.

-- Jack Krupansky

-Original Message- From: Mark Miller
Sent: Thursday, January 10, 2013 3:36 PM
To: dev@lucene.apache.org
Subject: Re: 4.1 release


Saying tomorrow without any date that gives anyone any time to do
anything is out of nowhere to me. People in Europe and east of that will
wake up and find out, oh today. While pressure has been building towards 
a

release, no one has proposed a date for a cutoff. I think that is always
only fair. I think that if you were desperate to cut off to blockers
tomorrow, you should have called for that last week.

Robert Muir's short term releases are not threatened by allowing people
to plan and execute a release together. You can take that too far and do
damage from the opposite direction. Giving people time to tie things up 
with

a real deadline is only fair. We all know a nebulous deadline is not
conducive to finishing up work.

I think all releases should have a known date that we agree on that 
gives
developers some time to finish what they are working on or what they 
believe
is important for the release. At a minimum there should be a few days 
for

this. A weekend involved only seems fair. This doesn't have to be a long
time, but it should not require we file blockers and just seems like a
friendly way to develop together.

Monday is fine by me if others buy into it.

Otherwise, we have taken 4 or 5 months for 4.1. Let's not drag it out
another month. But let's not do the reverse and release it tonight. The
sensible approach always seems like we should plan out some target dates 
on
the list - dates that actually give devs a chance to respond to - and 
then

follow through on those dates.

- Mark

On Jan 10, 2013, at 3:26 PM, Steve Rowe  wrote:


Okay - I can see your logic, Mark, but this is not even close to out of
nowhere.  You yourself have been vocal about making a 4.1 release for a
couple weeks now.

I agree with Robert Muir that we should be promoting short turnaround
releases.  If it doesn't make this release, it'll make the next one, 
which
will come out in a relatively short span of time.  In this model, 
Blocker
issues are the drivers, not "Fix Version".If people want stuff in 
the

release, they should mark their issue as Blocker.

How about a compromise - next Monday we branch and only allow Blockers
to block the release?

Steve

On Jan 10, 2013, at 3:08 PM, Mark Miller  wrote:


-1 from me - I don't like not giving people a target date to clean
things up by. No one has given a proposed date to try and tie things 
up by -
just calling 'hike is tomorrow' out of nowhere doesn't seem right to 
me.


We have a lot of people working on this over a lot of timezones. I
think we should do the right thing and give everyone at least a few 
days and

a weekend to finish getting their issues into 4.1.

- Mark

On Jan 10, 2013, at 2:36 PM, Steve Rowe  wrote:


I'd like to start sooner than next Tuesday.

I propose to make the branch tomorrow, and only allow Blocker issues
to hold up the release after that.

A release candidate should then be possible by the middle of next
week.

Steve

On Jan 10, 2013, at 2:27 PM, Mark Miller 
wrote:



On Jan 10, 2013, at 2:12 PM, Steve Rowe  wrote:


I'd like to release soon.  What else blocks this?



I think we should toss out a short term date (next tuesday?) for
anyone to get in what they need for 4.1.

Then just consider blockers after branching?

Then release?

Objections, better ideas?

I think we should give a bit of time for people to finish up what's
in flight or fix any blockers. Then we should heighten testing and 
allow for
any new blockers, and 

[jira] [Commented] (SOLR-2649) MM ignored in edismax queries with operators

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-2649:


Just ran into this (or something like it) on both my production 3.5 and dev 4.1 
servers.

What I see happening with edismax queries that contain operators is this: Both 
mm (100%) and q.op (AND) are ignored so that it acts as if q.op were OR.  
Instead of 8k results, there are over 300k.  With a sort parameter, most of the 
results actually seen are invalid.  Here is an actual query from my log:

(  (young man close up NOT woman NOT couple))


> MM ignored in edismax queries with operators
> 
>
> Key: SOLR-2649
> URL: https://issues.apache.org/jira/browse/SOLR-2649
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Reporter: Magnus Bergmark
>Priority: Minor
> Fix For: 4.2, 5.0
>
>
> Hypothetical scenario:
>   1. User searches for "stocks oil gold" with MM set to "50%"
>   2. User adds "-stockings" to the query: "stocks oil gold -stockings"
>   3. User gets no hits since MM was ignored and all terms where AND-ed 
> together
> The behavior seems to be intentional, although the reason why is never 
> explained:
>   // For correct lucene queries, turn off mm processing if there
>   // were explicit operators (except for AND).
>   boolean doMinMatched = (numOR + numNOT + numPluses + numMinuses) == 0; 
> (lines 232-234 taken from 
> tags/lucene_solr_3_3/solr/src/java/org/apache/solr/search/ExtendedDismaxQParserPlugin.java)
> This makes edismax unsuitable as an replacement to dismax; mm is one of the 
> primary features of dismax.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Resolved] (SOLR-1972) Need additional query stats in admin interface - median, 95th and 99th percentile

[Alan Woodward (JIRA)]

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

Alan Woodward resolved SOLR-1972.
-

Resolution: Fixed

> Need additional query stats in admin interface - median, 95th and 99th 
> percentile
> -
>
> Key: SOLR-1972
> URL: https://issues.apache.org/jira/browse/SOLR-1972
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 1.4
>Reporter: Shawn Heisey
>Assignee: Alan Woodward
>Priority: Minor
> Fix For: 4.1, 5.0
>
> Attachments: elyograg-1972-3.2.patch, elyograg-1972-3.2.patch, 
> elyograg-1972-trunk.patch, elyograg-1972-trunk.patch, 
> elyograg-closeable.patch, leak-closeable.patch, leak.patch, 
> revert-SOLR-1972.patch, SOLR-1972-branch3x-url_pattern.patch, 
> SOLR-1972-branch4x.patch, SOLR-1972-branch4x.patch, 
> SOLR-1972_forked-metrics.patch, SOLR-1972_forked-metrics.patch, 
> SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, 
> SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, 
> SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, 
> solr1972-metricsregistry-branch4x-failure.log, SOLR-1972.patch, 
> SOLR-1972.patch, SOLR-1972.patch, SOLR-1972.patch, 
> SOLR-1972-url_pattern.patch, stacktraces.tar.gz
>
>
> I would like to see more detailed query statistics from the admin GUI.  This 
> is what you can get now:
> requests : 809
> errors : 0
> timeouts : 0
> totalTime : 70053
> avgTimePerRequest : 86.59209
> avgRequestsPerSecond : 0.8148785 
> I'd like to see more data on the time per request - median, 95th percentile, 
> 99th percentile, and any other statistical function that makes sense to 
> include.  In my environment, the first bunch of queries after startup tend to 
> take several seconds each.  I find that the average value tends to be useless 
> until it has several thousand queries under its belt and the caches are 
> thoroughly warmed.  The statistical functions I have mentioned would quickly 
> eliminate the influence of those initial slow queries.
> The system will have to store individual data about each query.  I don't know 
> if this is something Solr does already.  It would be nice to have a 
> configurable count of how many of the most recent data points are kept, to 
> control the amount of memory the feature uses.  The default value could be 
> something like 1024 or 4096.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4256) The example for solr.TypeTokenFilterFactory uses wrong case for useWhitelist parameter - breaks examples

[Commit Tag Bot (JIRA)]

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

Commit Tag Bot commented on SOLR-4256:
--

[branch_4x commit] Steven Rowe
http://svn.apache.org/viewvc?view=revision&revision=1433664

SOLR-4256: Fix parameter name in javadocs (useWhiteList->useWhitelist) (merged 
trunk r1433660)


> The example for solr.TypeTokenFilterFactory uses wrong case for useWhitelist 
> parameter - breaks examples
> 
>
> Key: SOLR-4256
> URL: https://issues.apache.org/jira/browse/SOLR-4256
> Project: Solr
>  Issue Type: Task
>  Components: documentation, Schema and Analysis
>Affects Versions: 4.0
>Reporter: Alexandre Rafalovitch
>Priority: Trivial
>  Labels: documentation
> Fix For: 4.0.1, 4.1
>
>
> In SOLR-3092, solr.TypeTokenFilterFactory from Lucene has been exposed. One 
> of the parameter documented is useWhiteList. However the code uses 
> useWhitelist instead (small 'l'). This makes the examples using the boolean 
> property set to true not work. 
> The documentation and code need to match. It would be also good to include at 
> least a basic description of this in the Wiki.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4288) FileDataSource with an empty basePath and a relative resource is broken.

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-4288:
-

Fix Version/s: (was: 4.1)
   4.2

> FileDataSource with an empty basePath and a relative resource is broken.
> 
>
> Key: SOLR-4288
> URL: https://issues.apache.org/jira/browse/SOLR-4288
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.0
>Reporter: Dawid Weiss
>Priority: Minor
> Fix For: 4.2, 5.0
>
>
> In fact, the logic is broken:
> {code}
>   if (!file.isAbsolute())
> file = new File(basePath + query);
> {code}
> because basePath is null so 'null' is concatenated with the query string 
> (path) resulting in an invalid path. 
> It should be checked if basePath is null, if so default to "."? Then resolve 
> relative location as:
> {code}
> new File(basePathFile, query);
> {code}
> I'd also say change the log so that the absolute path is also logged in the 
> warning message, otherwise it's really hard to figure out what's going on.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4038) SolrCloud indexing blocks if shard is marked as DOWN

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-4038:
--

Mark, can this issue be resolved now?

> SolrCloud indexing blocks if shard is marked as DOWN
> 
>
> Key: SOLR-4038
> URL: https://issues.apache.org/jira/browse/SOLR-4038
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.0
>Reporter: Markus Jelsma
>Assignee: Mark Miller
> Fix For: 4.1, 5.0
>
>
> See: 
> http://lucene.472066.n3.nabble.com/SolrCloud-indexing-blocks-if-node-is-recovering-td4017827.html
> While indexing (without CloudSolrServer at that time) one node dies with an 
> OOME perhaps  because of the linked issue SOLR-4032. The OOME stack traces 
> are varied but here are some ZK-related logs between the OOME stack traces:
> {code}
> 2012-11-02 14:14:37,126 INFO [solr.update.UpdateLog] - [RecoveryThread] - : 
> Dropping buffered updates FSUpdateLog{state=BUFFERING, tlog=null}
> 2012-11-02 14:14:37,127 ERROR [solr.cloud.RecoveryStrategy] - 
> [RecoveryThread] - : Recovery failed - trying again... (2) core=shard_e
> 2012-11-02 14:14:37,127 INFO [solr.cloud.RecoveryStrategy] - [RecoveryThread] 
> - : Wait 8.0 seconds before trying to recover again (3)
> 2012-11-02 14:14:45,328 INFO [solr.cloud.ZkController] - [RecoveryThread] - : 
> numShards not found on descriptor - reading it from system property
> 2012-11-02 14:14:45,363 INFO [solr.cloud.RecoveryStrategy] - [RecoveryThread] 
> - : Starting Replication Recovery. core=shard_e
> 2012-11-02 14:14:45,363 INFO [solrj.impl.HttpClientUtil] - [RecoveryThread] - 
> : Creating new http client, 
> config:maxConnections=128&maxConnectionsPerHost=32&followRedirects=false
> 2012-11-02 14:14:45,775 INFO [common.cloud.ZkStateReader] - 
> [main-EventThread] - : A cluster state change has occurred - updating... (10)
> 2012-11-02 14:14:50,987 INFO [solr.cloud.RecoveryStrategy] - [RecoveryThread] 
> - : Begin buffering updates. core=shard_e
> 2012-11-02 14:14:50,987 INFO [solr.update.UpdateLog] - [RecoveryThread] - : 
> Starting to buffer updates. FSUpdateLog{state=ACTIVE, tlog=null}
> 2012-11-02 14:14:50,987 INFO [solr.cloud.RecoveryStrategy] - [RecoveryThread] 
> - : Attempting to replicate from http://rot05.solrserver:8080/solr/shard_e/. 
> core=shard_e
> 2012-11-02 14:14:50,987 INFO [solrj.impl.HttpClientUtil] - [RecoveryThread] - 
> : Creating new http client, 
> config:maxConnections=128&maxConnectionsPerHost=32&followRedirects=false
> 2012-11-02 14:15:03,303 INFO [solr.core.CachingDirectoryFactory] - 
> [RecoveryThread] - : Releasing directory:/opt/solr/cores/shard_f/data/index
> 2012-11-02 14:15:03,303 INFO [solr.handler.SnapPuller] - [RecoveryThread] - : 
> removing temporary index download directory files 
> NRTCachingDirectory(org.apache.lucene.store.MMapDirectory@/opt/solr/cores/shard_f/data/index.20121102141424591
>  lockFactory=org.apache.lucene.store.SimpleFSLockFactory@1520a48c; 
> maxCacheMB=48.0 maxMergeSizeMB=4.0)
> 2012-11-02 14:15:09,421 INFO [apache.zookeeper.ClientCnxn] - 
> [main-SendThread(rot1.zkserver:2181)] - : Client session timed out, have not 
> heard from server in 11873ms for sessionid 0x13abc504486000f, closing socket 
> connection and attempting reconnect
> 2012-11-02 14:15:09,422 ERROR [solr.core.SolrCore] - [http-8080-exec-1] - : 
> org.apache.solr.common.SolrException: Ping query caused exception: Java heap 
> space
> .
> .
> 2012-11-02 14:15:09,867 INFO [common.cloud.ConnectionManager] - 
> [main-EventThread] - : Watcher 
> org.apache.solr.common.cloud.ConnectionManager@305e7020 
> name:ZooKeeperConnection Watcher:rot1.zkserver:2181,rot2.zkserver:2181 got 
> event WatchedEvent state:Disconnected type:None path:null path:null type:None
> 2012-11-02 14:15:09,867 INFO [common.cloud.ConnectionManager] - 
> [main-EventThread] - : zkClient has disconnected
> 2012-11-02 14:15:09,869 ERROR [solr.cloud.RecoveryStrategy] - 
> [RecoveryThread] - : Error while trying to 
> recover:java.lang.OutOfMemoryError: Java heap space
> .
> .
> 2012-11-02 14:15:10,159 INFO [solr.update.UpdateLog] - [RecoveryThread] - : 
> Dropping buffered updates FSUpdateLog{state=BUFFERING, tlog=null}
> 2012-11-02 14:15:10,159 ERROR [solr.cloud.RecoveryStrategy] - 
> [RecoveryThread] - : Recovery failed - trying again... (3) core=shard_e
> 2012-11-02 14:15:10,159 INFO [solr.cloud.RecoveryStrategy] - [RecoveryThread] 
> - : Wait 16.0 seconds before trying to recover again (4)
> 2012-11-02 14:15:09,878 INFO [solr.core.CachingDirectoryFactory] - 
> [RecoveryThread] - : Releasing 
> directory:/opt/solr/cores/shard_f/data/index.20121102141424591
> 2012-11-02 14:15:10,192 INFO [solr.core.CachingDirectoryFactory] - 
> [Reco

[jira] [Commented] (SOLR-1972) Need additional query stats in admin interface - median, 95th and 99th percentile

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-1972:
--

Alan, can this be resolved as fixed now?

> Need additional query stats in admin interface - median, 95th and 99th 
> percentile
> -
>
> Key: SOLR-1972
> URL: https://issues.apache.org/jira/browse/SOLR-1972
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 1.4
>Reporter: Shawn Heisey
>Assignee: Alan Woodward
>Priority: Minor
> Fix For: 4.1, 5.0
>
> Attachments: elyograg-1972-3.2.patch, elyograg-1972-3.2.patch, 
> elyograg-1972-trunk.patch, elyograg-1972-trunk.patch, 
> elyograg-closeable.patch, leak-closeable.patch, leak.patch, 
> revert-SOLR-1972.patch, SOLR-1972-branch3x-url_pattern.patch, 
> SOLR-1972-branch4x.patch, SOLR-1972-branch4x.patch, 
> SOLR-1972_forked-metrics.patch, SOLR-1972_forked-metrics.patch, 
> SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, 
> SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, 
> SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, 
> solr1972-metricsregistry-branch4x-failure.log, SOLR-1972.patch, 
> SOLR-1972.patch, SOLR-1972.patch, SOLR-1972.patch, 
> SOLR-1972-url_pattern.patch, stacktraces.tar.gz
>
>
> I would like to see more detailed query statistics from the admin GUI.  This 
> is what you can get now:
> requests : 809
> errors : 0
> timeouts : 0
> totalTime : 70053
> avgTimePerRequest : 86.59209
> avgRequestsPerSecond : 0.8148785 
> I'd like to see more data on the time per request - median, 95th percentile, 
> 99th percentile, and any other statistical function that makes sense to 
> include.  In my environment, the first bunch of queries after startup tend to 
> take several seconds each.  I find that the average value tends to be useless 
> until it has several thousand queries under its belt and the caches are 
> thoroughly warmed.  The statistical functions I have mentioned would quickly 
> eliminate the influence of those initial slow queries.
> The system will have to store individual data about each query.  I don't know 
> if this is something Solr does already.  It would be nice to have a 
> configurable count of how many of the most recent data points are kept, to 
> control the amount of memory the feature uses.  The default value could be 
> something like 1024 or 4096.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-3180) ChaosMonkey test failures

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-3180:
-

Fix Version/s: (was: 4.1)
   4.2

> ChaosMonkey test failures
> -
>
> Key: SOLR-3180
> URL: https://issues.apache.org/jira/browse/SOLR-3180
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 4.2, 5.0
>
> Attachments: CMSL_fail1.log, CMSL_hang_2.txt, CMSL_hang.txt, 
> fail.130101_034142.txt, fail.130102_020942.txt, fail.130103_105104.txt, 
> fail.130103_193722.txt, fail.inconsistent.txt, test_report_1.txt
>
>
> Handle intermittent failures in the ChaosMonkey tests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4266) HttpSolrServer does not release connection properly on exception when no response parser is used

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-4266:
--

Mark, should we push to 4.2?

> HttpSolrServer does not release connection properly on exception when no 
> response parser is used
> 
>
> Key: SOLR-4266
> URL: https://issues.apache.org/jira/browse/SOLR-4266
> Project: Solr
>  Issue Type: Bug
>  Components: clients - java
>Affects Versions: 4.0
>Reporter: Steve Molloy
>Assignee: Mark Miller
> Fix For: 4.1, 5.0
>
> Attachments: patch-4266.txt
>
>
> When using HttpSolrServer for requests with no response parser, any 
> unpredicted status code (401, 500...) will throw the exception properly, but 
> will not close the connection. Since no handle for connection is returned in 
> case of exception, it should be closed. So only case where it should not be 
> closed is when the stream is actually returned, that is, when no response 
> parser is used and the call is successful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4256) The example for solr.TypeTokenFilterFactory uses wrong case for useWhitelist parameter - breaks examples

[Commit Tag Bot (JIRA)]

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

Commit Tag Bot commented on SOLR-4256:
--

[trunk commit] Steven Rowe
http://svn.apache.org/viewvc?view=revision&revision=1433660

SOLR-4256: Fix parameter name in javadocs ("useWhiteList"->"useWhitelist")


> The example for solr.TypeTokenFilterFactory uses wrong case for useWhitelist 
> parameter - breaks examples
> 
>
> Key: SOLR-4256
> URL: https://issues.apache.org/jira/browse/SOLR-4256
> Project: Solr
>  Issue Type: Task
>  Components: documentation, Schema and Analysis
>Affects Versions: 4.0
>Reporter: Alexandre Rafalovitch
>Priority: Trivial
>  Labels: documentation
> Fix For: 4.0.1, 4.1
>
>
> In SOLR-3092, solr.TypeTokenFilterFactory from Lucene has been exposed. One 
> of the parameter documented is useWhiteList. However the code uses 
> useWhitelist instead (small 'l'). This makes the examples using the boolean 
> property set to true not work. 
> The documentation and code need to match. It would be also good to include at 
> least a basic description of this in the Wiki.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4259) Carrot2 dependency should be declared on the mini version, not the core

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-4259:
-

Fix Version/s: (was: 4.1)
   4.2

> Carrot2 dependency should be declared on the mini version, not the core
> ---
>
> Key: SOLR-4259
> URL: https://issues.apache.org/jira/browse/SOLR-4259
> Project: Solr
>  Issue Type: Improvement
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: 4.2, 5.0
>
>
> Check why we depend on the full core POM anyway; the mini version should be 
> enough for algorithms (we wouldn't need so many exclusions then).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4061) CREATE action in Collections API should allow to upload a new configuration

[JIRA]

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

Tomás Fernández Löbbe commented on SOLR-4061:
-

FYI, I don't have more than what I uploaded in the patch. This still doesn't 
upload local configuration, at least from my side.

> CREATE action in Collections API should allow to upload a new configuration
> ---
>
> Key: SOLR-4061
> URL: https://issues.apache.org/jira/browse/SOLR-4061
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Tomás Fernández Löbbe
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4061.patch
>
>
> When creating new collections with the Collection API, the only option is to 
> point to an existing configuration in ZK. It would be nice to be able to 
> upload a new configuration in the same command. 
> For more details see 
> http://lucene.472066.n3.nabble.com/Error-with-SolrCloud-td4019351.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (LUCENE-4599) Compressed term vectors

[Steve Rowe (JIRA)]

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

Steve Rowe updated LUCENE-4599:
---

Fix Version/s: (was: 4.1)
   4.2

> Compressed term vectors
> ---
>
> Key: LUCENE-4599
> URL: https://issues.apache.org/jira/browse/LUCENE-4599
> Project: Lucene - Core
>  Issue Type: Task
>  Components: core/codecs, core/termvectors
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 4.2
>
> Attachments: LUCENE-4599.patch, LUCENE-4599.patch
>
>
> We should have codec-compressed term vectors similarly to what we have with 
> stored fields.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Resolved] (SOLR-4256) The example for solr.TypeTokenFilterFactory uses wrong case for useWhitelist parameter - breaks examples

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-4256.
--

Resolution: Fixed

Committed to trunk, branch_4x and lucene_solr_4_1.

Thanks Alexandre!

> The example for solr.TypeTokenFilterFactory uses wrong case for useWhitelist 
> parameter - breaks examples
> 
>
> Key: SOLR-4256
> URL: https://issues.apache.org/jira/browse/SOLR-4256
> Project: Solr
>  Issue Type: Task
>  Components: documentation, Schema and Analysis
>Affects Versions: 4.0
>Reporter: Alexandre Rafalovitch
>Priority: Trivial
>  Labels: documentation
> Fix For: 4.0.1, 4.1
>
>
> In SOLR-3092, solr.TypeTokenFilterFactory from Lucene has been exposed. One 
> of the parameter documented is useWhiteList. However the code uses 
> useWhitelist instead (small 'l'). This makes the examples using the boolean 
> property set to true not work. 
> The documentation and code need to match. It would be also good to include at 
> least a basic description of this in the Wiki.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (LUCENE-4654) Test duration statistics from multiple test runs should be reused (locally).

[Steve Rowe (JIRA)]

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

Steve Rowe updated LUCENE-4654:
---

Fix Version/s: (was: 4.1)
   4.2

> Test duration statistics from multiple test runs should be reused (locally).
> 
>
> Key: LUCENE-4654
> URL: https://issues.apache.org/jira/browse/LUCENE-4654
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 4.2, 5.0
>
>
> This is trivial to accomplish: when somebody (or jenkins) runs tests multiple 
> times the execution statistics could be reused to improve load balancing on 
> the local machine (local hardware and settings) in favor of the precached 
> values currently version in the svn repo.
> At this moment we already do this, but keep the stats under build/ and every 
> ant clean effectively removes them. I could move those stats under an 
> svn-ignored folder elsewhere so that these stats are not lost and reused for 
> balancing.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Resolved] (SOLR-3961) LimitTokenCountFilterFactory config parsing is totally broken

[Hoss Man (JIRA)]

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

Hoss Man resolved SOLR-3961.


   Resolution: Fixed
Fix Version/s: (was: 4.0.1)

> LimitTokenCountFilterFactory config parsing is totally broken
> -
>
> Key: SOLR-3961
> URL: https://issues.apache.org/jira/browse/SOLR-3961
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.0
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-3961.patch, SOLR-3961.patch
>
>
> As noted on the mailing list, LimitTokenCountFilterFactory throws a 
> NumberFormatException because it tries to use the value of it's config param 
> as a key to look up another param that it parses as an integer ... totally 
> ridiculous.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4465) ConstantScoreQuery's scorer does not return child scorers

[Commit Tag Bot (JIRA)]

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

Commit Tag Bot commented on LUCENE-4465:


[branch_4x commit] Uwe Schindler
http://svn.apache.org/viewvc?view=revision&revision=1433653

Merged revision(s) 1433652 from lucene/dev/trunk:
LUCENE-4465: Let ConstantScoreQuery's Scorer return its child scorer.


> ConstantScoreQuery's scorer does not return child scorers
> -
>
> Key: LUCENE-4465
> URL: https://issues.apache.org/jira/browse/LUCENE-4465
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 4.0-BETA
>Reporter: selckin
>Assignee: Uwe Schindler
> Fix For: 4.1, 5.0
>
> Attachments: constant-score-children.patch
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4061) CREATE action in Collections API should allow to upload a new configuration

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-4061:
--

Mark, a couple of weeks ago you retargeted this for 4.1 - should it instead be 
pushed to 4.2?



> CREATE action in Collections API should allow to upload a new configuration
> ---
>
> Key: SOLR-4061
> URL: https://issues.apache.org/jira/browse/SOLR-4061
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Tomás Fernández Löbbe
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4061.patch
>
>
> When creating new collections with the Collection API, the only option is to 
> point to an existing configuration in ZK. It would be nice to be able to 
> upload a new configuration in the same command. 
> For more details see 
> http://lucene.472066.n3.nabble.com/Error-with-SolrCloud-td4019351.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Resolved] (LUCENE-4465) ConstantScoreQuery's scorer does not return child scorers

[Uwe Schindler (JIRA)]

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

Uwe Schindler resolved LUCENE-4465.
---

Resolution: Fixed

Committed to trunk, 4.x and the new 4.1 branch. Thanks selckin!

> ConstantScoreQuery's scorer does not return child scorers
> -
>
> Key: LUCENE-4465
> URL: https://issues.apache.org/jira/browse/LUCENE-4465
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 4.0-BETA
>Reporter: selckin
>Assignee: Uwe Schindler
> Fix For: 4.1, 5.0
>
> Attachments: constant-score-children.patch
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4196) Untangle XML-specific nature of Config and Container classes

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-4196:
-

Fix Version/s: (was: 4.1)
   4.2

> Untangle XML-specific nature of Config and Container classes
> 
>
> Key: SOLR-4196
> URL: https://issues.apache.org/jira/browse/SOLR-4196
> Project: Solr
>  Issue Type: Improvement
>  Components: Schema and Analysis
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch, 
> SOLR-4196.patch
>
>
> sub-task for SOLR-4083. If we're going to try to obsolete solr.xml, we need 
> to pull all of the specific XML processing out of Config and Container. 
> Currently, we refer to xpaths all over the place. This JIRA is about 
> providing a thunking layer to isolate the XML-esque nature of solr.xml and 
> allow a simple properties file to be used instead which will lead, 
> eventually, to solr.xml going away.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (LUCENE-3581) IndexReader#isCurrent() should return true on a NRT reader if no deletes are applied and only deletes are present in IW

[Steve Rowe (JIRA)]

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

Steve Rowe updated LUCENE-3581:
---

Fix Version/s: (was: 4.1)
   4.2

> IndexReader#isCurrent() should return true on a NRT reader if no deletes are 
> applied and only deletes are present in IW
> ---
>
> Key: LUCENE-3581
> URL: https://issues.apache.org/jira/browse/LUCENE-3581
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 3.5, 4.0-ALPHA
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: 4.2
>
>
> I keep forgetting about this, I better open an issue. If you have a NRT 
> reader without deletes applied it should infact return true on IR#isCurrent() 
> if the IW only has deletes in its buffer ie. no documents where updated / 
> added since the NRT reader was opened. Currently if there is a delete coming 
> in we force a reopen which does nothing since deletes are not applied anyway.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4465) ConstantScoreQuery's scorer does not return child scorers

[Commit Tag Bot (JIRA)]

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

Commit Tag Bot commented on LUCENE-4465:


[trunk commit] Uwe Schindler
http://svn.apache.org/viewvc?view=revision&revision=1433652

LUCENE-4465: Let ConstantScoreQuery's Scorer return its child scorer.


> ConstantScoreQuery's scorer does not return child scorers
> -
>
> Key: LUCENE-4465
> URL: https://issues.apache.org/jira/browse/LUCENE-4465
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 4.0-BETA
>Reporter: selckin
>Assignee: Uwe Schindler
> Fix For: 4.1, 5.0
>
> Attachments: constant-score-children.patch
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (LUCENE-3109) Rename FieldsConsumer to InvertedFieldsConsumer

[Steve Rowe (JIRA)]

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

Steve Rowe updated LUCENE-3109:
---

Fix Version/s: (was: 4.1)
   4.2

> Rename FieldsConsumer to InvertedFieldsConsumer
> ---
>
> Key: LUCENE-3109
> URL: https://issues.apache.org/jira/browse/LUCENE-3109
> Project: Lucene - Core
>  Issue Type: Task
>  Components: core/codecs
>Affects Versions: 4.0-ALPHA
>Reporter: Simon Willnauer
>Assignee: Michael McCandless
>Priority: Minor
> Fix For: 4.2
>
> Attachments: LUCENE-3109.patch, LUCENE-3109.patch, LUCENE-3109.patch, 
> LUCENE-3109.patch, LUCENE-3109.patch, LUCENE-3109.patch
>
>
> The name FieldsConsumer is missleading here it really is an 
> InvertedFieldsConsumer and since we are extending codecs to consume 
> non-inverted Fields we should be clear here. Same applies to Fields.java as 
> well as FieldsProducer.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-3507) Refactor parts of solr doing inter node communication to use shardhandlerfactory/shardhandler

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-3507:
-

Fix Version/s: (was: 4.1)
   4.2

> Refactor parts of solr doing inter node communication to use 
> shardhandlerfactory/shardhandler
> -
>
> Key: SOLR-3507
> URL: https://issues.apache.org/jira/browse/SOLR-3507
> Project: Solr
>  Issue Type: Improvement
>Reporter: Sami Siren
>Assignee: Sami Siren
>Priority: Minor
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-3507.patch, SOLR-3507.patch, SOLR-3507.patch
>
>
> Sequal to SOLR-3480, the aim is to change most (all?) parts of solr that need 
> to talk to different nodes to use ShardHandlerFacory from corecontainer.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-3854) SolrCloud does not work with https

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-3854:
-

Fix Version/s: (was: 4.1)
   4.2

> SolrCloud does not work with https
> --
>
> Key: SOLR-3854
> URL: https://issues.apache.org/jira/browse/SOLR-3854
> Project: Solr
>  Issue Type: Bug
>Reporter: Sami Siren
>Assignee: Sami Siren
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-3854.patch, SOLR-3854.patch
>
>
> There are a few places in current codebase that assume http is used. This 
> prevents using https when running solr in cloud mode.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-3118) We need a better error message when failing due to a slice that is part of collection is not available

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-3118:
--

Mark, do you plan on getting this into 4.1?

> We need a better error message when failing due to a slice that is part of 
> collection is not available
> --
>
> Key: SOLR-3118
> URL: https://issues.apache.org/jira/browse/SOLR-3118
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 4.0-ALPHA
>Reporter: Sami Siren
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-3118.patch
>
>
> When indexing to/searching from an incomplete collection (for example a slice 
> does not have any shards registered/available) a cruel error without a proper 
> explanation is shown to the user. These errors are from running example1.sh 
> and creating a new collection with coreadminhandler:
> Slices with no shards:
> Indexing:
> {code}
> Error 500 No registered leader was found, collection:collection2 slice:shard4
> java.lang.RuntimeException: No registered leader was found, 
> collection:collection2 slice:shard4
>   at 
> org.apache.solr.common.cloud.ZkStateReader.getLeaderProps(ZkStateReader.java:408)
>   at 
> org.apache.solr.common.cloud.ZkStateReader.getLeaderProps(ZkStateReader.java:393)
>   at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.setupRequest(DistributedUpdateProcessor.java:154)
>   at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:210)
>   at 
> org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:115)
>   at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:135)
>   at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:79)
>   at 
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:59)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1523)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:339)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:234)
>   at 
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
>   at 
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
>   at 
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
>   at 
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
>   at 
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
>   at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
>   at 
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
>   at 
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
>   at 
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>   at org.mortbay.jetty.Server.handle(Server.java:326)
>   at 
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
>   at 
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:945)
>   at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756)
>   at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
>   at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
>   at 
> org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
>   at 
> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
> {code}
> Searching:
> {code}
> HTTP ERROR 503
> Problem accessing /solr/coreX/select/. Reason:
> no servers hosting shard: 
> Powered by Jetty://
> {code}
> Surprisingly the error is different when searching from a collection after 
> removing a core from an collection that was in OK condition:
> {code}
> HTTP ERROR 500
> Problem accessing /solr/coreX/select/. Reason:
> null
> java.util.concurrent.RejectedExecutionException
>   at 
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1768)
>   at 
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)
>   at 
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)
>   at 
> java.util.concurrent.ExecutorCompletionService.submit(ExecutorCompletionService.java:152)
>   at 
> org.apache.solr.handler.component.HttpShardHandler.sub

[jira] [Updated] (SOLR-3393) Implement an optimized LFUCache

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-3393:
-

Fix Version/s: (was: 4.1)
   4.2

> Implement an optimized LFUCache
> ---
>
> Key: SOLR-3393
> URL: https://issues.apache.org/jira/browse/SOLR-3393
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Affects Versions: 3.6, 4.0-ALPHA
>Reporter: Shawn Heisey
>Assignee: Hoss Man
>Priority: Minor
> Fix For: 4.2
>
> Attachments: SOLR-3393-4x-withdecay.patch, SOLR-3393.patch, 
> SOLR-3393.patch, SOLR-3393.patch, SOLR-3393.patch, SOLR-3393.patch, 
> SOLR-3393.patch, SOLR-3393.patch, SOLR-3393-trunk-withdecay.patch
>
>
> SOLR-2906 gave us an inefficient LFU cache modeled on 
> FastLRUCache/ConcurrentLRUCache.  It could use some serious improvement.  The 
> following project includes an Apache 2.0 licensed O(1) implementation.  The 
> second link is the paper (PDF warning) it was based on:
> https://github.com/chirino/hawtdb
> http://dhruvbird.com/lfu.pdf
> Using this project and paper, I will attempt to make a new O(1) cache called 
> FastLFUCache that is modeled on LRUCache.java.  This will (for now) leave the 
> existing LFUCache/ConcurrentLFUCache implementation in place.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Resolved] (LUCENE-3343) Comparison operators >,>=,<,<= and = support as RangeQuery syntax in QueryParser

[Steve Rowe (JIRA)]

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

Steve Rowe resolved LUCENE-3343.


   Resolution: Fixed
Fix Version/s: (was: 4.1)
   4.0

Resolving as fixed.

This was committed to 4.0, and had remained open in order to backport to 3.6, 
but because this is a new feature, and the 3.6 branch is open only for 
bugfixes, it will never be released in any 3.6.X version.

> Comparison operators >,>=,<,<= and = support as RangeQuery syntax in 
> QueryParser
> 
>
> Key: LUCENE-3343
> URL: https://issues.apache.org/jira/browse/LUCENE-3343
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/queryparser
>Reporter: Olivier Favre
>Assignee: Adriano Crestani
>Priority: Minor
>  Labels: parser, query
> Fix For: 4.0
>
> Attachments: NumCompQueryParser-3x.patch, NumCompQueryParser.patch
>
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> To offer better interoperability with other search engines and to provide an 
> easier and more straight forward syntax,
> the operators >, >=, <, <= and = should be available to express an open range 
> query.
> They should at least work for numeric queries.
> '=' can be made a synonym for ':'.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-3926) solrj should support better way of finding active sorts

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-3926:
--

Erick, should this be pushed to 4.2?

> solrj should support better way of finding active sorts
> ---
>
> Key: SOLR-3926
> URL: https://issues.apache.org/jira/browse/SOLR-3926
> Project: Solr
>  Issue Type: Improvement
>  Components: clients - java
>Affects Versions: 4.0
>Reporter: Eirik Lygre
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 4.1
>
> Attachments: SOLR-3926.patch, SOLR-3926.patch, SOLR-3926.patch, 
> SOLR-3926.patch
>
>
> The Solrj api uses ortogonal concepts for setting/removing and getting sort 
> information. Setting/removing uses a combination of (name,order), while 
> getters return a String "name order":
> {code}
> public SolrQuery setSortField(String field, ORDER order);
> public SolrQuery addSortField(String field, ORDER order);
> public SolrQuery removeSortField(String field, ORDER order);
> public String[] getSortFields();
> public String getSortField();
> {code}
> If you want to use the current sort information to present a list of active 
> sorts, with the possibility to remove then, you need to manually parse the 
> string(s) returned from getSortFields, to recreate the information required 
> by removeSortField(). Not difficult, but not convenient either :-)
> Therefore this suggestion: Add a new method {{public Map 
> getSortFieldMap();}} which returns an ordered map of active sort fields. This 
> will make introspection of the current sort setup much easier.
> {code}
>   public Map getSortFieldMap() {
> String[] actualSortFields = getSortFields();
> if (actualSortFields == null || actualSortFields.length == 0)
>   return Collections.emptyMap();
> Map sortFieldMap = new LinkedHashMap();
> for (String sortField : actualSortFields) {
>   String[] fieldSpec = sortField.trim().split(" ");
>   sortFieldMap.put(fieldSpec[0], ORDER.valueOf(fieldSpec[1]));
> }
> return Collections.unmodifiableMap(sortFieldMap);
>   }
> {code}
> For what it's worth, this is possible client code:
> {code}
> System.out.println("Active sorts");
> Map fieldMap = getSortFieldMap(query);
> for (String field : fieldMap.keySet()) {
>System.out.println("- " + field + "; dir=" + fieldMap.get(field));
> }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (LUCENE-3907) Improve the Edge/NGramTokenizer/Filters

[Steve Rowe (JIRA)]

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

Steve Rowe updated LUCENE-3907:
---

Fix Version/s: (was: 4.1)
   4.2

> Improve the Edge/NGramTokenizer/Filters
> ---
>
> Key: LUCENE-3907
> URL: https://issues.apache.org/jira/browse/LUCENE-3907
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Uwe Schindler
>  Labels: gsoc2012, lucene-gsoc-12
> Fix For: 4.2
>
>
> Our ngram tokenizers/filters could use some love.  EG, they output ngrams in 
> multiple passes, instead of "stacked", which messes up offsets/positions and 
> requires too much buffering (can hit OOME for long tokens).  They clip at 
> 1024 chars (tokenizers) but don't (token filters).  The split up surrogate 
> pairs incorrectly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-3633) web UI reports an error if CoreAdminHandler says there are no SolrCores

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-3633:
-

Fix Version/s: (was: 4.1)
   4.2

> web UI reports an error if CoreAdminHandler says there are no SolrCores
> ---
>
> Key: SOLR-3633
> URL: https://issues.apache.org/jira/browse/SOLR-3633
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 4.0-ALPHA
>Reporter: Hoss Man
>Assignee: Stefan Matheis (steffkes)
> Fix For: 4.2
>
> Attachments: SOLR-3633.patch, SOLR-3633.patch
>
>
> Spun off from SOLR-3591...
> * having no SolrCores is a valid situation
> * independent of what may happen in SOLR-3591, the web UI should cleanly deal 
> with there being no SolrCores, and just hide/grey out any tabs that can't be 
> supported w/o at least one core
> * even if there are no SolrCores the core admin features (ie: creating a new 
> core) should be accessible in the UI

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4103) Investigate failure of TestDocBuilder2#testFileListEntityProcessor_lastIndexTime

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-4103:
-

Fix Version/s: (was: 4.1)
   4.2

> Investigate failure of 
> TestDocBuilder2#testFileListEntityProcessor_lastIndexTime
> 
>
> Key: SOLR-4103
> URL: https://issues.apache.org/jira/browse/SOLR-4103
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 4.1, 5.0
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Fix For: 4.2, 5.0
>
>
> TestDocBuilder2#testFileListEntityProcessor_lastIndexTime has been @Ignore'd 
> for a long time due to SOLR-1916.  With that resolved, this test is now 
> failing for other reasons.  Need to figure out why and fix it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4098) Unacceptable Corecontainer logic.lead delete/rename/swap a core quietly

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-4098:
-

Fix Version/s: (was: 4.1)
   4.2

> Unacceptable Corecontainer logic.lead delete/rename/swap a core quietly
> ---
>
> Key: SOLR-4098
> URL: https://issues.apache.org/jira/browse/SOLR-4098
> Project: Solr
>  Issue Type: Bug
>  Components: multicore
>Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0
>Reporter: Po Rui
>Assignee: Mark Miller
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4098.patch
>
>
> a bad logic in CoreContainer. it will assign a default name using 
> checkDefault(name) while the core name is not specified.
> e.g.
> http://127.0.0.1:8983/solr/admin/cores?action=UNLOAD
> or append whatever uncrect param like:
> http://127.0.0.1:8983/solr/admin/cores?action=UNLOAD&appname=wop
> those request both unload the core "collection1"(cause the default core name 
> is "collection1" in solr)
> this bad behavior appear on "reload"/"swap"/"rename"/"remove" and 
> "getCore(String)" operation
> here, checkDefault() should throw exception rather than assign a name quietly
> I'd fixed rename/remove/reload/swap. but getCore(name) be invoked by too many 
> methods. I'm not sure weather this also lead some potential issue now. I'd 
> rather believe it does. those invoker should be double check in next version  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-3859) SolrCloud admin graph is showing leader as state recovery failed, but it's working

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-3859:
-

Fix Version/s: (was: 4.1)
   4.2

> SolrCloud admin graph is showing leader as state recovery failed, but it's 
> working
> --
>
> Key: SOLR-3859
> URL: https://issues.apache.org/jira/browse/SOLR-3859
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.0-BETA
> Environment: linux/centos
>Reporter: Jim Musil
>Assignee: Mark Miller
> Fix For: 4.2, 5.0
>
> Attachments: zkAdminScreen.PNG, zkDump.txt
>
>
> I'm not sure this is truly a bug, but the behavior really confuses me.
> I have four servers running one of my cores. As a test, I took down the 
> leader to watch how leader election works. In this case, a leader was 
> selected, but it went into a state of "recovery failed". The odd thing is 
> that everything still works. I can query that box directly and I can query 
> the cluster and I observe correct behavior.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (LUCENE-4556) FuzzyTermsEnum creates tons of objects

[Steve Rowe (JIRA)]

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

Steve Rowe updated LUCENE-4556:
---

Fix Version/s: (was: 4.1)
   4.2

> FuzzyTermsEnum creates tons of objects
> --
>
> Key: LUCENE-4556
> URL: https://issues.apache.org/jira/browse/LUCENE-4556
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search, modules/spellchecker
>Affects Versions: 4.0
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
>Priority: Critical
> Fix For: 4.2, 5.0
>
> Attachments: LUCENE-4556.patch, LUCENE-4556.patch
>
>
> I ran into this problem in production using the DirectSpellchecker. The 
> number of objects created by the spellchecker shoot through the roof very 
> very quickly. We ran about 130 queries and ended up with > 2M transitions / 
> states. We spend 50% of the time in GC just because of transitions. Other 
> parts of the system behave just fine here.
> I talked quickly to robert and gave a POC a shot providing a 
> LevenshteinAutomaton#toRunAutomaton(prefix, n) method to optimize this case 
> and build a array based strucuture converted into UTF-8 directly instead of 
> going through the object based APIs. This involved quite a bit of changes but 
> they are all package private at this point. I have a patch that still has a 
> fair set of nocommits but its shows that its possible and IMO worth the 
> trouble to make this really useable in production. All tests pass with the 
> patch - its a start

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4070) OverSeerCollectionProcessor.createCollection() parameters issue.

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-4070:
-

Fix Version/s: (was: 4.1)
   4.2

> OverSeerCollectionProcessor.createCollection()  parameters issue. 
> --
>
> Key: SOLR-4070
> URL: https://issues.apache.org/jira/browse/SOLR-4070
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.0-BETA, 4.0
>Reporter: Po Rui
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4070.patch
>
>
> parameters doesn't validate. the same "collectionName" may be created more 
> than once. check the existent collectionName and nonexistent config files 
> before create a collection

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (LUCENE-4549) Allow variable buffer size on BufferedIndexOutput

[Steve Rowe (JIRA)]

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

Steve Rowe updated LUCENE-4549:
---

Fix Version/s: (was: 4.1)
   4.2

> Allow variable buffer size on BufferedIndexOutput 
> --
>
> Key: LUCENE-4549
> URL: https://issues.apache.org/jira/browse/LUCENE-4549
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/store
>Affects Versions: 4.0
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
>Priority: Minor
> Fix For: 4.2, 5.0
>
> Attachments: LUCENE-4549.patch
>
>
> BufferedIndexInput allows to set the buffersize but BufferedIndexOutput 
> doesn't this could be useful for optimizations related to LUCENE-4537. We 
> should make the apis here consistent.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4300) Possible race condition in CoreContainer.getCore() when lazily loading cores.

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-4300:
--

OK, I'm going to commit this this evening or tomorrow morning for both trunk, 
4.1 & 4.x unless there are objections. I'll take another detailed pass over the 
code before I do on the theory that anything stupid will be clearer after not 
looking at it for a while.

My fears of deadlock are probably overblown. People don't _get_ to the code in 
question unless they're defining lazily-loaded cores, so "It shouldn't affect 
anyone not using the new functionality" (tm).



> Possible race condition in CoreContainer.getCore() when lazily loading cores.
> -
>
> Key: SOLR-4300
> URL: https://issues.apache.org/jira/browse/SOLR-4300
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.1, 5.0
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Blocker
> Attachments: SOLR-4300.patch
>
>
> Yonik pointed out in SOLR-1028 that there is a possible race condition here, 
> he's right not to my surprise. Calling it a "blocker" for now so we make a 
> decision on it rather than let it fall through the cracks. I should be able 
> to get a patch up tonight (Sunday).
> That said, there's potential here to introduce deadlocks, is it worth rushing 
> into 4.1?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-3915) Color Legend for Cloud UI

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-3915:
-

Fix Version/s: (was: 4.1)
   4.2

> Color Legend for Cloud UI
> -
>
> Key: SOLR-3915
> URL: https://issues.apache.org/jira/browse/SOLR-3915
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Reporter: Stefan Matheis (steffkes)
>Assignee: Stefan Matheis (steffkes)
>Priority: Minor
> Fix For: 4.2
>
> Attachments: erick_overlap.png, SOLR-3915.patch, SOLR-3915.patch, 
> SOLR-3915-screenshot.png, SOLR-3915-screenshot.png
>
>
> The meaning of the used shard colors is not really clear, integrate kind of a 
> legend fo all possible node-states.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (LUCENE-4602) Use DocValues to store per-doc facet ord

[Shai Erera (JIRA)]

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

Shai Erera updated LUCENE-4602:
---

Attachment: LUCENE-4602.patch

Patch nukes CategoryListCache. Apparently TotalFacetCounts's API had it all 
over the place, but all their tests passed {{null}}! The cache was tested 
separately though ...

Anyway, nuked all relevant stuff, as well as FacetRequest.createCLI (this was 
there just in case someone set a CLCache on FacetSearchParams) -- createCLI is 
controlled by CLParams. I think that the cache should be controlled by that too 
.. but if we'll ever add such cache back, we'll have the opportunity to put it 
there.

I think this is ready. I'll give it a couple more test runs and then commit.

> Use DocValues to store per-doc facet ord
> 
>
> Key: LUCENE-4602
> URL: https://issues.apache.org/jira/browse/LUCENE-4602
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/facet
>Reporter: Michael McCandless
> Attachments: FacetsPayloadMigrationReader.java, LUCENE-4602.patch, 
> LUCENE-4602.patch, LUCENE-4602.patch, LUCENE-4602.patch, LUCENE-4602.patch, 
> TestFacetsPayloadMigrationReader.java
>
>
> Spinoff from LUCENE-4600
> DocValues can be used to hold the byte[] encoding all facet ords for
> the document, instead of payloads.  I made a hacked up approximation
> of in-RAM DV (see CachedCountingFacetsCollector in the patch) and the
> gains were somewhat surprisingly large:
> {noformat}
> TaskQPS base  StdDevQPS comp  StdDev  
>   Pct diff
> HighTerm0.53  (0.9%)1.00  (2.5%)   
> 87.3% (  83% -   91%)
>  LowTerm7.59  (0.6%)   26.75 (12.9%)  
> 252.6% ( 237% -  267%)
>  MedTerm3.35  (0.7%)   12.71  (9.0%)  
> 279.8% ( 268% -  291%)
> {noformat}
> I didn't think payloads were THAT slow; I think it must be the advance
> implementation?
> We need to separately test on-disk DV to make sure it's at least
> on-par with payloads (but hopefully faster) and if so ... we should
> cutover facets to using DV.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-3904) add package level javadocs to every package

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-3904:
-

Fix Version/s: (was: 4.1)
   4.2

I can see that at least solr-core doesn't have this enabled - pushing Fix 
Version to 4.2. 

> add package level javadocs to every package
> ---
>
> Key: SOLR-3904
> URL: https://issues.apache.org/jira/browse/SOLR-3904
> Project: Solr
>  Issue Type: Improvement
>  Components: documentation
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 4.2
>
> Attachments: SOLR-3904_buildxml.patch
>
>
> quoth rmuir on the mailing list...
> {quote}
> We've been working on this for the lucene side (3.6 was the first
> release where every package had docs, 4.0 will be the first where
> every class had docs, and we are now working towards
> methods/fields/ctors/enums).
> I think this would be valuable for solr too (especially solrj as a start).
> Besides users, its really useful to developers as well. Of course we
> all think our code is self-documenting, but its not always the case. a
> few extra seconds can save someone a ton of time trying to figure out
> your code.
> Additionally at least in my IDE, when things are done as javadoc
> comments then they are more easily accessible than code comments. I'm
> sure its the case for some other development environments too.
> Filling in these package.html's to at least have a one sentence
> description would be a really good start. It lets someone know where
> to go at the high-level.
> If I was brand new to solr and wanted to write a java app that uses
> solrj, i wouldn't have a clue where to start
> (https://builds.apache.org/job/Solr-Artifacts-4.x/javadoc/solr-solrj/index.html).
> 12 sentences could go a really long way.
> And for all new code, I hope we can all try harder for more complete
> javadocs. when you are working on something and its fresh in your head
> its a lot easier to do this than for someone else to come back around
> and figure it out.
> {quote}
> I'm going to try and make it a priority for me to fill in package level docs 
> as we look towards 4.1

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-3980) Incorporate lazily-loaded cores into core listings for clients

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-3980:
-

Fix Version/s: (was: 4.1)
   4.2

bq. Same as SOLR-1533, I'll resolve all this stuff as a bunch for 4.2

Ok, thanks, I've pushed Fix Version to 4.2.

> Incorporate lazily-loaded cores into core listings for clients
> --
>
> Key: SOLR-3980
> URL: https://issues.apache.org/jira/browse/SOLR-3980
> Project: Solr
>  Issue Type: Improvement
>  Components: multicore, web gui
>Affects Versions: 4.1
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 4.2
>
>
> Part of SOLR-1293 (supporting lots of cores) will require we do something to 
> allow clients (particularly the admin GUI) to get a full list of all possible 
> cores, whether they've been loaded or not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-3980) Incorporate lazily-loaded cores into core listings for clients

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-3980:
--

Same as SOLR-1533, I'll resolve all this stuff as a bunch for 4.2



> Incorporate lazily-loaded cores into core listings for clients
> --
>
> Key: SOLR-3980
> URL: https://issues.apache.org/jira/browse/SOLR-3980
> Project: Solr
>  Issue Type: Improvement
>  Components: multicore, web gui
>Affects Versions: 4.1
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 4.1
>
>
> Part of SOLR-1293 (supporting lots of cores) will require we do something to 
> allow clients (particularly the admin GUI) to get a full list of all possible 
> cores, whether they've been loaded or not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-1533) Partition data directories into multiple "bucket" directories

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-1533:
--

This is very much in the works. It's related to SOLR-1028 & etc. I'm waiting on 
4.1 to be cut so it can all bake in 4.2 for a while before being released into 
the wild. There are a bunch of other related JIRAS as well, SOLR-4196 and 
SOLR-4083 in particular.

So I'll be tracking this and probably kill it when I'm sure the 
directory-discovery bits work...

> Partition data directories into multiple "bucket" directories
> -
>
> Key: SOLR-1533
> URL: https://issues.apache.org/jira/browse/SOLR-1533
> Project: Solr
>  Issue Type: New Feature
>  Components: multicore
>Reporter: Shalin Shekhar Mangar
>Assignee: Erick Erickson
> Fix For: 4.2
>
>
> Provide a way to partition data directories into multiple "bucket" 
> directories. For example, instead of creating 10,000 data directories inside 
> one base data directory, Solr can assign a core to one of 4 base directories, 
> thereby distributing them.
> The underlying problem is that with large number of indexes, we see slower 
> and slower system performance as one goes on increasing the number of cores, 
> thereby increasing the number of directories in the single data directory.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-3980) Incorporate lazily-loaded cores into core listings for clients

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-3980:
--

Erick, can this issue be resolved?

> Incorporate lazily-loaded cores into core listings for clients
> --
>
> Key: SOLR-3980
> URL: https://issues.apache.org/jira/browse/SOLR-3980
> Project: Solr
>  Issue Type: Improvement
>  Components: multicore, web gui
>Affects Versions: 4.1
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 4.1
>
>
> Part of SOLR-1293 (supporting lots of cores) will require we do something to 
> allow clients (particularly the admin GUI) to get a full list of all possible 
> cores, whether they've been loaded or not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4013) Creating a core should prevent more than one thread from creating a core of the same name at once.

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-4013:
-

Fix Version/s: (was: 4.1)
   4.2

> Creating a core should prevent more than one thread from creating a core of 
> the same name at once.
> --
>
> Key: SOLR-4013
> URL: https://issues.apache.org/jira/browse/SOLR-4013
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 4.1, 5.0
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 4.2, 5.0
>
>
> This hasn't been an issue so far since cores are created at startup. But in 
> the lots of cores case (see SOLR-1293) the probability that more than one 
> thread will attempt to create a core of the same name is vastly greater. We 
> need to block other threads from creating a core if the core is already being 
> created in a different thread.
> Once the core is created, the blocked thread should pick up the newly-created 
> core rather than create it again.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.7.0_10) - Build # 2409 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/2409/
Java: 64bit/jdk1.7.0_10 -XX:+UseParallelGC

All tests passed

Build Log:
[...truncated 25842 lines...]
-documentation-lint:
 [echo] checking for broken html...
[jtidy] Checking for broken html (such as invalid tags)...
   [delete] Deleting directory 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build\jtidy_tmp
 [echo] Checking for broken links...
 [exec] 
 [exec] Crawl/parse...
 [exec] 
 [exec] Verify...
 [echo] Checking for missing docs...
 [exec] 
 [exec] 
build/docs\suggest\org\apache\lucene\search\spell/package-summary.html
 [exec]   missing: DirectSpellChecker.ScoreTerm
 [exec] 
 [exec] Missing javadocs were found!

BUILD FAILED
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:60: The 
following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build.xml:245: 
The following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\common-build.xml:1972:
 exec returned: 1

Total time: 65 minutes 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Description set: Java: 64bit/jdk1.7.0_10 -XX:+UseParallelGC
Email was triggered for: Failure
Sending email for trigger: Failure



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

[jira] [Updated] (SOLR-1293) Support for large no:of cores and faster loading/unloading of cores

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-1293:
-

Fix Version/s: (was: 4.1)
   4.2

> Support for large no:of cores and faster loading/unloading of cores
> ---
>
> Key: SOLR-1293
> URL: https://issues.apache.org/jira/browse/SOLR-1293
> Project: Solr
>  Issue Type: New Feature
>  Components: multicore
>Reporter: Noble Paul
>Assignee: Erick Erickson
> Fix For: 4.2
>
> Attachments: SOLR-1293.patch
>
>
> Solr , currently ,is not very suitable for a large no:of homogeneous cores 
> where you require fast/frequent loading/unloading of cores . usually a core 
> is required to be loaded just to fire a search query or to just index one 
> document
> The requirements of such a system are.
> * Very efficient loading of cores . Solr cannot afford to read and parse and 
> create Schema, SolrConfig Objects for each core each time the core has to be 
> loaded ( SOLR-919 , SOLR-920)
> * START STOP core . Currently it is only possible to unload a core (SOLR-880)
> * Automatic loading of cores . If a core is present and it is not loaded and 
> a request comes for that load it automatically before serving up a request
> * As there are a large no:of cores , all the cores cannot be kept loaded 
> always. There has to be an upper limit beyond which we need to unload a few 
> cores (probably the least recently used ones)
> * Automatic allotment of dataDir for cores. If the no:of cores is too high al 
> the cores' dataDirs cannot live in the same dir. There is an upper limit on 
> the no:of dirs you can create in a unix dir w/o affecting performance

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-1533) Partition data directories into multiple "bucket" directories

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-1533:
-

Fix Version/s: (was: 4.1)
   4.2

Erick, do you plan on following through on your threat to kill this issue?

> Partition data directories into multiple "bucket" directories
> -
>
> Key: SOLR-1533
> URL: https://issues.apache.org/jira/browse/SOLR-1533
> Project: Solr
>  Issue Type: New Feature
>  Components: multicore
>Reporter: Shalin Shekhar Mangar
>Assignee: Erick Erickson
> Fix For: 4.2
>
>
> Provide a way to partition data directories into multiple "bucket" 
> directories. For example, instead of creating 10,000 data directories inside 
> one base data directory, Solr can assign a core to one of 4 base directories, 
> thereby distributing them.
> The underlying problem is that with large number of indexes, we see slower 
> and slower system performance as one goes on increasing the number of cores, 
> thereby increasing the number of directories in the single data directory.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-3885) audit solr DocumentBuilder logic & tests

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-3885:
-

Fix Version/s: (was: 4.1)
   4.2

> audit solr DocumentBuilder logic & tests
> 
>
> Key: SOLR-3885
> URL: https://issues.apache.org/jira/browse/SOLR-3885
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 4.2
>
>
> Spun off of SOLR-3875: it would be good to audit DocumentBuilder carefully 
> and ensure that there are adequate tests for the various edge cases (ie: 
> docboosts, copyfield, multivalued fields, various combinations of, etc..) and 
> special types of fields (ie: polyfields).
> There also seems to be some dead code here that can likely be cleaned up.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (LUCENE-4491) Make analyzing suggester more flexible

[Steve Rowe (JIRA)]

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

Steve Rowe updated LUCENE-4491:
---

Affects Version/s: (was: 4.1)
   4.2

> Make analyzing suggester more flexible
> --
>
> Key: LUCENE-4491
> URL: https://issues.apache.org/jira/browse/LUCENE-4491
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/other
>Affects Versions: 4.2
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: 4.1, 5.0
>
> Attachments: LUCENE-4491.patch, LUCENE-4491.patch
>
>
> Today we have a analyzing suggester that is bound to a single key. Yet, if 
> you want to have a totally different surface form compared to the key used to 
> find the suggestion you either have to copy the code or play some super ugly 
> analyzer tricks. For example I want to suggest "Barbar Streisand" if somebody 
> types "strei" in that case the surface form is totally different from the 
> analyzed form. 
> Even one step further I want to embed some meta-data in the suggested key 
> like a user id or some type my surface form could look like "Barbar 
> Streisand|15". Ideally I want to encode this as binary and that might not be 
> a valid UTF-8 byte sequence.
> I'm actually doing this in production and my only option was to copy the 
> analyzing suggester and some of it's related classes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-3961) LimitTokenCountFilterFactory config parsing is totally broken

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-3961:
--

Hoss, I don't think there will be a 4.0.1 release - can this be resolved as 
fixed?

> LimitTokenCountFilterFactory config parsing is totally broken
> -
>
> Key: SOLR-3961
> URL: https://issues.apache.org/jira/browse/SOLR-3961
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.0
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 4.0.1, 4.1, 5.0
>
> Attachments: SOLR-3961.patch, SOLR-3961.patch
>
>
> As noted on the mailing list, LimitTokenCountFilterFactory throws a 
> NumberFormatException because it tries to use the value of it's config param 
> as a key to look up another param that it parses as an integer ... totally 
> ridiculous.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4465) ConstantScoreQuery's scorer does not return child scorers

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-4465:
---

Oh. I missed that one.  I will commit soon. 

> ConstantScoreQuery's scorer does not return child scorers
> -
>
> Key: LUCENE-4465
> URL: https://issues.apache.org/jira/browse/LUCENE-4465
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 4.0-BETA
>Reporter: selckin
>Assignee: Uwe Schindler
> Fix For: 4.1, 5.0
>
> Attachments: constant-score-children.patch
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4465) ConstantScoreQuery's scorer does not return child scorers

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-4465:


Uwe, do you plan on getting this into 4.1?

> ConstantScoreQuery's scorer does not return child scorers
> -
>
> Key: LUCENE-4465
> URL: https://issues.apache.org/jira/browse/LUCENE-4465
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 4.0-BETA
>Reporter: selckin
>Assignee: Uwe Schindler
> Fix For: 4.1, 5.0
>
> Attachments: constant-score-children.patch
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-3888) need beter handling of external add/commit requests during tlog recovery

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-3888:
-

Fix Version/s: (was: 4.1)
   4.2

> need beter handling of external add/commit requests during tlog recovery
> 
>
> Key: SOLR-3888
> URL: https://issues.apache.org/jira/browse/SOLR-3888
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.0
>Reporter: Hoss Man
>Assignee: Yonik Seeley
> Fix For: 4.2
>
>
> as noted in SOLR-3884: if Solr suffers an unclean-shutdown with documents in 
> the tlog that have not been hard commited to the index, it is then possible 
> that on the next startup tlog recovery will cause "commits" sent by external 
> clients (ie: after indexing new documents) to be ignored.
> in general, we need to give more thought to edge causes of how updates during 
> tlog recovery should be dealt with...
> * is there a non-solrcloud tlog recovery case we're handling poorly?
> * should all updates be blocked until tlog recovery finishes?
> * should tlog recovery be synchronized on UpdateHandler init so that solr 
> isn't even listing on the port until it finishes?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4602) Use DocValues to store per-doc facet ord

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-4602:


Patch looks good, at least the parts that I understand: +1

Nice that drill-down fields are now indexed as DOCS_ONLY!!

> Use DocValues to store per-doc facet ord
> 
>
> Key: LUCENE-4602
> URL: https://issues.apache.org/jira/browse/LUCENE-4602
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/facet
>Reporter: Michael McCandless
> Attachments: FacetsPayloadMigrationReader.java, LUCENE-4602.patch, 
> LUCENE-4602.patch, LUCENE-4602.patch, LUCENE-4602.patch, 
> TestFacetsPayloadMigrationReader.java
>
>
> Spinoff from LUCENE-4600
> DocValues can be used to hold the byte[] encoding all facet ords for
> the document, instead of payloads.  I made a hacked up approximation
> of in-RAM DV (see CachedCountingFacetsCollector in the patch) and the
> gains were somewhat surprisingly large:
> {noformat}
> TaskQPS base  StdDevQPS comp  StdDev  
>   Pct diff
> HighTerm0.53  (0.9%)1.00  (2.5%)   
> 87.3% (  83% -   91%)
>  LowTerm7.59  (0.6%)   26.75 (12.9%)  
> 252.6% ( 237% -  267%)
>  MedTerm3.35  (0.7%)   12.71  (9.0%)  
> 279.8% ( 268% -  291%)
> {noformat}
> I didn't think payloads were THAT slow; I think it must be the advance
> implementation?
> We need to separately test on-disk DV to make sure it's at least
> on-par with payloads (but hopefully faster) and if so ... we should
> cutover facets to using DV.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Closed] (SOLR-3039) ExtendedDismaxQParser should allow for extension of parsing-related behavior

[Danny Dvinov (JIRA)]

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

Danny Dvinov closed SOLR-3039.
--

   Resolution: Duplicate
Fix Version/s: 4.1

> ExtendedDismaxQParser should allow for extension of parsing-related behavior
> 
>
> Key: SOLR-3039
> URL: https://issues.apache.org/jira/browse/SOLR-3039
> Project: Solr
>  Issue Type: Improvement
>  Components: query parsers
>Affects Versions: 5.0
>Reporter: Danny Dvinov
>Priority: Minor
>  Labels: edismax, parser, parsing
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-3039.patch, SOLR-3039.patch, SOLR-3039.patch, 
> SOLR-3039.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> ExtendedDismaxQParser.parse does not currently allow for things like query 
> pre-processing prior to its parsing, specifying the parser to be used, and 
> whether particular clause should be included in the query being parsed. 
> Furthermore, ExtendedDismaxQParser and inner ExtendedSolrQueryParser cannot 
> be subclassed. By resolving this issue, we'll provide a way for Solr 
> implementations to extend the parser and parsing related behavior.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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