Re: [JENKINS] Lucene-Solr-4.x-MacOSX (64bit/jdk1.7.0) - Build # 45 - Still Failing!

[Dawid Weiss]

[junit4:junit4] >>> JVM J0: stderr (verbatim) 
[junit4:junit4] java(999,0x13760c000) malloc: *** error for object
0x1375faef1: pointer being freed was not allocated
[junit4:junit4] *** set a breakpoint in malloc_error_break to debug
[junit4:junit4] java(999,0x13815b000) malloc: *** error for object
0x13814a014: pointer being freed was not allocated
[junit4:junit4] *** set a breakpoint in malloc_error_break to debug
[junit4:junit4] <<< JVM J0: EOF 

Robert tracked an interesting paper about FreeBSD's alternative malloc
implementation which can track double free calls. If MacOSX is using
this then it'd explain why we're seing these. Still, it shouldn't
result in a VM crash I think so something odd is happening at the VM
level -- I think malloc warnings are an effect not the cause of these
VM crashes.

Dawid


On Mon, Jan 7, 2013 at 2:48 AM, Policeman Jenkins Server
 wrote:
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/45/
> Java: 64bit/jdk1.7.0 -XX:+UseParallelGC
>
> All tests passed
>
> Build Log:
> [...truncated 8641 lines...]
> [junit4:junit4] ERROR: JVM J0 ended with an exception, command line: 
> /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre/bin/java 
> -XX:+UseParallelGC -XX:+HeapDumpOnOutOfMemoryError 
> -XX:HeapDumpPath=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/heapdumps
>  -Dtests.prefix=tests -Dtests.seed=37A75E8D5824BBDD -Xmx512M -Dtests.iters= 
> -Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random 
> -Dtests.postingsformat=random -Dtests.locale=random -Dtests.timezone=random 
> -Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz 
> -Dtests.luceneMatchVersion=4.1 -Dtests.cleanthreads=perClass 
> -Djava.util.logging.config.file=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/testlogging.properties
>  -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true 
> -Dtests.asserts.gracious=false -Dtests.multiplier=1 -DtempDir=. 
> -Djava.io.tmpdir=. 
> -Djunit4.tempDir=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/build/solr-core/test/temp
>  
> -Dclover.db.dir=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/clover/db
>  -Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
> -Djava.security.policy=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/tools/junit4/tests.policy
>  -Dlucene.version=4.1-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 
> -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory 
> -Djava.awt.headless=true -Dfile.encoding=US-ASCII -classpath 
> /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/build/solr-core/classes/test:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/build/solr-test-framework/classes/java:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/build/solr-core/test-files:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/test-framework/classes/java:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/codecs/classes/java:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/build/solr-solrj/classes/java:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/build/solr-core/classes/java:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/analysis/common/lucene-analyzers-common-4.1-SNAPSHOT.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/analysis/kuromoji/lucene-analyzers-kuromoji-4.1-SNAPSHOT.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/analysis/phonetic/lucene-analyzers-phonetic-4.1-SNAPSHOT.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/highlighter/lucene-highlighter-4.1-SNAPSHOT.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/memory/lucene-memory-4.1-SNAPSHOT.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/misc/lucene-misc-4.1-SNAPSHOT.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/spatial/lucene-spatial-4.1-SNAPSHOT.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/suggest/lucene-suggest-4.1-SNAPSHOT.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/grouping/lucene-grouping-4.1-SNAPSHOT.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/queries/lucene-queries-4.1-SNAPSHOT.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/queryparser/lucene-queryparser-4.1-SNAPSHOT.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/core/lib/cglib-nodep-2.2.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/core/lib/commons-cli-1.2.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/core/lib/commons-codec-1.7.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-Mac

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

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 25841 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...
 [exec] 
 [exec] 
file:///build/docs/facet/org/apache/lucene/facet/taxonomy/writercache/cl2o/CategoryPathUtils.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec] 
 [exec] 
file:///build/docs/facet/org/apache/lucene/facet/taxonomy/class-use/CategoryPath.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec] 
 [exec] Broken javadocs links 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:242: The 
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1961:
 exec returned: 1

Total time: 34 minutes 30 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Description set: Java: 64bit/jdk1.7.0_10 -XX:+UseSerialGC
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: [JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.7.0) - Build # 58 - Failure!

[Shai Erera]

I don't like this failure. CategoryPathUtils contains some {@link
CharBlockArray} mentions, while the latter is package-private. When I run
'ant javadocs' the generated javadocs just include the text CharBlockArray
with no link. I don't think that's a true error?

Anyway, this made me think that CategoryPathUtils should be package-private
itself, since its API relies on package-private API, so I committed that
change.

I hope that documentation-lint will be happier now.

But in general I think that this failure was a false positive. We should be
allowed to put such links in jdocs - the generated jdocs don't display them
as links, so end-user wise there's no problem.

Shai


On Mon, Jan 7, 2013 at 7:57 AM, Policeman Jenkins Server <
jenk...@thetaphi.de> wrote:

> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/58/
> Java: 64bit/jdk1.7.0 -XX:+UseConcMarkSweepGC
>
> All tests passed
>
> Build Log:
> [...truncated 25815 lines...]
> -documentation-lint:
>  [echo] checking for broken html...
> [jtidy] Checking for broken html (such as invalid tags)...
>[delete] Deleting directory
> /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/jtidy_tmp
>  [echo] Checking for broken links...
>  [exec]
>  [exec] Crawl/parse...
>  [exec]
>  [exec] Verify...
>  [exec]
>  [exec]
> file:///build/docs/facet/org/apache/lucene/facet/taxonomy/class-use/CategoryPath.html
>  [exec]   BROKEN LINK:
> file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
>  [exec]   BROKEN LINK:
> file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
>  [exec]   BROKEN LINK:
> file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
>  [exec]   BROKEN LINK:
> file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
>  [exec]
>  [exec]
> file:///build/docs/facet/org/apache/lucene/facet/taxonomy/writercache/cl2o/CategoryPathUtils.html
>  [exec]   BROKEN LINK:
> file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
>  [exec]   BROKEN LINK:
> file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
>  [exec]   BROKEN LINK:
> file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
>  [exec]   BROKEN LINK:
> file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
>  [exec]   BROKEN LINK:
> file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
>  [exec]   BROKEN LINK:
> file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
>  [exec]   BROKEN LINK:
> file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
>  [exec]   BROKEN LINK:
> file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
>  [exec]   BROKEN LINK:
> file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
>  [exec]   BROKEN LINK:
> file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
>  [exec]
>  [exec] Broken javadocs links were found!
>
> BUILD FAILED
> /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/build.xml:60:
> The following error occurred while executing this line:
> /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/lucene/build.xml:242:
> The following error occurred while executing this line:
> /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/lucene/common-build.xml:1961:
> exec returned: 1
>
> Total time: 81 minutes 29 seconds
> Build step 'Invoke Ant' marked build as failure
> Archiving artifacts
> Recording test results
> Description set: Java: 64bit/jdk1.7.0 -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
>

[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.7.0) - Build # 58 - Failure!

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 25815 lines...]
-documentation-lint:
 [echo] checking for broken html...
[jtidy] Checking for broken html (such as invalid tags)...
   [delete] Deleting directory 
/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/jtidy_tmp
 [echo] Checking for broken links...
 [exec] 
 [exec] Crawl/parse...
 [exec] 
 [exec] Verify...
 [exec] 
 [exec] 
file:///build/docs/facet/org/apache/lucene/facet/taxonomy/class-use/CategoryPath.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec] 
 [exec] 
file:///build/docs/facet/org/apache/lucene/facet/taxonomy/writercache/cl2o/CategoryPathUtils.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec] 
 [exec] Broken javadocs links were found!

BUILD FAILED
/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/build.xml:60: 
The following error occurred while executing this line:
/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/lucene/build.xml:242:
 The following error occurred while executing this line:
/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/lucene/common-build.xml:1961:
 exec returned: 1

Total time: 81 minutes 29 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Description set: Java: 64bit/jdk1.7.0 -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

[JENKINS] Lucene-Solr-4.x-Linux (64bit/jdk1.7.0_10) - Build # 3617 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/3617/
Java: 64bit/jdk1.7.0_10 -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 25642 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-4.x-Linux/lucene/build/jtidy_tmp
 [echo] Checking for broken links...
 [exec] 
 [exec] Crawl/parse...
 [exec] 
 [exec] Verify...
 [exec] 
 [exec] 
file:///build/docs/facet/org/apache/lucene/facet/taxonomy/writercache/cl2o/CategoryPathUtils.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec] 
 [exec] 
file:///build/docs/facet/org/apache/lucene/facet/taxonomy/class-use/CategoryPath.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec] 
 [exec] Broken javadocs links were found!

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

Total time: 38 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:+UseG1GC
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

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

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 23583 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] 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.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.ap

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

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 25818 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...
 [exec] 
 [exec] 
file:///build/docs/facet/org/apache/lucene/facet/taxonomy/class-use/CategoryPath.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec] 
 [exec] 
file:///build/docs/facet/org/apache/lucene/facet/taxonomy/writercache/cl2o/CategoryPathUtils.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec] 
 [exec] Broken javadocs links 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:242: 
The following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\common-build.xml:1961:
 exec returned: 1

Total time: 64 minutes 44 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

[jira] [Commented] (LUCENE-4661) Reduce default maxMerge/ThreadCount for ConcurrentMergeScheduler

[Littlestar (JIRA)]

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

Littlestar commented on LUCENE-4661:


when you change default to 1
so it can't be change any more, because setMaxMergeCount/setMaxThreadCount 
depends on each other.

public void setMaxMergeCount(int count) {
if (count < 1) {
  throw new IllegalArgumentException("count should be at least 1");
}
if (count < maxThreadCount) {
  throw new IllegalArgumentException("count should be >= maxThreadCount (= 
" + maxThreadCount + ")");
}
maxMergeCount = count;
  }

  public void setMaxThreadCount(int count) {
if (count < 1) {
  throw new IllegalArgumentException("count should be at least 1");
}
if (count > maxMergeCount) {
  throw new IllegalArgumentException("count should be <= maxMergeCount (= " 
+ maxMergeCount + ")");
}
maxThreadCount = count;
  }

> Reduce default maxMerge/ThreadCount for ConcurrentMergeScheduler
> 
>
> Key: LUCENE-4661
> URL: https://issues.apache.org/jira/browse/LUCENE-4661
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 4.1, 5.0
>
>
> I think our current defaults (maxThreadCount=#cores/2,
> maxMergeCount=maxThreadCount+2) are too high ... I've frequently found
> merges falling behind and then slowing each other down when I index on
> a spinning-magnets drive.
> As a test, I indexed all of English Wikipedia with term-vectors (=
> heavy on merging), using 6 threads ... at the defaults
> (maxThreadCount=3, maxMergeCount=5, for my machine) it took 5288 sec
> to index & wait for merges & commit.  When I changed to
> maxThreadCount=1, maxMergeCount=2, indexing time sped up to 2902
> seconds (45% faster).  This is on a spinning-magnets disk... basically
> spinning-magnets disk don't handle the concurrent IO well.
> Then I tested an OCZ Vertex 3 SSD: at the current defaults it took
> 1494 seconds and at maxThreadCount=1, maxMergeCount=2 it took 1795 sec
> (20% slower).  Net/net the SSD can handle merge concurrency just fine.
> I think we should change the defaults: spinning magnet drives are hurt
> by the current defaults more than SSDs are helped ... apps that know
> their IO system is fast can always increase the merge concurrency.

--
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-4.x-MacOSX (64bit/jdk1.7.0) - Build # 45 - Still Failing!

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 8641 lines...]
[junit4:junit4] ERROR: JVM J0 ended with an exception, command line: 
/Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre/bin/java 
-XX:+UseParallelGC -XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/heapdumps
 -Dtests.prefix=tests -Dtests.seed=37A75E8D5824BBDD -Xmx512M -Dtests.iters= 
-Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random 
-Dtests.postingsformat=random -Dtests.locale=random -Dtests.timezone=random 
-Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz 
-Dtests.luceneMatchVersion=4.1 -Dtests.cleanthreads=perClass 
-Djava.util.logging.config.file=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/testlogging.properties
 -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true 
-Dtests.asserts.gracious=false -Dtests.multiplier=1 -DtempDir=. 
-Djava.io.tmpdir=. 
-Djunit4.tempDir=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/build/solr-core/test/temp
 
-Dclover.db.dir=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/clover/db
 -Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
-Djava.security.policy=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/tools/junit4/tests.policy
 -Dlucene.version=4.1-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 
-Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory 
-Djava.awt.headless=true -Dfile.encoding=US-ASCII -classpath 
/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/build/solr-core/classes/test:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/build/solr-test-framework/classes/java:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/build/solr-core/test-files:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/test-framework/classes/java:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/codecs/classes/java:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/build/solr-solrj/classes/java:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/build/solr-core/classes/java:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/analysis/common/lucene-analyzers-common-4.1-SNAPSHOT.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/analysis/kuromoji/lucene-analyzers-kuromoji-4.1-SNAPSHOT.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/analysis/phonetic/lucene-analyzers-phonetic-4.1-SNAPSHOT.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/highlighter/lucene-highlighter-4.1-SNAPSHOT.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/memory/lucene-memory-4.1-SNAPSHOT.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/misc/lucene-misc-4.1-SNAPSHOT.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/spatial/lucene-spatial-4.1-SNAPSHOT.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/suggest/lucene-suggest-4.1-SNAPSHOT.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/grouping/lucene-grouping-4.1-SNAPSHOT.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/queries/lucene-queries-4.1-SNAPSHOT.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/queryparser/lucene-queryparser-4.1-SNAPSHOT.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/core/lib/cglib-nodep-2.2.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/core/lib/commons-cli-1.2.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/core/lib/commons-codec-1.7.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/core/lib/commons-fileupload-1.2.1.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/core/lib/commons-lang-2.6.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/core/lib/easymock-3.0.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/core/lib/guava-13.0.1.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/core/lib/javax.servlet-api-3.0.1.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/core/lib/objenesis-1.2.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/core/lib/spatial4j-0.3.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/solrj/lib/commons-io-2.1.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/solrj/lib/httpclient-4.1.3.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/solrj/lib/httpcore-4.1.4.jar:/Users/jenkins/jenkins-slave/workspa

[jira] [Updated] (LUCENE-4658) Per-segment tracking of external/side-car data

[Michael McCandless (JIRA)]

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

Michael McCandless updated LUCENE-4658:
---

Attachment: LUCENE-4658.patch

New patch, 1) moving this thing into Codec as (optional)
getExternalDataFormat, and 2) adding basic read-time support.  Test
still passes (and I was able to remove the hack commit/waitForMerges
necessary before because read-time support wasn't there)...

Now I'm not sure it really "belongs" on Codec: it's sort of awkward
because it's an indexing chain PLUS codec part (on the write side).
It's also ... heavyweight now because to use it you must make a Codec
and name it (so SPI can find it at read time), so for Solr (eg) to use
this for an ExternalFileField ... seems hardish.

Maybe it should be back on IndexWriterConfig (write side), but then
we'd need something on the read side ... not sure.


> Per-segment tracking of external/side-car data
> --
>
> Key: LUCENE-4658
> URL: https://issues.apache.org/jira/browse/LUCENE-4658
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Attachments: LUCENE-4658.patch, LUCENE-4658.patch
>
>
> Spinoff from David's idea on LUCENE-4258
> (https://issues.apache.org/jira/browse/LUCENE-4258?focusedCommentId=13534352&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13534352
>  )
> I made a prototype patch that allows custom per-segment "side-car
> data".  It adds an abstract ExternalSegmentData class.  The idea is
> the app implements this, and IndexWriter will pass each Document
> through to it, and call on it to do flushing/merging.  I added a
> setter to IndexWriterConfig to enable it, but I think this would
> really belong in Codec ...
> I haven't tackled the read-side yet, though this is already usable
> without that (ie, the app can just open its own files, read them,
> etc.).
> The random test case passes.
> I think for example this might make it easier for Solr/ElasticSearch
> to implement things like ExternalFileField.

--
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-4277) Spellchecker sometimes falsely reports a spelling error and correction

[Jack Krupansky (JIRA)]

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

Jack Krupansky updated SOLR-4277:
-

Component/s: (was: SearchComponents - other)
 spellchecker

> Spellchecker sometimes falsely reports a spelling error and correction
> --
>
> Key: SOLR-4277
> URL: https://issues.apache.org/jira/browse/SOLR-4277
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 4.0
>Reporter: Jack Krupansky
>
> In some cases, the Solr spell checker improperly reports query terms as being 
> misspelled.
> Using the Solr example for 4.0, I added these mini documents:
> {code}
> curl http://localhost:8983/solr/update?commit=true -H 
> 'Content-type:application/csv' -d '
> id,name
> spel-1,aardvark abacus ball bill cat cello
> spel-2,abate accord band bell cattle check
> spel-3,adorn border clean clock'
> {code}
> I then issued this request:
> {code}
> curl "http://localhost:8983/solr/spell/?q=check&indent=true";
> {code}
> The spell checker falsely concluded that "check" was misspelled and 
> improperly corrected it to "clock":
> {code}
> 
>   
> 
>   1
>   0
>   5
>   1
>   
> 
>   clock
>   1
> 
>   
> 
> false
> 
>   clock
>   1
>   
> clock
>   
> 
>   
> 
> {code}
> And if I query for "clock", it gets corrected to "check"!
> {code}
> curl "http://localhost:8983/solr/spell/?q=clock&indent=true";
> {code}
> {code}
>   
> 
>   1
>   0
>   5
>   1
>   
> 
>   check
>   1
> 
>   
> 
> false
> 
>   check
>   1
>   
> check
>   
> 
>   
> {code}
> Note: This appears to be only because "clock" is so close to "check". With 
> other terms I don't see the problem:
> {code}
> curl "http://localhost:8983/solr/spell/?q=cattle+abate+check&indent=true";
> {code}
> {code}
>   
> 
>   1
>   13
>   18
>   1
>   
> 
>   clock
>   1
> 
>   
> 
> false
> 
>   cattle abate clock
>   2
>   
> cattle
> abate
> clock
>   
> 
>   
> {code}
> Although, it inappropriately lists "cattle" and "abate" in the "misspellings" 
> section even though no suggestions were offered.
> Finally, I can workaround this issue by removing the following line from 
> solrconfig.xml:
> {code}
>   5
> {code}
> Which responds to the previous request with:
> {code}
>   
> false
>   
> {code}
> Which makes the original problem go away. Although, it does beg the question 
> as to why my 100% correct query is still tagged as "correctlySpelled" = 
> "false", but that's a separate Jira.

--
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] [Created] (SOLR-4278) Spellchecker correctlySpelled flag is improperly false in many cases

[Jack Krupansky (JIRA)]

Jack Krupansky created SOLR-4278:


 Summary: Spellchecker correctlySpelled flag is improperly false in 
many cases
 Key: SOLR-4278
 URL: https://issues.apache.org/jira/browse/SOLR-4278
 Project: Solr
  Issue Type: Bug
  Components: spellchecker
Reporter: Jack Krupansky


I issued a request to the /spell request handler with no misspellings, but the 
response still have a value of "false" for the "correctlySpelled" flag.

Using the Solr 4.0 example, I added some mini documents:

{code}
curl http://localhost:8983/solr/update?commit=true -H 
'Content-type:application/csv' -d '
id,name
spel-1,aardvark abacus ball bill cat cello
spel-2,abate accord band bell cattle check
spel-3,adorn border clean clock'
{code}

Then I issued this request to the /spell handler:

{code}
curl "http://localhost:8983/solr/spell/?q=abate&indent=true";
{code}

The response indicates that no corrections were needed, but the 
"correctlySpelled" flag is "false" when it should be "true".

{code}

  
false
  

{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-4277) Spellchecker sometimes falsely reports a spelling error and correction

[Jack Krupansky (JIRA)]

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

Jack Krupansky commented on SOLR-4277:
--

And for ironic humor, if I query for "check clock":

{code}
curl "http://localhost:8983/solr/spell/?q=check+clock&indent=true";
{code}

I am offered three corrected queries:

{code}
  

  1
  0
  5
  1
  

  clock
  1

  


  1
  6
  11
  1
  

  check
  1

  

false

  check check
  1
  
check
check
  


  clock clock
  1
  
clock
clock
  


  clock check
  2
  
clock
check
  

  
{code}


> Spellchecker sometimes falsely reports a spelling error and correction
> --
>
> Key: SOLR-4277
> URL: https://issues.apache.org/jira/browse/SOLR-4277
> Project: Solr
>  Issue Type: Bug
>  Components: SearchComponents - other
>Affects Versions: 4.0
>Reporter: Jack Krupansky
>
> In some cases, the Solr spell checker improperly reports query terms as being 
> misspelled.
> Using the Solr example for 4.0, I added these mini documents:
> {code}
> curl http://localhost:8983/solr/update?commit=true -H 
> 'Content-type:application/csv' -d '
> id,name
> spel-1,aardvark abacus ball bill cat cello
> spel-2,abate accord band bell cattle check
> spel-3,adorn border clean clock'
> {code}
> I then issued this request:
> {code}
> curl "http://localhost:8983/solr/spell/?q=check&indent=true";
> {code}
> The spell checker falsely concluded that "check" was misspelled and 
> improperly corrected it to "clock":
> {code}
> 
>   
> 
>   1
>   0
>   5
>   1
>   
> 
>   clock
>   1
> 
>   
> 
> false
> 
>   clock
>   1
>   
> clock
>   
> 
>   
> 
> {code}
> And if I query for "clock", it gets corrected to "check"!
> {code}
> curl "http://localhost:8983/solr/spell/?q=clock&indent=true";
> {code}
> {code}
>   
> 
>   1
>   0
>   5
>   1
>   
> 
>   check
>   1
> 
>   
> 
> false
> 
>   check
>   1
>   
> check
>   
> 
>   
> {code}
> Note: This appears to be only because "clock" is so close to "check". With 
> other terms I don't see the problem:
> {code}
> curl "http://localhost:8983/solr/spell/?q=cattle+abate+check&indent=true";
> {code}
> {code}
>   
> 
>   1
>   13
>   18
>   1
>   
> 
>   clock
>   1
> 
>   
> 
> false
> 
>   cattle abate clock
>   2
>   
> cattle
> abate
> clock
>   
> 
>   
> {code}
> Although, it inappropriately lists "cattle" and "abate" in the "misspellings" 
> section even though no suggestions were offered.
> Finally, I can workaround this issue by removing the following line from 
> solrconfig.xml:
> {code}
>   5
> {code}
> Which responds to the previous request with:
> {code}
>   
> false
>   
> {code}
> Which makes the original problem go away. Although, it does beg the question 
> as to why my 100% correct query is still tagged as "correctlySpelled" = 
> "false", but that's a separate Jira.

--
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] [Created] (SOLR-4277) Spellchecker sometimes falsely reports a spelling error and correction

[Jack Krupansky (JIRA)]

Jack Krupansky created SOLR-4277:


 Summary: Spellchecker sometimes falsely reports a spelling error 
and correction
 Key: SOLR-4277
 URL: https://issues.apache.org/jira/browse/SOLR-4277
 Project: Solr
  Issue Type: Bug
  Components: SearchComponents - other
Affects Versions: 4.0
Reporter: Jack Krupansky


In some cases, the Solr spell checker improperly reports query terms as being 
misspelled.

Using the Solr example for 4.0, I added these mini documents:

{code}
curl http://localhost:8983/solr/update?commit=true -H 
'Content-type:application/csv' -d '
id,name
spel-1,aardvark abacus ball bill cat cello
spel-2,abate accord band bell cattle check
spel-3,adorn border clean clock'
{code}

I then issued this request:

{code}
curl "http://localhost:8983/solr/spell/?q=check&indent=true";
{code}

The spell checker falsely concluded that "check" was misspelled and improperly 
corrected it to "clock":

{code}

  

  1
  0
  5
  1
  

  clock
  1

  

false

  clock
  1
  
clock
  

  

{code}

And if I query for "clock", it gets corrected to "check"!

{code}
curl "http://localhost:8983/solr/spell/?q=clock&indent=true";
{code}

{code}
  

  1
  0
  5
  1
  

  check
  1

  

false

  check
  1
  
check
  

  
{code}

Note: This appears to be only because "clock" is so close to "check". With 
other terms I don't see the problem:

{code}
curl "http://localhost:8983/solr/spell/?q=cattle+abate+check&indent=true";
{code}

{code}
  

  1
  13
  18
  1
  

  clock
  1

  

false

  cattle abate clock
  2
  
cattle
abate
clock
  

  
{code}

Although, it inappropriately lists "cattle" and "abate" in the "misspellings" 
section even though no suggestions were offered.

Finally, I can workaround this issue by removing the following line from 
solrconfig.xml:

{code}
  5
{code}

Which responds to the previous request with:

{code}
  
false
  
{code}

Which makes the original problem go away. Although, it does beg the question as 
to why my 100% correct query is still tagged as "correctlySpelled" = "false", 
but that's a separate Jira.

--
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-4661) Reduce default maxMerge/ThreadCount for ConcurrentMergeScheduler

[Commit Tag Bot (JIRA)]

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

Commit Tag Bot commented on LUCENE-4661:


[branch_4x commit] Michael McCandless
http://svn.apache.org/viewvc?view=revision&revision=1429617

LUCENE-4661: lower default maxThread/MergeCount in CMS


> Reduce default maxMerge/ThreadCount for ConcurrentMergeScheduler
> 
>
> Key: LUCENE-4661
> URL: https://issues.apache.org/jira/browse/LUCENE-4661
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 4.1, 5.0
>
>
> I think our current defaults (maxThreadCount=#cores/2,
> maxMergeCount=maxThreadCount+2) are too high ... I've frequently found
> merges falling behind and then slowing each other down when I index on
> a spinning-magnets drive.
> As a test, I indexed all of English Wikipedia with term-vectors (=
> heavy on merging), using 6 threads ... at the defaults
> (maxThreadCount=3, maxMergeCount=5, for my machine) it took 5288 sec
> to index & wait for merges & commit.  When I changed to
> maxThreadCount=1, maxMergeCount=2, indexing time sped up to 2902
> seconds (45% faster).  This is on a spinning-magnets disk... basically
> spinning-magnets disk don't handle the concurrent IO well.
> Then I tested an OCZ Vertex 3 SSD: at the current defaults it took
> 1494 seconds and at maxThreadCount=1, maxMergeCount=2 it took 1795 sec
> (20% slower).  Net/net the SSD can handle merge concurrency just fine.
> I think we should change the defaults: spinning magnet drives are hurt
> by the current defaults more than SSDs are helped ... apps that know
> their IO system is fast can always increase the merge concurrency.

--
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-4661) Reduce default maxMerge/ThreadCount for ConcurrentMergeScheduler

[Commit Tag Bot (JIRA)]

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

Commit Tag Bot commented on LUCENE-4661:


[trunk commit] Michael McCandless
http://svn.apache.org/viewvc?view=revision&revision=1429616

LUCENE-4661: lower default maxThread/MergeCount in CMS


> Reduce default maxMerge/ThreadCount for ConcurrentMergeScheduler
> 
>
> Key: LUCENE-4661
> URL: https://issues.apache.org/jira/browse/LUCENE-4661
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 4.1, 5.0
>
>
> I think our current defaults (maxThreadCount=#cores/2,
> maxMergeCount=maxThreadCount+2) are too high ... I've frequently found
> merges falling behind and then slowing each other down when I index on
> a spinning-magnets drive.
> As a test, I indexed all of English Wikipedia with term-vectors (=
> heavy on merging), using 6 threads ... at the defaults
> (maxThreadCount=3, maxMergeCount=5, for my machine) it took 5288 sec
> to index & wait for merges & commit.  When I changed to
> maxThreadCount=1, maxMergeCount=2, indexing time sped up to 2902
> seconds (45% faster).  This is on a spinning-magnets disk... basically
> spinning-magnets disk don't handle the concurrent IO well.
> Then I tested an OCZ Vertex 3 SSD: at the current defaults it took
> 1494 seconds and at maxThreadCount=1, maxMergeCount=2 it took 1795 sec
> (20% slower).  Net/net the SSD can handle merge concurrency just fine.
> I think we should change the defaults: spinning magnet drives are hurt
> by the current defaults more than SSDs are helped ... apps that know
> their IO system is fast can always increase the merge concurrency.

--
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-4661) Reduce default maxMerge/ThreadCount for ConcurrentMergeScheduler

[Michael McCandless (JIRA)]

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

Michael McCandless resolved LUCENE-4661.


   Resolution: Fixed
Fix Version/s: 5.0
   4.1

> Reduce default maxMerge/ThreadCount for ConcurrentMergeScheduler
> 
>
> Key: LUCENE-4661
> URL: https://issues.apache.org/jira/browse/LUCENE-4661
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 4.1, 5.0
>
>
> I think our current defaults (maxThreadCount=#cores/2,
> maxMergeCount=maxThreadCount+2) are too high ... I've frequently found
> merges falling behind and then slowing each other down when I index on
> a spinning-magnets drive.
> As a test, I indexed all of English Wikipedia with term-vectors (=
> heavy on merging), using 6 threads ... at the defaults
> (maxThreadCount=3, maxMergeCount=5, for my machine) it took 5288 sec
> to index & wait for merges & commit.  When I changed to
> maxThreadCount=1, maxMergeCount=2, indexing time sped up to 2902
> seconds (45% faster).  This is on a spinning-magnets disk... basically
> spinning-magnets disk don't handle the concurrent IO well.
> Then I tested an OCZ Vertex 3 SSD: at the current defaults it took
> 1494 seconds and at maxThreadCount=1, maxMergeCount=2 it took 1795 sec
> (20% slower).  Net/net the SSD can handle merge concurrency just fine.
> I think we should change the defaults: spinning magnet drives are hurt
> by the current defaults more than SSDs are helped ... apps that know
> their IO system is fast can always increase the merge concurrency.

--
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-4.x-Windows (64bit/jdk1.7.0_10) - Build # 2364 - Failure!

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 25680 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...
 [exec] 
 [exec] 
file:///build/docs/facet/org/apache/lucene/facet/taxonomy/class-use/CategoryPath.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec] 
 [exec] 
file:///build/docs/facet/org/apache/lucene/facet/taxonomy/writercache/cl2o/CategoryPathUtils.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec]   BROKEN LINK: 
file:///build/docs/core/org/apache/lucene/facet.taxonomy.writercache.cl2o.CharBlockArray.html
 [exec] 
 [exec] Broken javadocs links 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:242: 
The following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\common-build.xml:1960:
 exec returned: 1

Total time: 59 minutes 44 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: [JENKINS] Lucene-Solr-4.x-MacOSX (64bit/jdk1.7.0) - Build # 44 - Failure!

[Uwe Schindler]

Too funny. "Whats wrong with time this time?"(TM) - It restarts a new machine 
whenever the slave starts again after the windows builds are finished, so no 
crazy forwards going system time because NTP corrects it after virtual machine 
"save state" (how it was done before and still done on the windows slave).

@UweSays: Happy JVM crashing!

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de


> -Original Message-
> From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf
> Of Dawid Weiss
> Sent: Sunday, January 06, 2013 9:23 PM
> To: dev@lucene.apache.org
> Subject: Re: [JENKINS] Lucene-Solr-4.x-MacOSX (64bit/jdk1.7.0) - Build # 44 -
> Failure!
> 
> JVM error:
> 
> __commpage_gettimeofday
> 
> D.
> 
> On Sun, Jan 6, 2013 at 9:10 PM, Policeman Jenkins Server
>  wrote:
> > Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/44/
> > Java: 64bit/jdk1.7.0 -XX:+UseG1GC
> >
> > All tests passed
> >
> > Build Log:
> > [...truncated 937 lines...]
> > [junit4:junit4] ERROR: JVM J0 ended with an exception, command line:
> > /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre/bi
> > n/java -XX:+UseG1GC -XX:+HeapDumpOnOutOfMemoryError
> > -XX:HeapDumpPath=/Users/jenkins/jenkins-slave/workspace/Lucene-
> Solr-4.
> > x-MacOSX/heapdumps -Dtests.prefix=tests -
> Dtests.seed=AA329FDA58ED12D3
> > -Xmx512M -Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false
> > -Dtests.codec=random -Dtests.postingsformat=random
> > -Dtests.locale=random -Dtests.timezone=random -
> Dtests.directory=random
> > -Dtests.linedocsfile=europarl.lines.txt.gz
> > -Dtests.luceneMatchVersion=4.1 -Dtests.cleanthreads=perMethod
> > -Djava.util.logging.config.file=/Users/jenkins/jenkins-slave/workspace
> > /Lucene-Solr-4.x-MacOSX/lucene/tools/junit4/logging.properties
> > -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true
> > -Dtests.asserts.gracious=false -Dtests.multiplier=1 -DtempDir=.
> > -Djava.io.tmpdir=.
> > -Djunit4.tempDir=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.
> > x-MacOSX/lucene/build/core/test/temp
> > -Dclover.db.dir=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x
> > -MacOSX/lucene/build/clover/db
> > -Djava.security.manager=org.apache.lucene.util.TestSecurityManager
> > -Djava.security.policy=/Users/jenkins/jenkins-slave/workspace/Lucene-S
> > olr-4.x-MacOSX/lucene/tools/junit4/tests.policy
> > -Dlucene.version=4.1-SNAPSHOT -Djetty.testMode=1
> > -Djetty.insecurerandom=1
> > -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory
> > -Djava.awt.headless=true -classpath
> > /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-
> MacOSX/lucene/b
> > uild/test-framework/classes/java:/Users/jenkins/jenkins-slave/workspac
> > e/Lucene-Solr-4.x-MacOSX/lucene/build/codecs/classes/java:/Users/jenki
> > ns/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/test-
> framewor
> > k/lib/junit-4.10.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Sol
> > r-4.x-MacOSX/lucene/test-framework/lib/randomizedtesting-runner-
> 2.0.8.
> > jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/luce
> > ne/build/core/classes/java:/Users/jenkins/jenkins-slave/workspace/Luce
> > ne-Solr-4.x-MacOSX/lucene/build/core/classes/test:/Users/jenkins/jenki
> > ns-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-laun
> > cher.jar:/Users/jenkins/.ant/lib/ivy-2.2.0.jar:/Users/jenkins/jenkins-
> > slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-antlr.j
> > ar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation
> > /ANT_1.8.2/lib/ant-apache-bcel.jar:/Users/jenkins/jenkins-slave/tools/
> > hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-bsf.jar:/Use
> > rs/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.
> > 8.2/lib/ant-apache-log4j.jar:/Users/jenkins/jenkins-slave/tools/hudson
> > .tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-oro.jar:/Users/jen
> > kins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/li
> > b/ant-apache-regexp.jar:/Users/jenkins/jenkins-slave/tools/hudson.task
> > s.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-resolver.jar:/Users/jen
> > kins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/li
> > b/ant-apache-xalan2.jar:/Users/jenkins/jenkins-slave/tools/hudson.task
> > s.Ant_AntInstallation/ANT_1.8.2/lib/ant-commons-logging.jar:/Users/jen
> > kins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/li
> > b/ant-commons-net.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.
> > Ant_AntInstallation/ANT_1.8.2/lib/ant-jai.jar:/Users/jenkins/jenkins-s
> > lave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-javamail
> > .jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallati
> > on/ANT_1.8.2/lib/ant-jdepend.jar:/Users/jenkins/jenkins-slave/tools/hu
> > dson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jmf.jar:/Users/jenkin
> > s/jenkins-slave/tools/hudson.tas

Re: [JENKINS] Lucene-Solr-4.x-MacOSX (64bit/jdk1.7.0) - Build # 44 - Failure!

[Dawid Weiss]

JVM error:

__commpage_gettimeofday

D.

On Sun, Jan 6, 2013 at 9:10 PM, Policeman Jenkins Server
 wrote:
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/44/
> Java: 64bit/jdk1.7.0 -XX:+UseG1GC
>
> All tests passed
>
> Build Log:
> [...truncated 937 lines...]
> [junit4:junit4] ERROR: JVM J0 ended with an exception, command line: 
> /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre/bin/java 
> -XX:+UseG1GC -XX:+HeapDumpOnOutOfMemoryError 
> -XX:HeapDumpPath=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/heapdumps
>  -Dtests.prefix=tests -Dtests.seed=AA329FDA58ED12D3 -Xmx512M -Dtests.iters= 
> -Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random 
> -Dtests.postingsformat=random -Dtests.locale=random -Dtests.timezone=random 
> -Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz 
> -Dtests.luceneMatchVersion=4.1 -Dtests.cleanthreads=perMethod 
> -Djava.util.logging.config.file=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/tools/junit4/logging.properties
>  -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true 
> -Dtests.asserts.gracious=false -Dtests.multiplier=1 -DtempDir=. 
> -Djava.io.tmpdir=. 
> -Djunit4.tempDir=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/core/test/temp
>  
> -Dclover.db.dir=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/clover/db
>  -Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
> -Djava.security.policy=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/tools/junit4/tests.policy
>  -Dlucene.version=4.1-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 
> -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory 
> -Djava.awt.headless=true -classpath 
> /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/test-framework/classes/java:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/codecs/classes/java:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/test-framework/lib/junit-4.10.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/test-framework/lib/randomizedtesting-runner-2.0.8.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/core/classes/java:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/core/classes/test:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-launcher.jar:/Users/jenkins/.ant/lib/ivy-2.2.0.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-antlr.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-bcel.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-bsf.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-log4j.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-oro.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-regexp.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-resolver.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-xalan2.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-commons-logging.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-commons-net.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jai.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-javamail.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jdepend.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jmf.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jsch.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-junit.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-junit4.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-netrexx.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-swing.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-testutil.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/lib/tools.jar:/Users/jenkins/.ivy2/cache/com.carrotsearch.randomizedtesting/junit4-ant/jars/junit4-ant-2.0.8.jar
>  -ea:org.apache.lucene... -ea:org.apache.solr... 
> com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe -flush -eventsfile 
> /Users/jenkins/jenkins-slave/workspace/Lucene-Sol

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/44/
Java: 64bit/jdk1.7.0 -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 937 lines...]
[junit4:junit4] ERROR: JVM J0 ended with an exception, command line: 
/Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre/bin/java 
-XX:+UseG1GC -XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/heapdumps
 -Dtests.prefix=tests -Dtests.seed=AA329FDA58ED12D3 -Xmx512M -Dtests.iters= 
-Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random 
-Dtests.postingsformat=random -Dtests.locale=random -Dtests.timezone=random 
-Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz 
-Dtests.luceneMatchVersion=4.1 -Dtests.cleanthreads=perMethod 
-Djava.util.logging.config.file=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/tools/junit4/logging.properties
 -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true 
-Dtests.asserts.gracious=false -Dtests.multiplier=1 -DtempDir=. 
-Djava.io.tmpdir=. 
-Djunit4.tempDir=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/core/test/temp
 
-Dclover.db.dir=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/clover/db
 -Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
-Djava.security.policy=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/tools/junit4/tests.policy
 -Dlucene.version=4.1-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 
-Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory 
-Djava.awt.headless=true -classpath 
/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/test-framework/classes/java:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/codecs/classes/java:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/test-framework/lib/junit-4.10.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/test-framework/lib/randomizedtesting-runner-2.0.8.jar:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/core/classes/java:/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/core/classes/test:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-launcher.jar:/Users/jenkins/.ant/lib/ivy-2.2.0.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-antlr.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-bcel.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-bsf.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-log4j.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-oro.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-regexp.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-resolver.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-xalan2.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-commons-logging.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-commons-net.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jai.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-javamail.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jdepend.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jmf.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jsch.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-junit.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-junit4.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-netrexx.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-swing.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-testutil.jar:/Users/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/lib/tools.jar:/Users/jenkins/.ivy2/cache/com.carrotsearch.randomizedtesting/junit4-ant/jars/junit4-ant-2.0.8.jar
 -ea:org.apache.lucene... -ea:org.apache.solr... 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe -flush -eventsfile 
/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/core/test/temp/junit4-J0-20130106_200241_370.events
 
@/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/core/test/te

[jira] [Commented] (LUCENE-4659) Cleanup CategoryPath

[Commit Tag Bot (JIRA)]

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

Commit Tag Bot commented on LUCENE-4659:


[branch_4x commit] Shai Erera
http://svn.apache.org/viewvc?view=revision&revision=1429573

LUCENE-4659: Cleanup CategoryPath


> Cleanup CategoryPath
> 
>
> Key: LUCENE-4659
> URL: https://issues.apache.org/jira/browse/LUCENE-4659
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/facet
>Reporter: Shai Erera
>Assignee: Shai Erera
> Fix For: 4.1, 5.0
>
> Attachments: LUCENE-4659.patch, LUCENE-4659.patch, LUCENE-4659.patch
>
>
> CategoryPath is supposed to be a simple object which holds a category path's 
> components, and offers some utility methods that can be used during indexing 
> and search.
> Currently, it exposes lots of methods which aren't used, unless by tests - I 
> want to get rid of them. Also, the internal implementation manages 3 char[] 
> for holding the path components, while I think it would have been simpler if 
> it maintained a String[]. I'd like to explore that option too (the input is 
> anyway String, so why copy char[]?).
> Ultimately, I'd like CategoryPath to be immutable. I was able to get rid most 
> of the mutable methods. The ones that remain will probably go away when I 
> move from char[] to String[]. Immuntability is important because in various 
> places in the code we convert a CategoryPath back and forth to String, with 
> TODOs to stop doing that if CP was immutable.
> Will attach a patch that covers the first step - get rid of unneeded methods 
> and beginning to make it immutable.
> Perhaps this can be done in multiple commits?

--
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-4659) Cleanup CategoryPath

[Shai Erera (JIRA)]

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

Shai Erera resolved LUCENE-4659.


   Resolution: Fixed
Fix Version/s: 5.0
   4.1
Lucene Fields: New,Patch Available  (was: New)

Clarified more CatPath.components jdocs. Committed to trunk and 4x.

> Cleanup CategoryPath
> 
>
> Key: LUCENE-4659
> URL: https://issues.apache.org/jira/browse/LUCENE-4659
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/facet
>Reporter: Shai Erera
>Assignee: Shai Erera
> Fix For: 4.1, 5.0
>
> Attachments: LUCENE-4659.patch, LUCENE-4659.patch, LUCENE-4659.patch
>
>
> CategoryPath is supposed to be a simple object which holds a category path's 
> components, and offers some utility methods that can be used during indexing 
> and search.
> Currently, it exposes lots of methods which aren't used, unless by tests - I 
> want to get rid of them. Also, the internal implementation manages 3 char[] 
> for holding the path components, while I think it would have been simpler if 
> it maintained a String[]. I'd like to explore that option too (the input is 
> anyway String, so why copy char[]?).
> Ultimately, I'd like CategoryPath to be immutable. I was able to get rid most 
> of the mutable methods. The ones that remain will probably go away when I 
> move from char[] to String[]. Immuntability is important because in various 
> places in the code we convert a CategoryPath back and forth to String, with 
> TODOs to stop doing that if CP was immutable.
> Will attach a patch that covers the first step - get rid of unneeded methods 
> and beginning to make it immutable.
> Perhaps this can be done in multiple commits?

--
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-4659) Cleanup CategoryPath

[Commit Tag Bot (JIRA)]

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

Commit Tag Bot commented on LUCENE-4659:


[trunk commit] Shai Erera
http://svn.apache.org/viewvc?view=revision&revision=1429570

LUCENE-4659: Cleanup CategoryPath


> Cleanup CategoryPath
> 
>
> Key: LUCENE-4659
> URL: https://issues.apache.org/jira/browse/LUCENE-4659
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/facet
>Reporter: Shai Erera
>Assignee: Shai Erera
> Attachments: LUCENE-4659.patch, LUCENE-4659.patch, LUCENE-4659.patch
>
>
> CategoryPath is supposed to be a simple object which holds a category path's 
> components, and offers some utility methods that can be used during indexing 
> and search.
> Currently, it exposes lots of methods which aren't used, unless by tests - I 
> want to get rid of them. Also, the internal implementation manages 3 char[] 
> for holding the path components, while I think it would have been simpler if 
> it maintained a String[]. I'd like to explore that option too (the input is 
> anyway String, so why copy char[]?).
> Ultimately, I'd like CategoryPath to be immutable. I was able to get rid most 
> of the mutable methods. The ones that remain will probably go away when I 
> move from char[] to String[]. Immuntability is important because in various 
> places in the code we convert a CategoryPath back and forth to String, with 
> TODOs to stop doing that if CP was immutable.
> Will attach a patch that covers the first step - get rid of unneeded methods 
> and beginning to make it immutable.
> Perhaps this can be done in multiple commits?

--
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] [Comment Edited] (SOLR-4274) Solr logs loud exception when a client closes the connection before the response is sent

[Shawn Heisey (JIRA)]

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

Shawn Heisey edited comment on SOLR-4274 at 1/6/13 6:35 PM:


There is also a pair of exceptions logged to stderr by 3.5.0/jetty6, using the 
standard JUL binding.  No idea whether these can be shortened or eliminated.  I 
do not see the jetty exceptions on stderr with Solr 4.1 under Jetty 8, but on 
that deployment, I am using the log4j binding, which seems to grab a lot more 
logs, so it may be logged to Solr's log now.

  was (Author: elyograg):
There is also a pair of exceptions logged to stdout by jetty.  No idea 
whether these can be shortened or eliminated.
  
> Solr logs loud exception when a client closes the connection before the 
> response is sent
> 
>
> Key: SOLR-4274
> URL: https://issues.apache.org/jira/browse/SOLR-4274
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 3.5, 4.0
>Reporter: Shawn Heisey
> Fix For: 4.2, 5.0
>
>
> If a client closes the HTTP/TCP connection before Solr has had time to 
> respond, a loud Jetty exception is thrown and logged.  If possible, I would 
> like to see that reduced to a warning message that includes the request 
> parameters.

--
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-4274) Solr logs loud exception when a client closes the connection before the response is sent

[Shawn Heisey (JIRA)]

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

Shawn Heisey updated SOLR-4274:
---

Affects Version/s: 3.5

> Solr logs loud exception when a client closes the connection before the 
> response is sent
> 
>
> Key: SOLR-4274
> URL: https://issues.apache.org/jira/browse/SOLR-4274
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 3.5, 4.0
>Reporter: Shawn Heisey
> Fix For: 4.2, 5.0
>
>
> If a client closes the HTTP/TCP connection before Solr has had time to 
> respond, a loud Jetty exception is thrown and logged.  If possible, I would 
> like to see that reduced to a warning message that includes the request 
> parameters.

--
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: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #729: POMs out of sync

[Uwe Schindler]

When they placed it again, can we back them up, just to be safe?

 

-

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

  http://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Steve Rowe [mailto:sar...@gmail.com] 
Sent: Sunday, January 06, 2013 7:11 PM
To: dev@lucene.apache.org
Subject: Re: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #729: POMs out of sync

 

Someone from infra put the necessary credentials in ~/.m2/settings.xml at my 
request.  I'll ask them to do that again. 

In the future, rather than nuking all of ~/.m2/, you could just nuke 
~/.m2/repository/, which would leave settings.xml in place.

Steve

On Sun, Jan 6, 2013 at 12:54 PM, Uwe Schindler  wrote:

Hi,

I think that's my fault maybe. I nuked ~/.m2, because the maven repositories 
were fucked up. Did I delete the upload key by this?

Steven: How to fix this? We should place a backup for fast restoration in the 
home directory.


-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de


> -Original Message-

> From: Uwe Schindler [mailto:u...@thetaphi.de]
> Sent: Sunday, January 06, 2013 6:49 PM
> To: dev@lucene.apache.org
> Subject: RE: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #729: POMs out of
> sync
>
> It looks like Steven's upload certificate/key/whatever is no longer working.
> HTTP error 401 is "access denied", he upload of the maven artifacts was
> denied by the Apache Snapshot server. Maybe it is related to the LDAP
> problem @ ASF?
>
> Uwe
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
> > -Original Message-
> > From: Apache Jenkins Server [mailto:jenk...@builds.apache.org]
> > Sent: Sunday, January 06, 2013 6:45 PM
> > To: dev@lucene.apache.org
> > Subject: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #729: POMs out of
> > sync
> >
> > Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/729/
> >
> > No tests ran.
> >
> > Build Log:
> > [...truncated 127 lines...]
> >
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional
> commands, e-mail: dev-h...@lucene.apache.org


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

 

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

[Steve Rowe]

Someone from infra put the necessary credentials in ~/.m2/settings.xml at
my request.  I'll ask them to do that again.

In the future, rather than nuking all of ~/.m2/, you could just nuke
~/.m2/repository/, which would leave settings.xml in place.

Steve

On Sun, Jan 6, 2013 at 12:54 PM, Uwe Schindler  wrote:

> Hi,
>
> I think that's my fault maybe. I nuked ~/.m2, because the maven
> repositories were fucked up. Did I delete the upload key by this?
>
> Steven: How to fix this? We should place a backup for fast restoration in
> the home directory.
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
> > -Original Message-
> > From: Uwe Schindler [mailto:u...@thetaphi.de]
> > Sent: Sunday, January 06, 2013 6:49 PM
> > To: dev@lucene.apache.org
> > Subject: RE: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #729: POMs out of
> > sync
> >
> > It looks like Steven's upload certificate/key/whatever is no longer
> working.
> > HTTP error 401 is "access denied", he upload of the maven artifacts was
> > denied by the Apache Snapshot server. Maybe it is related to the LDAP
> > problem @ ASF?
> >
> > Uwe
> >
> > -
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> > http://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> >
> > > -Original Message-
> > > From: Apache Jenkins Server [mailto:jenk...@builds.apache.org]
> > > Sent: Sunday, January 06, 2013 6:45 PM
> > > To: dev@lucene.apache.org
> > > Subject: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #729: POMs out of
> > > sync
> > >
> > > Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/729/
> > >
> > > No tests ran.
> > >
> > > Build Log:
> > > [...truncated 127 lines...]
> > >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional
> > commands, e-mail: dev-h...@lucene.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

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

[Uwe Schindler]

Hi,

I think that's my fault maybe. I nuked ~/.m2, because the maven repositories 
were fucked up. Did I delete the upload key by this?

Steven: How to fix this? We should place a backup for fast restoration in the 
home directory.

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de


> -Original Message-
> From: Uwe Schindler [mailto:u...@thetaphi.de]
> Sent: Sunday, January 06, 2013 6:49 PM
> To: dev@lucene.apache.org
> Subject: RE: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #729: POMs out of
> sync
> 
> It looks like Steven's upload certificate/key/whatever is no longer working.
> HTTP error 401 is "access denied", he upload of the maven artifacts was
> denied by the Apache Snapshot server. Maybe it is related to the LDAP
> problem @ ASF?
> 
> Uwe
> 
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
> 
> 
> > -Original Message-
> > From: Apache Jenkins Server [mailto:jenk...@builds.apache.org]
> > Sent: Sunday, January 06, 2013 6:45 PM
> > To: dev@lucene.apache.org
> > Subject: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #729: POMs out of
> > sync
> >
> > Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/729/
> >
> > No tests ran.
> >
> > Build Log:
> > [...truncated 127 lines...]
> >
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional
> commands, e-mail: dev-h...@lucene.apache.org


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

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

[Uwe Schindler]

It looks like Steven's upload certificate/key/whatever is no longer working. 
HTTP error 401 is "access denied", he upload of the maven artifacts was denied 
by the Apache Snapshot server. Maybe it is related to the LDAP problem @ ASF?

Uwe

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de


> -Original Message-
> From: Apache Jenkins Server [mailto:jenk...@builds.apache.org]
> Sent: Sunday, January 06, 2013 6:45 PM
> To: dev@lucene.apache.org
> Subject: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #729: POMs out of
> sync
> 
> Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/729/
> 
> No tests ran.
> 
> Build Log:
> [...truncated 127 lines...]
> 



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

[jira] [Commented] (SOLR-4269) Core Object doesn't be checked when remove a core from coreToOrigName in coreContainer

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-4269:
---

Hey Po, just took a look and it seems this had already been fixed?

> Core Object doesn't be checked when remove a core from  coreToOrigName in 
> coreContainer
> ---
>
> Key: SOLR-4269
> URL: https://issues.apache.org/jira/browse/SOLR-4269
> Project: Solr
>  Issue Type: Bug
>  Components: multicore
>Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0
>Reporter: Po Rui
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4269.patch
>
>
> this bug lead a "No such core exists" exception never happen and the 
> exception replace by the NullPointerException from ConcurrentHashMap

--
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-4.x #205: POMs out of sync

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-4.x/205/

No tests ran.

Build Log:
[...truncated 102 lines...]



-
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 #729: POMs out of sync

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 127 lines...]



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

Re: [JENKINS-MAVEN] Lucene-Solr-Maven-4.x #203: POMs out of sync

[Steve Rowe]

Looks like it's reappeared: <
http://search.maven.org/#artifactdetails|org.eclipse.jetty|jetty-start|8.1.8.v20121106|jar
>

On Sat, Jan 5, 2013 at 7:01 PM, Uwe Schindler  wrote:

> The whole jetty folder disappeared in maven/ivy. No release anymore
> visible. Maybe a temporary problem.
>
> Uwe
>
>
>
> Apache Jenkins Server  schrieb:
>>
>> Build: https://builds.apache.org/job/Lucene-Solr-Maven-4.x/203/
>>
>> No tests ran.
>>
>> Build Log:
>> [...truncated 3801 lines...]
>>
>>
>>
>> --
>>
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
> --
> Uwe Schindler
> H.-H.-Meier-Allee 63, 28213 Bremen
> http://www.thetaphi.de
>

[jira] [Resolved] (SOLR-4276) Handling of string field is broken

[Thomas Beckers (JIRA)]

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

Thomas Beckers resolved SOLR-4276.
--

Resolution: Invalid

> Handling of string field is broken
> --
>
> Key: SOLR-4276
> URL: https://issues.apache.org/jira/browse/SOLR-4276
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis, search
>Affects Versions: 4.0
>Reporter: Thomas Beckers
>
> We upgraded from Solr 3.6 to Solr 4.0. Unfortunately the behaviour of how to 
> retrieve a document from the index by a unique key has apparently changed.
> In Solr 3.6 the following query retrieves a single document:
> bq. key:conf/socc/AscottS09
> But when using Solr 4.0 with the same document collection (re-indexed) an 
> empty result list is returned. It seems that Solr 4.0 is processing/analyzing 
> the term conf/socc/AscottS09 even though it is of type solr.StrField. The 
> query works as expected in Solr 4.0 when the term in enclosed in quotation 
> marks:
> bq. key:"conf/socc/AscottS09"
> schema.xml:
> {quote}
> ...
>  mitNorms="true"/>
> ...
>  multiValued="false" required="true"/>
> ...
> {quote}
> Is this a bug or have there been any changes on how Solr processes the string 
> field?
> The analyzer in the admin ui does it right. But when using the query field in 
> the admin ui with enabled debug mode it shows that the term gets analyzed and 
> tokenized:
> {quote}
> key:conf/socc/AscottS09 name="querystring">key:conf/socc/AscottS09 name="parsedquery">+key:conf +RegexpQuery(text:/socc/) +(+text:ascotts09 
> +text:ascott +text:s +text:09) name="parsedquery_toString">+key:conf +text:/socc/ +(+text:ascotts09 
> +text:ascott +text:s +text:09) {quote}
> see also: 
> http://stackoverflow.com/questions/13511969/solr-4-0-searching-in-string-field

--
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] [Comment Edited] (SOLR-4276) Handling of string field is broken

[Thomas Beckers (JIRA)]

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

Thomas Beckers edited comment on SOLR-4276 at 1/6/13 3:59 PM:
--

Thanks for the hint, we are already using this method but this was done in 
another component using Solr/Lucene 3.6. With updated dependencies the query 
tokens are escaped as expected.

  was (Author: problemzebra):
Thnaks for the hint, we are already using this method but this was done in 
another component using Solr/Lucene 3.6. With updated dependencies the query 
tokens are escaped as expected.
  
> Handling of string field is broken
> --
>
> Key: SOLR-4276
> URL: https://issues.apache.org/jira/browse/SOLR-4276
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis, search
>Affects Versions: 4.0
>Reporter: Thomas Beckers
>
> We upgraded from Solr 3.6 to Solr 4.0. Unfortunately the behaviour of how to 
> retrieve a document from the index by a unique key has apparently changed.
> In Solr 3.6 the following query retrieves a single document:
> bq. key:conf/socc/AscottS09
> But when using Solr 4.0 with the same document collection (re-indexed) an 
> empty result list is returned. It seems that Solr 4.0 is processing/analyzing 
> the term conf/socc/AscottS09 even though it is of type solr.StrField. The 
> query works as expected in Solr 4.0 when the term in enclosed in quotation 
> marks:
> bq. key:"conf/socc/AscottS09"
> schema.xml:
> {quote}
> ...
>  mitNorms="true"/>
> ...
>  multiValued="false" required="true"/>
> ...
> {quote}
> Is this a bug or have there been any changes on how Solr processes the string 
> field?
> The analyzer in the admin ui does it right. But when using the query field in 
> the admin ui with enabled debug mode it shows that the term gets analyzed and 
> tokenized:
> {quote}
> key:conf/socc/AscottS09 name="querystring">key:conf/socc/AscottS09 name="parsedquery">+key:conf +RegexpQuery(text:/socc/) +(+text:ascotts09 
> +text:ascott +text:s +text:09) name="parsedquery_toString">+key:conf +text:/socc/ +(+text:ascotts09 
> +text:ascott +text:s +text:09) {quote}
> see also: 
> http://stackoverflow.com/questions/13511969/solr-4-0-searching-in-string-field

--
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-4276) Handling of string field is broken

[Thomas Beckers (JIRA)]

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

Thomas Beckers commented on SOLR-4276:
--

Thnaks for the hint, we are already using this method but this was done in 
another component using Solr/Lucene 3.6. With updated dependencies the query 
tokens are escaped as expected.

> Handling of string field is broken
> --
>
> Key: SOLR-4276
> URL: https://issues.apache.org/jira/browse/SOLR-4276
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis, search
>Affects Versions: 4.0
>Reporter: Thomas Beckers
>
> We upgraded from Solr 3.6 to Solr 4.0. Unfortunately the behaviour of how to 
> retrieve a document from the index by a unique key has apparently changed.
> In Solr 3.6 the following query retrieves a single document:
> bq. key:conf/socc/AscottS09
> But when using Solr 4.0 with the same document collection (re-indexed) an 
> empty result list is returned. It seems that Solr 4.0 is processing/analyzing 
> the term conf/socc/AscottS09 even though it is of type solr.StrField. The 
> query works as expected in Solr 4.0 when the term in enclosed in quotation 
> marks:
> bq. key:"conf/socc/AscottS09"
> schema.xml:
> {quote}
> ...
>  mitNorms="true"/>
> ...
>  multiValued="false" required="true"/>
> ...
> {quote}
> Is this a bug or have there been any changes on how Solr processes the string 
> field?
> The analyzer in the admin ui does it right. But when using the query field in 
> the admin ui with enabled debug mode it shows that the term gets analyzed and 
> tokenized:
> {quote}
> key:conf/socc/AscottS09 name="querystring">key:conf/socc/AscottS09 name="parsedquery">+key:conf +RegexpQuery(text:/socc/) +(+text:ascotts09 
> +text:ascott +text:s +text:09) name="parsedquery_toString">+key:conf +text:/socc/ +(+text:ascotts09 
> +text:ascott +text:s +text:09) {quote}
> see also: 
> http://stackoverflow.com/questions/13511969/solr-4-0-searching-in-string-field

--
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-4265) Fix decoding of GET/POST parameters for servlet containers with non-UTF-8 URL parsing (Tomcat)

[Uwe Schindler (JIRA)]

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

Uwe Schindler resolved SOLR-4265.
-

   Resolution: Fixed
Fix Version/s: 5.0
   4.1

I fixed also the Solr Wiki pages of Tomcat, Glassfish,...

> Fix decoding of GET/POST parameters for servlet containers with non-UTF-8 URL 
> parsing (Tomcat)
> --
>
> Key: SOLR-4265
> URL: https://issues.apache.org/jira/browse/SOLR-4265
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 4.0
> Environment: Windows but, environment independent
>Reporter: Alex Rocher
>Assignee: Uwe Schindler
> Fix For: 4.1, 5.0
>
> Attachments: CropperCapture[4].png, CropperCapture[5].png, 
> CropperCapture[6].png, SOLR-4265.patch, SOLR-4265.patch, SOLR-4265.patch, 
> SOLR-4265.patch, SOLR-4265.patch, SOLR-4265.patch, 
> SolrDispatchFilter.java.patch
>
>
> When you type an accent (in french language for example) in the console query 
> tester, there's no charset conversion (servlet request charset conversion)
> Eg.: "même" is converted into it's ISO-8859-1 representation ==> fail
> The reason : getCharacterEncoding from HTTPRequest is not tested. Il it's 
> null, il will assume to convert an UTF-8 encoding charset.

--
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-4276) Handling of string field is broken

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-4276:


Solr 4.0 treats a forward slash as a special character - there's regex support 
now, and forward slashes are how those are delineated.  When you want a slash 
to be part of the query text, you have to escape it with a backslash.  If you 
send the following as your query, does it work?

key:conf\/socc\/AscottS09


> Handling of string field is broken
> --
>
> Key: SOLR-4276
> URL: https://issues.apache.org/jira/browse/SOLR-4276
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis, search
>Affects Versions: 4.0
>Reporter: Thomas Beckers
>
> We upgraded from Solr 3.6 to Solr 4.0. Unfortunately the behaviour of how to 
> retrieve a document from the index by a unique key has apparently changed.
> In Solr 3.6 the following query retrieves a single document:
> bq. key:conf/socc/AscottS09
> But when using Solr 4.0 with the same document collection (re-indexed) an 
> empty result list is returned. It seems that Solr 4.0 is processing/analyzing 
> the term conf/socc/AscottS09 even though it is of type solr.StrField. The 
> query works as expected in Solr 4.0 when the term in enclosed in quotation 
> marks:
> bq. key:"conf/socc/AscottS09"
> schema.xml:
> {quote}
> ...
>  mitNorms="true"/>
> ...
>  multiValued="false" required="true"/>
> ...
> {quote}
> Is this a bug or have there been any changes on how Solr processes the string 
> field?
> The analyzer in the admin ui does it right. But when using the query field in 
> the admin ui with enabled debug mode it shows that the term gets analyzed and 
> tokenized:
> {quote}
> key:conf/socc/AscottS09 name="querystring">key:conf/socc/AscottS09 name="parsedquery">+key:conf +RegexpQuery(text:/socc/) +(+text:ascotts09 
> +text:ascott +text:s +text:09) name="parsedquery_toString">+key:conf +text:/socc/ +(+text:ascotts09 
> +text:ascott +text:s +text:09) {quote}
> see also: 
> http://stackoverflow.com/questions/13511969/solr-4-0-searching-in-string-field

--
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-4265) Fix decoding of GET/POST parameters for servlet containers with non-UTF-8 URL parsing (Tomcat)

[Commit Tag Bot (JIRA)]

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

Commit Tag Bot commented on SOLR-4265:
--

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

Merged revision(s) 1429534 from lucene/dev/trunk:
SOLR-4265: Fix decoding of GET/POST parameters for servlet containers with 
non-UTF-8 URL parsing (Tomcat)


> Fix decoding of GET/POST parameters for servlet containers with non-UTF-8 URL 
> parsing (Tomcat)
> --
>
> Key: SOLR-4265
> URL: https://issues.apache.org/jira/browse/SOLR-4265
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 4.0
> Environment: Windows but, environment independent
>Reporter: Alex Rocher
>Assignee: Uwe Schindler
> Attachments: CropperCapture[4].png, CropperCapture[5].png, 
> CropperCapture[6].png, SOLR-4265.patch, SOLR-4265.patch, SOLR-4265.patch, 
> SOLR-4265.patch, SOLR-4265.patch, SOLR-4265.patch, 
> SolrDispatchFilter.java.patch
>
>
> When you type an accent (in french language for example) in the console query 
> tester, there's no charset conversion (servlet request charset conversion)
> Eg.: "même" is converted into it's ISO-8859-1 representation ==> fail
> The reason : getCharacterEncoding from HTTPRequest is not tested. Il it's 
> null, il will assume to convert an UTF-8 encoding charset.

--
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-4265) Fix decoding of GET/POST parameters for servlet containers with non-UTF-8 URL parsing (Tomcat)

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-4265:
-

OK, I committed the new stuff. I will now check and update Solr Wiki.

> Fix decoding of GET/POST parameters for servlet containers with non-UTF-8 URL 
> parsing (Tomcat)
> --
>
> Key: SOLR-4265
> URL: https://issues.apache.org/jira/browse/SOLR-4265
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 4.0
> Environment: Windows but, environment independent
>Reporter: Alex Rocher
>Assignee: Uwe Schindler
> Attachments: CropperCapture[4].png, CropperCapture[5].png, 
> CropperCapture[6].png, SOLR-4265.patch, SOLR-4265.patch, SOLR-4265.patch, 
> SOLR-4265.patch, SOLR-4265.patch, SOLR-4265.patch, 
> SolrDispatchFilter.java.patch
>
>
> When you type an accent (in french language for example) in the console query 
> tester, there's no charset conversion (servlet request charset conversion)
> Eg.: "même" is converted into it's ISO-8859-1 representation ==> fail
> The reason : getCharacterEncoding from HTTPRequest is not tested. Il it's 
> null, il will assume to convert an UTF-8 encoding charset.

--
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-4265) Fix decoding of GET/POST parameters for servlet containers with non-UTF-8 URL parsing (Tomcat)

[Commit Tag Bot (JIRA)]

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

Commit Tag Bot commented on SOLR-4265:
--

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

SOLR-4265: Fix decoding of GET/POST parameters for servlet containers with 
non-UTF-8 URL parsing (Tomcat)


> Fix decoding of GET/POST parameters for servlet containers with non-UTF-8 URL 
> parsing (Tomcat)
> --
>
> Key: SOLR-4265
> URL: https://issues.apache.org/jira/browse/SOLR-4265
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 4.0
> Environment: Windows but, environment independent
>Reporter: Alex Rocher
>Assignee: Uwe Schindler
> Attachments: CropperCapture[4].png, CropperCapture[5].png, 
> CropperCapture[6].png, SOLR-4265.patch, SOLR-4265.patch, SOLR-4265.patch, 
> SOLR-4265.patch, SOLR-4265.patch, SOLR-4265.patch, 
> SolrDispatchFilter.java.patch
>
>
> When you type an accent (in french language for example) in the console query 
> tester, there's no charset conversion (servlet request charset conversion)
> Eg.: "même" is converted into it's ISO-8859-1 representation ==> fail
> The reason : getCharacterEncoding from HTTPRequest is not tested. Il it's 
> null, il will assume to convert an UTF-8 encoding charset.

--
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: Search across a specified number of boundaries

[Erick Erickson]

Mike:

I'm _really_ stretching here, but you might be able to do something
interesting
with payloads. Say each word had a payload with the sentence number and
you _somehow_ made use of that information in a custom scorer. But like I
said, I really have no good idea how to accomplish that...

BTW, in future this kind of question is better asked on the user's list
(either
Lucene or Solr), this list if intended for discussing development work

Best
Erick

On Fri, Jan 4, 2013 at 1:02 PM, Mike Ree  wrote:

> d terms that are in nearby sentences.
>
> IE:
> "TermA NEAR3 TermB" would find all TermA's that are within 3 sentences of
> TermB.
>
> Have found ways to find TermA within same sentence
>

[jira] [Assigned] (SOLR-3900) LogWatcher Config Not Persisted

[Erick Erickson (JIRA)]

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

Erick Erickson reassigned SOLR-3900:


Assignee: Erick Erickson

> LogWatcher Config Not Persisted 
> 
>
> Key: SOLR-3900
> URL: https://issues.apache.org/jira/browse/SOLR-3900
> Project: Solr
>  Issue Type: Bug
>  Components: multicore
>Reporter: Michael Garski
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 4.2, 5.0
>
>
> When the solr.xml file is set to persistent="true", the logging element that 
> contains the LogWatcher configuration is not persisted to the new solr.xml 
> file that is written when managing the cores via core admin.

--
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-3900) LogWatcher Config Not Persisted

[Erick Erickson (JIRA)]

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

Erick Erickson reopened SOLR-3900:
--


Michael:

I'm re-opening this issue, since we'll be supporting solr.xml through the 4.x 
life cycle. There are a _lot_ of changes necessary for 4196 and this might well 
be lost if we don't have an open JIRA for it.

Treat the re-opening as a suggestion, feel free to re-close it if you think it 
should be.

> LogWatcher Config Not Persisted 
> 
>
> Key: SOLR-3900
> URL: https://issues.apache.org/jira/browse/SOLR-3900
> Project: Solr
>  Issue Type: Bug
>  Components: multicore
>Reporter: Michael Garski
>Priority: Minor
> Fix For: 4.2, 5.0
>
>
> When the solr.xml file is set to persistent="true", the logging element that 
> contains the LogWatcher configuration is not persisted to the new solr.xml 
> file that is written when managing the cores via core admin.

--
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-4265) Fix decoding of GET/POST parameters for servlet containers with non-UTF-8 URL parsing (Tomcat)

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated SOLR-4265:


Attachment: SOLR-4265.patch

Final patch for trunk, now committing it.

I added the new maximum formdata setting to example solrconfigs.

I also added some checks in the formdata request parser, so it fails when you 
have changed the solr webapplication and added an incompatible Filter before 
SolrDispatchFilter that calls Request#getParameter*() and causes the servlet 
container to incorrectly jump in.

> Fix decoding of GET/POST parameters for servlet containers with non-UTF-8 URL 
> parsing (Tomcat)
> --
>
> Key: SOLR-4265
> URL: https://issues.apache.org/jira/browse/SOLR-4265
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 4.0
> Environment: Windows but, environment independent
>Reporter: Alex Rocher
>Assignee: Uwe Schindler
> Attachments: CropperCapture[4].png, CropperCapture[5].png, 
> CropperCapture[6].png, SOLR-4265.patch, SOLR-4265.patch, SOLR-4265.patch, 
> SOLR-4265.patch, SOLR-4265.patch, SOLR-4265.patch, 
> SolrDispatchFilter.java.patch
>
>
> When you type an accent (in french language for example) in the console query 
> tester, there's no charset conversion (servlet request charset conversion)
> Eg.: "même" is converted into it's ISO-8859-1 representation ==> fail
> The reason : getCharacterEncoding from HTTPRequest is not tested. Il it's 
> null, il will assume to convert an UTF-8 encoding charset.

--
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-4663) IndexSearcher.document() should not be final

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-4663:


Attachment: LUCENE-4663.patch

Here's one possible patch: in 4.x we would just deprecate document(), with it 
still being final, just forwarding to the new non-final doc().


> IndexSearcher.document() should not be final
> 
>
> Key: LUCENE-4663
> URL: https://issues.apache.org/jira/browse/LUCENE-4663
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-4663.patch
>
>
> IndexSearcher has 3 methods:
> {noformat}
> StoredDocument doc(int)
> void doc(int, StoredFieldVisitor)
> final StoredDocument document(int, Set)
> {noformat}
> The last one is confusing for subclasses (e.g. SolrIndexSearcher) that 
> override these methods. for example that one has its own StoredDocument 
> doc(int, Set) method. 
> But now this means a user could always call the wrong method (this final 
> document() method) and get the wrong behavior (versus calling doc()).
> I think the name is also wrong. it should be doc() like the others.

--
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-4226) Extract fl parsing code out of ReturnFields constructor

[Robert Muir (JIRA)]

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

Robert Muir updated SOLR-4226:
--

Attachment: SOLR-4226.patch

Thanks Ryan: here's an updated patch. I added javadocs (since its a new 
abstract class). 

Also i just made all the members abstract: having some of the concrete stuff 
might be confusing to subclasses and cause strange things to happen (e.g. if 
they forget to set _wantsAllFields but returned null from getLuceneFieldNames). 
So I think this is less error-prone.

> Extract fl parsing code out of ReturnFields constructor
> ---
>
> Key: SOLR-4226
> URL: https://issues.apache.org/jira/browse/SOLR-4226
> Project: Solr
>  Issue Type: Improvement
>  Components: SearchComponents - other
>Affects Versions: 4.0
>Reporter: Ryan Ernst
>Assignee: Robert Muir
>Priority: Minor
> Attachments: SOLR-4226.patch, SOLR-4226.patch
>
>
> I would like to have my own QueryComponent, and have a more limited syntax 
> for return fields.  Unfortunately the ReturnFields constructor currently does 
> parsing.
> If we extract the parsing code into a static method of ReturnFields, then the 
> class can be a simple container, and I can have my alternate parsing code to 
> fill 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] [Created] (LUCENE-4663) IndexSearcher.document() should not be final

[Robert Muir (JIRA)]

Robert Muir created LUCENE-4663:
---

 Summary: IndexSearcher.document() should not be final
 Key: LUCENE-4663
 URL: https://issues.apache.org/jira/browse/LUCENE-4663
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir


IndexSearcher has 3 methods:

{noformat}
StoredDocument doc(int)
void doc(int, StoredFieldVisitor)
final StoredDocument document(int, Set)
{noformat}

The last one is confusing for subclasses (e.g. SolrIndexSearcher) that override 
these methods. for example that one has its own StoredDocument doc(int, Set) 
method. 

But now this means a user could always call the wrong method (this final 
document() method) and get the wrong behavior (versus calling doc()).

I think the name is also wrong. it should be doc() like the others.


--
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] (LUCENE-4655) Documentation of the StandardTokenizerInterface getNextToken() return value

[Uwe Schindler (JIRA)]

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

Uwe Schindler closed LUCENE-4655.
-

Resolution: Won't Fix
  Assignee: Uwe Schindler

No need to fix anything. The mentioned API is only public for cross-package 
usage, but marked as "internal". The Javadocs are copied from javacc.

> Documentation of the StandardTokenizerInterface getNextToken() return value
> ---
>
> Key: LUCENE-4655
> URL: https://issues.apache.org/jira/browse/LUCENE-4655
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 4.0, 3.6.2
>Reporter: Juha Haaga
>Assignee: Uwe Schindler
>Priority: Minor
>  Labels: docs
>
> Documentation of getNextToken() says that it returns an int, but incorrectly 
> states that it returns the next token. getNextToken doesn't return the next 
> token, it returns the numerical type of the next token that was found, as 
> defined by constants in the implementing class. That is also useful 
> information that can be taken advantage of in the filtering chain that 
> follows.

--
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: [JENKINS] Lucene-Solr-Tests-trunk-Java6 - Build # 15785 - Still Failing

[Uwe Schindler]

I fixed it already. Somehow some servers were missing artifacts (at sonatype 
and repo2.maven.org; those servers were missing Jetty artifacts completely) and 
also a lock file was in the way. I removed the whole ivy and maven caches on 
ASF Jenkins and now the builds are working again.

Uwe

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Robert Muir [mailto:rcm...@gmail.com]
> Sent: Sunday, January 06, 2013 1:55 PM
> To: dev@lucene.apache.org
> Subject: Re: [JENKINS] Lucene-Solr-Tests-trunk-Java6 - Build # 15785 - Still
> Failing
> 
> Looks like maven became corrumpted!
> 
> On Sun, Jan 6, 2013 at 6:10 AM, Apache Jenkins Server
>  wrote:
> > Build:
> > https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java6/15785/
> >
> > All tests passed
> >
> > Build Log:
> > [...truncated 7614 lines...]
> > BUILD FAILED
> > /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-
> Java6/build.xml:353: The following error occurred while executing this line:
> > /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-
> Java6/build.xml:39: The following error occurred while executing this line:
> > /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-
> Java6/solr/build.xml:178: The following error occurred while executing this
> line:
> > /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-
> Java6/solr/common-build.xml:428: The following error occurred while
> executing this line:
> > /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-
> Java6/solr/common-build.xml:378: The following error occurred while
> executing this line:
> > /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-
> Java6/solr/common-build.xml:329: The following error occurred while
> executing this line:
> > /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-
> Java6/solr/common-build.xml:349: The following error occurred while
> executing this line:
> > /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-
> Java6/solr/common-build.xml:387: The following error occurred while
> executing this line:
> > /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-
> Java6/solr/example/build.xml:57: impossible to resolve dependencies:
> > resolve failed - see output for details
> >
> > Total time: 31 minutes 17 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
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org


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

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

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-4.x/204/

No tests ran.

Build Log:
[...truncated 160 lines...]



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

Re: [JENKINS] Lucene-Solr-Tests-trunk-Java6 - Build # 15785 - Still Failing

[Robert Muir]

Looks like maven became corrumpted!

On Sun, Jan 6, 2013 at 6:10 AM, Apache Jenkins Server
 wrote:
> Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java6/15785/
>
> All tests passed
>
> Build Log:
> [...truncated 7614 lines...]
> BUILD FAILED
> /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/build.xml:353:
>  The following error occurred while executing this line:
> /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/build.xml:39:
>  The following error occurred while executing this line:
> /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/solr/build.xml:178:
>  The following error occurred while executing this line:
> /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/solr/common-build.xml:428:
>  The following error occurred while executing this line:
> /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/solr/common-build.xml:378:
>  The following error occurred while executing this line:
> /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/solr/common-build.xml:329:
>  The following error occurred while executing this line:
> /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/solr/common-build.xml:349:
>  The following error occurred while executing this line:
> /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/solr/common-build.xml:387:
>  The following error occurred while executing this line:
> /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/solr/example/build.xml:57:
>  impossible to resolve dependencies:
> resolve failed - see output for details
>
> Total time: 31 minutes 17 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

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

[JENKINS] Lucene-Solr-Tests-trunk-Java6 - Build # 15785 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java6/15785/

All tests passed

Build Log:
[...truncated 7614 lines...]
BUILD FAILED
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/build.xml:353:
 The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/build.xml:39:
 The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/solr/build.xml:178:
 The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/solr/common-build.xml:428:
 The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/solr/common-build.xml:378:
 The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/solr/common-build.xml:329:
 The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/solr/common-build.xml:349:
 The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/solr/common-build.xml:387:
 The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/solr/example/build.xml:57:
 impossible to resolve dependencies:
resolve failed - see output for details

Total time: 31 minutes 17 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

[jira] [Commented] (LUCENE-4659) Cleanup CategoryPath

[Gilad Barkai (JIRA)]

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

Gilad Barkai commented on LUCENE-4659:
--

Magnificent, +1 for commit.

> Cleanup CategoryPath
> 
>
> Key: LUCENE-4659
> URL: https://issues.apache.org/jira/browse/LUCENE-4659
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/facet
>Reporter: Shai Erera
>Assignee: Shai Erera
> Attachments: LUCENE-4659.patch, LUCENE-4659.patch, LUCENE-4659.patch
>
>
> CategoryPath is supposed to be a simple object which holds a category path's 
> components, and offers some utility methods that can be used during indexing 
> and search.
> Currently, it exposes lots of methods which aren't used, unless by tests - I 
> want to get rid of them. Also, the internal implementation manages 3 char[] 
> for holding the path components, while I think it would have been simpler if 
> it maintained a String[]. I'd like to explore that option too (the input is 
> anyway String, so why copy char[]?).
> Ultimately, I'd like CategoryPath to be immutable. I was able to get rid most 
> of the mutable methods. The ones that remain will probably go away when I 
> move from char[] to String[]. Immuntability is important because in various 
> places in the code we convert a CategoryPath back and forth to String, with 
> TODOs to stop doing that if CP was immutable.
> Will attach a patch that covers the first step - get rid of unneeded methods 
> and beginning to make it immutable.
> Perhaps this can be done in multiple commits?

--
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-Tests-4.x-Java6 - Build # 1201 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-4.x-Java6/1201/

All tests passed

Build Log:
[...truncated 7483 lines...]
BUILD FAILED
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/build.xml:353:
 The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/build.xml:39:
 The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/solr/build.xml:178:
 The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/solr/common-build.xml:428:
 The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/solr/common-build.xml:378:
 The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/solr/common-build.xml:329:
 The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/solr/common-build.xml:349:
 The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/solr/common-build.xml:387:
 The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/solr/example/build.xml:57:
 impossible to resolve dependencies:
resolve failed - see output for details

Total time: 33 minutes 1 second
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

[jira] [Updated] (SOLR-4276) Handling of string field is broken

[Thomas Beckers (JIRA)]

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

Thomas Beckers updated SOLR-4276:
-

Description: 
We upgraded from Solr 3.6 to Solr 4.0. Unfortunately the behaviour of how to 
retrieve a document from the index by a unique key has apparently changed.

In Solr 3.6 the following query retrieves a single document:

bq. key:conf/socc/AscottS09

But when using Solr 4.0 with the same document collection (re-indexed) an empty 
result list is returned. It seems that Solr 4.0 is processing/analyzing the 
term conf/socc/AscottS09 even though it is of type solr.StrField. The query 
works as expected in Solr 4.0 when the term in enclosed in quotation marks:

bq. key:"conf/socc/AscottS09"

schema.xml:
{quote}
{{...

...

...}}
{quote}
Is this a bug or have there been any changes on how Solr processes the string 
field?

The analyzer in the admin ui does it right. But when using the query field in 
the admin ui with enabled debug mode it shows that the term gets analyzed and 
tokenized:
{quote}
key:conf/socc/AscottS09key:conf/socc/AscottS09+key:conf +RegexpQuery(text:/socc/) +(+text:ascotts09 
+text:ascott +text:s +text:09)+key:conf 
+text:/socc/ +(+text:ascotts09 +text:ascott +text:s +text:09)http://stackoverflow.com/questions/13511969/solr-4-0-searching-in-string-field

  was:
We upgraded from Solr 3.6 to Solr 4.0. Unfortunately the behaviour of how to 
retrieve a document from the index by a unique key has apparently changed.

In Solr 3.6 the following query retrieves a single document:

bq. key:conf/socc/AscottS09

But when using Solr 4.0 with the same document collection (re-indexed) an empty 
result list is returned. It seems that Solr 4.0 is processing/analyzing the 
term conf/socc/AscottS09 even though it is of type solr.StrField. The query 
works as expected in Solr 4.0 when the term in enclosed in quotation marks:

bq. key:"conf/socc/AscottS09"

schema.xml:
{quote}
...

...

...
{quote}
Is this a bug or have there been any changes on how Solr processes the string 
field?

The analyzer in the admin ui does it right. But when using the query field in 
the admin ui with enabled debug mode it shows that the term gets analyzed and 
tokenized:
{quote}
key:conf/socc/AscottS09key:conf/socc/AscottS09+key:conf +RegexpQuery(text:/socc/) +(+text:ascotts09 
+text:ascott +text:s +text:09)+key:conf 
+text:/socc/ +(+text:ascotts09 +text:ascott +text:s +text:09)http://stackoverflow.com/questions/13511969/solr-4-0-searching-in-string-field


> Handling of string field is broken
> --
>
> Key: SOLR-4276
> URL: https://issues.apache.org/jira/browse/SOLR-4276
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis, search
>Affects Versions: 4.0
>Reporter: Thomas Beckers
>
> We upgraded from Solr 3.6 to Solr 4.0. Unfortunately the behaviour of how to 
> retrieve a document from the index by a unique key has apparently changed.
> In Solr 3.6 the following query retrieves a single document:
> bq. key:conf/socc/AscottS09
> But when using Solr 4.0 with the same document collection (re-indexed) an 
> empty result list is returned. It seems that Solr 4.0 is processing/analyzing 
> the term conf/socc/AscottS09 even though it is of type solr.StrField. The 
> query works as expected in Solr 4.0 when the term in enclosed in quotation 
> marks:
> bq. key:"conf/socc/AscottS09"
> schema.xml:
> {quote}
> {{...
>  mitNorms="true"/>
> ...
>  multiValued="false" required="true"/>
> ...}}
> {quote}
> Is this a bug or have there been any changes on how Solr processes the string 
> field?
> The analyzer in the admin ui does it right. But when using the query field in 
> the admin ui with enabled debug mode it shows that the term gets analyzed and 
> tokenized:
> {quote}
> key:conf/socc/AscottS09 name="querystring">key:conf/socc/AscottS09 name="parsedquery">+key:conf +RegexpQuery(text:/socc/) +(+text:ascotts09 
> +text:ascott +text:s +text:09) name="parsedquery_toString">+key:conf +text:/socc/ +(+text:ascotts09 
> +text:ascott +text:s +text:09) {quote}
> see also: 
> http://stackoverflow.com/questions/13511969/solr-4-0-searching-in-string-field

--
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-4276) Handling of string field is broken

[Thomas Beckers (JIRA)]

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

Thomas Beckers updated SOLR-4276:
-

Description: 
We upgraded from Solr 3.6 to Solr 4.0. Unfortunately the behaviour of how to 
retrieve a document from the index by a unique key has apparently changed.

In Solr 3.6 the following query retrieves a single document:

bq. key:conf/socc/AscottS09

But when using Solr 4.0 with the same document collection (re-indexed) an empty 
result list is returned. It seems that Solr 4.0 is processing/analyzing the 
term conf/socc/AscottS09 even though it is of type solr.StrField. The query 
works as expected in Solr 4.0 when the term in enclosed in quotation marks:

bq. key:"conf/socc/AscottS09"

schema.xml:
{quote}
...

...

...
{quote}
Is this a bug or have there been any changes on how Solr processes the string 
field?

The analyzer in the admin ui does it right. But when using the query field in 
the admin ui with enabled debug mode it shows that the term gets analyzed and 
tokenized:
{quote}
key:conf/socc/AscottS09key:conf/socc/AscottS09+key:conf +RegexpQuery(text:/socc/) +(+text:ascotts09 
+text:ascott +text:s +text:09)+key:conf 
+text:/socc/ +(+text:ascotts09 +text:ascott +text:s +text:09)http://stackoverflow.com/questions/13511969/solr-4-0-searching-in-string-field

  was:
We upgraded from Solr 3.6 to Solr 4.0. Unfortunately the behaviour of how to 
retrieve a document from the index by a unique key has apparently changed.

In Solr 3.6 the following query retrieves a single document:

bq. key:conf/socc/AscottS09

But when using Solr 4.0 with the same document collection (re-indexed) an empty 
result list is returned. It seems that Solr 4.0 is processing/analyzing the 
term conf/socc/AscottS09 even though it is of type solr.StrField. The query 
works as expected in Solr 4.0 when the term in enclosed in quotation marks:

bq. key:"conf/socc/AscottS09"

schema.xml:
{quote}
{{...

...

...}}
{quote}
Is this a bug or have there been any changes on how Solr processes the string 
field?

The analyzer in the admin ui does it right. But when using the query field in 
the admin ui with enabled debug mode it shows that the term gets analyzed and 
tokenized:
{quote}
key:conf/socc/AscottS09key:conf/socc/AscottS09+key:conf +RegexpQuery(text:/socc/) +(+text:ascotts09 
+text:ascott +text:s +text:09)+key:conf 
+text:/socc/ +(+text:ascotts09 +text:ascott +text:s +text:09)http://stackoverflow.com/questions/13511969/solr-4-0-searching-in-string-field


> Handling of string field is broken
> --
>
> Key: SOLR-4276
> URL: https://issues.apache.org/jira/browse/SOLR-4276
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis, search
>Affects Versions: 4.0
>Reporter: Thomas Beckers
>
> We upgraded from Solr 3.6 to Solr 4.0. Unfortunately the behaviour of how to 
> retrieve a document from the index by a unique key has apparently changed.
> In Solr 3.6 the following query retrieves a single document:
> bq. key:conf/socc/AscottS09
> But when using Solr 4.0 with the same document collection (re-indexed) an 
> empty result list is returned. It seems that Solr 4.0 is processing/analyzing 
> the term conf/socc/AscottS09 even though it is of type solr.StrField. The 
> query works as expected in Solr 4.0 when the term in enclosed in quotation 
> marks:
> bq. key:"conf/socc/AscottS09"
> schema.xml:
> {quote}
> ...
>  mitNorms="true"/>
> ...
>  multiValued="false" required="true"/>
> ...
> {quote}
> Is this a bug or have there been any changes on how Solr processes the string 
> field?
> The analyzer in the admin ui does it right. But when using the query field in 
> the admin ui with enabled debug mode it shows that the term gets analyzed and 
> tokenized:
> {quote}
> key:conf/socc/AscottS09 name="querystring">key:conf/socc/AscottS09 name="parsedquery">+key:conf +RegexpQuery(text:/socc/) +(+text:ascotts09 
> +text:ascott +text:s +text:09) name="parsedquery_toString">+key:conf +text:/socc/ +(+text:ascotts09 
> +text:ascott +text:s +text:09) {quote}
> see also: 
> http://stackoverflow.com/questions/13511969/solr-4-0-searching-in-string-field

--
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-4276) Handling of string field is broken

[Thomas Beckers (JIRA)]

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

Thomas Beckers updated SOLR-4276:
-

Description: 
We upgraded from Solr 3.6 to Solr 4.0. Unfortunately the behaviour of how to 
retrieve a document from the index by a unique key has apparently changed.

In Solr 3.6 the following query retrieves a single document:

bq. key:conf/socc/AscottS09

But when using Solr 4.0 with the same document collection (re-indexed) an empty 
result list is returned. It seems that Solr 4.0 is processing/analyzing the 
term conf/socc/AscottS09 even though it is of type solr.StrField. The query 
works as expected in Solr 4.0 when the term in enclosed in quotation marks:

bq. key:"conf/socc/AscottS09"

schema.xml:
{quote}
...

...

...
{quote}
Is this a bug or have there been any changes on how Solr processes the string 
field?

The analyzer in the admin ui does it right. But when using the query field in 
the admin ui with enabled debug mode it shows that the term gets analyzed and 
tokenized:
{quote}
key:conf/socc/AscottS09key:conf/socc/AscottS09+key:conf +RegexpQuery(text:/socc/) +(+text:ascotts09 
+text:ascott +text:s +text:09)+key:conf 
+text:/socc/ +(+text:ascotts09 +text:ascott +text:s +text:09)http://stackoverflow.com/questions/13511969/solr-4-0-searching-in-string-field

  was:
We upgraded from Solr 3.6 to Solr 4.0. Unfortunately the behaviour of how to 
retrieve a document from the index by a unique key has apparently changed.

In Solr 3.6 the following query retrieves a single document:

bq. key:conf/socc/AscottS09

But when using Solr 4.0 with the same document collection (re-indexed) an empty 
result list is returned. It seems that Solr 4.0 is processing/analyzing the 
term conf/socc/AscottS09 even though it is of type solr.StrField. The query 
works as expected in Solr 4.0 when the term in enclosed in quotation marks:

bq. key:"conf/socc/AscottS09"

schema.xml:
{quote}
...

...

...
{quote}
Is this a bug or have there been any changes on how Solr processes the string 
field?


see also: 
http://stackoverflow.com/questions/13511969/solr-4-0-searching-in-string-field


> Handling of string field is broken
> --
>
> Key: SOLR-4276
> URL: https://issues.apache.org/jira/browse/SOLR-4276
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis, search
>Affects Versions: 4.0
>Reporter: Thomas Beckers
>
> We upgraded from Solr 3.6 to Solr 4.0. Unfortunately the behaviour of how to 
> retrieve a document from the index by a unique key has apparently changed.
> In Solr 3.6 the following query retrieves a single document:
> bq. key:conf/socc/AscottS09
> But when using Solr 4.0 with the same document collection (re-indexed) an 
> empty result list is returned. It seems that Solr 4.0 is processing/analyzing 
> the term conf/socc/AscottS09 even though it is of type solr.StrField. The 
> query works as expected in Solr 4.0 when the term in enclosed in quotation 
> marks:
> bq. key:"conf/socc/AscottS09"
> schema.xml:
> {quote}
> ...
>  mitNorms="true"/>
> ...
>  multiValued="false" required="true"/>
> ...
> {quote}
> Is this a bug or have there been any changes on how Solr processes the string 
> field?
> The analyzer in the admin ui does it right. But when using the query field in 
> the admin ui with enabled debug mode it shows that the term gets analyzed and 
> tokenized:
> {quote}
> key:conf/socc/AscottS09 name="querystring">key:conf/socc/AscottS09 name="parsedquery">+key:conf +RegexpQuery(text:/socc/) +(+text:ascotts09 
> +text:ascott +text:s +text:09) name="parsedquery_toString">+key:conf +text:/socc/ +(+text:ascotts09 
> +text:ascott +text:s +text:09) {quote}
> see also: 
> http://stackoverflow.com/questions/13511969/solr-4-0-searching-in-string-field

--
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] [Created] (SOLR-4276) Handling of string field is broken

[Thomas Beckers (JIRA)]

Thomas Beckers created SOLR-4276:


 Summary: Handling of string field is broken
 Key: SOLR-4276
 URL: https://issues.apache.org/jira/browse/SOLR-4276
 Project: Solr
  Issue Type: Bug
  Components: Schema and Analysis, search
Affects Versions: 4.0
Reporter: Thomas Beckers


We upgraded from Solr 3.6 to Solr 4.0. Unfortunately the behaviour of how to 
retrieve a document from the index by a unique key has apparently changed.

In Solr 3.6 the following query retrieves a single document:

bq. key:conf/socc/AscottS09

But when using Solr 4.0 with the same document collection (re-indexed) an empty 
result list is returned. It seems that Solr 4.0 is processing/analyzing the 
term conf/socc/AscottS09 even though it is of type solr.StrField. The query 
works as expected in Solr 4.0 when the term in enclosed in quotation marks:

bq. key:"conf/socc/AscottS09"

schema.xml:
{quote}
...

...

...
{quote}
Is this a bug or have there been any changes on how Solr processes the string 
field?


see also: 
http://stackoverflow.com/questions/13511969/solr-4-0-searching-in-string-field

--
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-4659) Cleanup CategoryPath

[Shai Erera (JIRA)]

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

Shai Erera updated LUCENE-4659:
---

Attachment: LUCENE-4659.patch

bq. copyFullPath() - numCharsCopied is redundant?

You're right. Fixed

bq. perhaps use only one index rather than both index j and i?

Yup. It was a leftover from the previous patch, when I had start offset in CP.

bq. Also, CPs are more likely to be different at the end, than in the start 
(e.g further away from the root than the dimension) - perhaps iterate in 
reverse (up the tree)

Done.

> Cleanup CategoryPath
> 
>
> Key: LUCENE-4659
> URL: https://issues.apache.org/jira/browse/LUCENE-4659
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/facet
>Reporter: Shai Erera
>Assignee: Shai Erera
> Attachments: LUCENE-4659.patch, LUCENE-4659.patch, LUCENE-4659.patch
>
>
> CategoryPath is supposed to be a simple object which holds a category path's 
> components, and offers some utility methods that can be used during indexing 
> and search.
> Currently, it exposes lots of methods which aren't used, unless by tests - I 
> want to get rid of them. Also, the internal implementation manages 3 char[] 
> for holding the path components, while I think it would have been simpler if 
> it maintained a String[]. I'd like to explore that option too (the input is 
> anyway String, so why copy char[]?).
> Ultimately, I'd like CategoryPath to be immutable. I was able to get rid most 
> of the mutable methods. The ones that remain will probably go away when I 
> move from char[] to String[]. Immuntability is important because in various 
> places in the code we convert a CategoryPath back and forth to String, with 
> TODOs to stop doing that if CP was immutable.
> Will attach a patch that covers the first step - get rid of unneeded methods 
> and beginning to make it immutable.
> Perhaps this can be done in multiple commits?

--
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-4659) Cleanup CategoryPath

[Gilad Barkai (JIRA)]

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

Gilad Barkai commented on LUCENE-4659:
--

Patch looks really good.

I'm not concerned about the new objects for subPath. Actually, since the 
{{HashMap}} s are now against {{CategoryPath}} and it's not constantly being 
translated to/from {{String}} I'm looking forward a better performance than 
before.

Nice job, and a nasty one that must have been.. 
Chapeau à lui!

A few (minor) comments:
* {{copyFullPath()}} - {{numCharsCopied}} is redundant? The return value could 
have been {{(idx + component[upto].length() - start)}} 
* {{equals()}} line 143 - perhaps use only one index rather than both index 
{{j}} and {{i}} ? Also, CPs are more likely to be different at the end, than in 
the start (e.g further away from the root than the dimension) - perhaps iterate 
in reverse (up the tree)?

> Cleanup CategoryPath
> 
>
> Key: LUCENE-4659
> URL: https://issues.apache.org/jira/browse/LUCENE-4659
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/facet
>Reporter: Shai Erera
>Assignee: Shai Erera
> Attachments: LUCENE-4659.patch, LUCENE-4659.patch
>
>
> CategoryPath is supposed to be a simple object which holds a category path's 
> components, and offers some utility methods that can be used during indexing 
> and search.
> Currently, it exposes lots of methods which aren't used, unless by tests - I 
> want to get rid of them. Also, the internal implementation manages 3 char[] 
> for holding the path components, while I think it would have been simpler if 
> it maintained a String[]. I'd like to explore that option too (the input is 
> anyway String, so why copy char[]?).
> Ultimately, I'd like CategoryPath to be immutable. I was able to get rid most 
> of the mutable methods. The ones that remain will probably go away when I 
> move from char[] to String[]. Immuntability is important because in various 
> places in the code we convert a CategoryPath back and forth to String, with 
> TODOs to stop doing that if CP was immutable.
> Will attach a patch that covers the first step - get rid of unneeded methods 
> and beginning to make it immutable.
> Perhaps this can be done in multiple commits?

--
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-4659) Cleanup CategoryPath

[Shai Erera (JIRA)]

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

Shai Erera updated LUCENE-4659:
---

Attachment: LUCENE-4659.patch

More cleanup. Here's a summary of all the changes:

* CategoryPath is now immutable. As such it does not implement Cloneable and 
clone() is removed.

* CategoryPath.add is removed - used only by tests, and they were converted to 
use alternative methods, e.g. subpath().

* CategoryPath.subpath returns a sub-path of the CategoryPath (used to traverse 
parents)

* CategoryPath exposes two public final 'components' and 'length' members. This 
removed the length() and getComponent() methods (getComponent was only used in 
test). I added jdocs to these two members.

* CategoryPath no longer implements Serializable.

* CategoryPath.\*serialize\* methods moved to CategoryPathUtils under the cl2o 
package, as it's the only one that uses them.

* All 'prefixLen' variants were removed. Instead one should call 
cp.subpath(prefix).
** This allowed removing all prefixLen variants from TaxoWriterCache, and nuke 
3 duplicate methods in DirTaxoWriter.

* Handled a TODO in DirTaxoReader - since now CategoryPath is immutable, it can 
hold caches to-from CategoryPath instead of String.

CategoryPath is now 215 lines, instead of ~1100 !

> Cleanup CategoryPath
> 
>
> Key: LUCENE-4659
> URL: https://issues.apache.org/jira/browse/LUCENE-4659
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/facet
>Reporter: Shai Erera
>Assignee: Shai Erera
> Attachments: LUCENE-4659.patch, LUCENE-4659.patch
>
>
> CategoryPath is supposed to be a simple object which holds a category path's 
> components, and offers some utility methods that can be used during indexing 
> and search.
> Currently, it exposes lots of methods which aren't used, unless by tests - I 
> want to get rid of them. Also, the internal implementation manages 3 char[] 
> for holding the path components, while I think it would have been simpler if 
> it maintained a String[]. I'd like to explore that option too (the input is 
> anyway String, so why copy char[]?).
> Ultimately, I'd like CategoryPath to be immutable. I was able to get rid most 
> of the mutable methods. The ones that remain will probably go away when I 
> move from char[] to String[]. Immuntability is important because in various 
> places in the code we convert a CategoryPath back and forth to String, with 
> TODOs to stop doing that if CP was immutable.
> Will attach a patch that covers the first step - get rid of unneeded methods 
> and beginning to make it immutable.
> Perhaps this can be done in multiple commits?

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