[JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 65780 - Still Failing!

[builder]

Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/65780/

No tests ran.

Build Log:
[...truncated 7 lines...]
ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/trunk
org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS 
/repos/asf/lucene/dev/trunk failed
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:379)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:364)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:708)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:628)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:103)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1018)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148)
at 
org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339)
at 
org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328)
at 
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482)
at 
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364)
at 
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274)
at 
org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27)
at 
org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11)
at 
org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
at 
org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:291)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387)
at 
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:153)
at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:903)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:884)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:867)
at hudson.FilePath.act(FilePath.java:916)
at hudson.FilePath.act(FilePath.java:889)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:843)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:781)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1411)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:657)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:562)
at hudson.model.Run.execute(Run.java:1665)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:246)
Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97)
... 38 more
Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request 
failed on '/repos/asf/lucene/dev/trunk'
svn: E175002: Connection reset
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:754)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373)
... 37 more
Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk'
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:752)
... 38 more
Caused by: svn: E175002: Connection reset
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:109)
at 
org.tmateso

[JENKINS] Lucene-4x-Linux-Java7-64-test-only - Build # 2094 - Failure!

[builder]

Build: builds.flonkings.com/job/Lucene-4x-Linux-Java7-64-test-only/2094/

No tests ran.

Build Log:
[...truncated 13 lines...]
ERROR: Failed to update 
http://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x
org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS 
/repos/asf/lucene/dev/branches/branch_4x failed
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:379)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:364)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:708)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:628)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:103)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1018)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148)
at 
org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339)
at 
org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328)
at 
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482)
at 
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364)
at 
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274)
at 
org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27)
at 
org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11)
at 
org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
at 
org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:291)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387)
at 
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:153)
at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:903)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:884)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:867)
at hudson.FilePath.act(FilePath.java:916)
at hudson.FilePath.act(FilePath.java:889)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:843)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:781)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1411)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:657)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:562)
at hudson.model.Run.execute(Run.java:1665)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:246)
Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_4x failed
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97)
... 38 more
Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request 
failed on '/repos/asf/lucene/dev/branches/branch_4x'
svn: E175002: Connection reset
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:754)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373)
... 37 more
Caused by: svn: E175002: OPTIONS request failed on 
'/repos/asf/lucene/dev/branches/branch_4x'
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:752)
... 38 more
Caused by: svn: E175002: Connection reset
at 
org.tmatesoft.svn.core.SVNError

Re: DocValue on Strings slow and OOM

[Per Steffensen]

Thanks for all the help, guys!

Just to clarify. Everything is working functionality-wise - we have 
tests showing that.


It is just that two similar queries (hitting the same number of rows 
(only 6 among 12billion in this example) and resulting in the same 
number of facet-groups etc etc) is performing very differently depending 
on the type of the facet.field. It is fast (< 2 secs) and efficient when 
the facet.field is
stored="true" required="true" docValues="true"/>
positionIncrementGap="0" docValuesFormat="Disk"/>
But it is very slow (> 100 secs) and memory-consuming (eating GBs) when 
the facet.field is
stored="true" required="true" docValues="true"/>
sortMissingLast="true" docValuesFormat="Disk"/>


We use docValuesFormat="Disk" because we have so much data, that 
everything will never fit in memory. Are you saying that this does not 
work before 4.5? But how does it explain the huge difference in 
response-time and memory-consumption? Guess, if it does not work in 4.4, 
that it does not work for neither of the types?
Just a side-question: We never have more than one value per field. Would 
we benefit from adding multiValued=false to our field-declarations?


Regards, Per Steffensen

On 11/5/13 11:44 PM, Shawn Heisey wrote:

On 11/5/2013 11:56 AM, Erick Erickson wrote:

Hmmm, what I'm referring to is this bit:

|<||fieldType||name||=||"string_ondisk"||class||=||"solr.StrField"||docValuesFormat||=||"Disk"||/>| 


|
|
|The docValuesFormat="Disk" bit isn't supported until 4.5, which 
doesn't seem clear in either place. Feel free to disagree of course :).|






I'm pretty sure that the disk format was supported from 4.2, when 
docvalues first came to Solr.  Not sure about earlier.  Here's someone 
with it working on 4.2.1:


http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201304.mbox/%3c51766344.5060...@gmail.com%3E 



Something that wasn't supported that far back (and as far as I know 
still isn't supported) is upgrading Solr with an existing index that 
uses the disk format.


Thanks,
Shawn


-
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] Lucene-Solr-trunk-MacOSX (64bit/jdk1.7.0) - Build # 987 - Still Failing!

[Rory O'Donnell Oracle, Dublin Ireland]

Hi Uwe,Dawid,

Let us know when you have logged a bug report.

Rgds,Rory

On 05/11/2013 23:03, Uwe Schindler wrote:

One more time this one.

 From my analysis, this happens while creating a String for initializing an IOException from the value of 
errno. It looks like while running those Solr tests, some unexpected I/O error with non-standard 
"errno" occurs, and this MacOS "errno" cannot be converted to a String and is left in the 
C++ code as "NULL", causing the SEGV.

I wanted to open Oracle bug report already, but was out of office. I made the 
Jenkins build sticky, so it does not get removed.

Uwe

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



-Original Message-
From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de]
Sent: Tuesday, November 05, 2013 11:56 PM
To: dev@lucene.apache.org; er...@apache.org; dwe...@apache.org
Subject: [JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.7.0) - Build # 987 -
Still Failing!

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

All tests passed

Build Log:
[...truncated 10230 lines...]
[junit4] JVM J0: stdout was not empty, see:
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-
core/test/temp/junit4-J0-20131105_223228_067.sysout
[junit4] >>> JVM J0: stdout (verbatim) 
[junit4] #
[junit4] # A fatal error has been detected by the Java Runtime
Environment:
[junit4] #
[junit4] #  SIGSEGV (0xb) at pc=0x00010d550a20, pid=187, tid=57963
[junit4] #
[junit4] # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18)
(build 1.7.0_45-b18)
[junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed
mode bsd-amd64 compressed oops)
[junit4] # Problematic frame:
[junit4] # C  [libjava.dylib+0x9a20]  JNU_NewStringPlatform+0x1c8
[junit4] #
[junit4] # Failed to write core dump. Core dumps have been disabled. To
enable core dumping, try "ulimit -c unlimited" before starting Java again
[junit4] #
[junit4] # An error report file with more information is saved as:
[junit4] # /Users/jenkins/workspace/Lucene-Solr-trunk-
MacOSX/solr/build/solr-core/test/J0/hs_err_pid187.log
[junit4] #
[junit4] # If you would like to submit a bug report, please visit:
[junit4] #   http://bugreport.sun.com/bugreport/crash.jsp
[junit4] # The crash happened outside the Java Virtual Machine in native
code.
[junit4] # See problematic frame for where to report the bug.
[junit4] #
[junit4] <<< JVM J0: EOF 

[...truncated 1 lines...]
[junit4] ERROR: JVM J0 ended with an exception, command line:
/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/bin/
java -XX:+UseCompressedOops -XX:+UseSerialGC -
XX:+HeapDumpOnOutOfMemoryError -
XX:HeapDumpPath=/Users/jenkins/workspace/Lucene-Solr-trunk-
MacOSX/heapdumps -Dtests.prefix=tests -Dtests.seed=5BE8F74D3D7CF604 -
Xmx512M -Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false -
Dtests.codec=random -Dtests.postingsformat=random -
Dtests.docvaluesformat=random -Dtests.locale=random -
Dtests.timezone=random -Dtests.directory=random -
Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=5.0 -
Dtests.cleanthreads=perClass -
Djava.util.logging.config.file=/Users/jenkins/workspace/Lucene-Solr-trunk-
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/workspace/Lucene-Solr-trunk-
MacOSX/solr/build/solr-core/test/temp -
Dclover.db.dir=/Users/jenkins/workspace/Lucene-Solr-trunk-
MacOSX/lucene/build/clover/db -
Djava.security.manager=org.apache.lucene.util.TestSecurityManager -
Djava.security.policy=/Users/jenkins/workspace/Lucene-Solr-trunk-
MacOSX/lucene/tools/junit4/tests.policy -Dlucene.version=5.0-SNAPSHOT -
Djetty.testMode=1 -Djetty.insecurerandom=1 -
Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory -
Djava.awt.headless=true -Dtests.disableHdfs=true -classpath
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-
core/classes/test:/Users/jenkins/workspace/Lucene-Solr-trunk-
MacOSX/solr/build/solr-test-
framework/classes/java:/Users/jenkins/workspace/Lucene-Solr-trunk-
MacOSX/solr/test-framework/lib/junit4-ant-
2.0.13.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-
MacOSX/solr/build/solr-core/test-files:/Users/jenkins/workspace/Lucene-
Solr-trunk-MacOSX/lucene/build/test-
framework/classes/java:/Users/jenkins/workspace/Lucene-Solr-trunk-
MacOSX/lucene/build/codecs/classes/java:/Users/jenkins/workspace/Lucen
e-Solr-trunk-MacOSX/solr/build/solr-
solrj/classes/java:/Users/jenkins/workspace/Lucene-Solr-trunk-
MacOSX/solr/build/solr-
core/classes/java:/Users/jenkins/workspace/Lucene-Solr-trunk-
MacOSX/lucene/build/analysis/common/lucene-analyzers-common-5.0-
SNAPSH

[jira] [Commented] (SOLR-5378) Suggester Version 2

[Alexey Serba (JIRA)]

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

Alexey Serba commented on SOLR-5378:


{quote}
In addition to this, this suggester version should also have support for 
distributed support, which was awkward at best with the previous implementation 
due to SpellCheck requirements.
{quote}
It seems that it is required to have _query_ component registered in a request 
handler for _suggester_ component to work correctly in distributed mode. Try to 
change last-components=suggest to components=suggest in solrconfig and I 
believe it won't work.

I'm wondering what are the performance implications of having query (and 
others) components in a suggest request handler?

> Suggester Version 2
> ---
>
> Key: SOLR-5378
> URL: https://issues.apache.org/jira/browse/SOLR-5378
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Areek Zillur
> Attachments: SOLR-5378.patch, SOLR-5378.patch, SOLR-5378.patch, 
> SOLR-5378.patch, SOLR-5378.patch
>
>
> The idea is to add a new Suggester Component that will eventually replace the 
> Suggester support through the SpellCheck Component.
> This will enable Solr to fully utilize the Lucene suggester module (along 
> with supporting most of the existing features) in the following ways:
>- Dictionary pluggability (give users the option to choose the dictionary 
> implementation to use for their suggesters to consume)
>- Map the suggester options/ suggester result format (e.g. support for 
> payload)
>- The new Component will also allow us to have "beefier" Lookup support 
> instead of resorting to collation and such. (Move computation from query time 
> to index time) with more freedom
> In addition to this, this suggester version should also have support for 
> distributed support, which was awkward at best with the previous 
> implementation due to SpellCheck requirements.
> Config (index time) options:
>   - name - name of suggester
>   - sourceLocation - external file location (for file-based suggesters)
>   - lookupImpl - type of lookup to use [default JaspellLookupFactory]
>   - dictionaryImpl - type of dictionary to use (lookup input) [default
> (sourceLocation == null ? HighFrequencyDictionaryFactory : 
> FileDictionaryFactory)]
>   - storeDir - location to store in-memory data structure in disk
>   - buildOnCommit - command to build suggester for every commit
>   - buildOnOptimize - command to build suggester for every optimize
> Query time options:
>   - suggest.dictionary - name of suggester to use
>   - suggest.count - number of suggestions to return
>   - suggest.q - query to use for lookup
>   - suggest.build - command to build the suggester
>   - suggest.reload - command to reload the suggester
> Example query:
> {code}
> http://localhost:8983/solr/suggest?suggest.dictionary=mySuggester&suggest=true&suggest.build=true&suggest.q=elec
> {code}
> Distributed query:
> {code}
> http://localhost:7574/solr/suggest?suggest.dictionary=mySuggester&suggest=true&suggest.build=true&suggest.q=elec&shards=localhost:8983/solr,localhost:7574/solr&shards.qt=/suggest
> {code}
> Example Response:
> {code}
> 
>   
> 0
> 28
>   
>   build
>   
>   
> 
>   
> 2
> 
>   electronics and computer1
>   2199
>   
> 
> 
>   electronics
>   649
>   
> 
>   
> 
>   
> 
> {code}
> Example config file:
>- Using DocumentDictionary and FuzzySuggester 
>-- Suggestion on product_name sorted by popularity with the additional 
> product_id in the payload
> {code}  
>   
>   
> suggest_fuzzy_doc_dict
> FuzzyLookupFactory
> DocumentDictionaryFactory
> product_name
> popularity
> product_id
> suggest_fuzzy_doc_dict_payload
> text
>   
> 
> {code}
>   - Using DocumentExpressionDictionary and FuzzySuggester
>   -- Suggestion on product_name sorted by the expression "((price * 2) + 
> ln(popularity))" (where both price and popularity are fields in the document)
> {code}
> 
>   
> suggest_fuzzy_doc_expr_dict
> DocumentExpressionDictionaryFactory
> FuzzyLookupFactory
> product_name
> ((price * 2) + ln(popularity))
> 
>   weight
>   float
> 
> 
>   price
>   float
> 
> suggest_fuzzy_doc_expr_dict
> text
>   
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (SOLR-2894) Implement distributed pivot faceting

[Elran Dvir (JIRA)]

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

Elran Dvir commented on SOLR-2894:
--

Hi Andrew,

Sorry for the long delay.
I am still seeing the issue I reported on 20/May/13 12:27 
(f.field_A.facet.limit=-1 returns at most 100 terms for field_A).

Also, can you please dircet me to the line of code where datetimes are breaking 
when trying to refine (caused by "pivot.add( "value", ftype.toObject(sfield, 
termval))")
I need pivot to return values as objects.

Thank you very much.


> Implement distributed pivot faceting
> 
>
> Key: SOLR-2894
> URL: https://issues.apache.org/jira/browse/SOLR-2894
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erik Hatcher
> Fix For: 4.6
>
> Attachments: SOLR-2894-reworked.patch, SOLR-2894.patch, 
> SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, 
> SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, 
> SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, 
> SOLR-2894.patch
>
>
> Following up on SOLR-792, pivot faceting currently only supports 
> undistributed mode.  Distributed pivot faceting needs to be implemented.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module

[simon raphael (JIRA)]

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

simon raphael commented on LUCENE-2899:
---

Hi, 

I have a problem after installing the patch. I can't launch Solr anymore. I've 
got the following error : 

Plugin init failure for [schema.xml] analyzer/tokenizer: Error loading class 
'solr.OpenNLPTokenizerFactory'

Though the opennlp*.jar files are correctly added : 

Adding 
'file:/var/www/lucene_solr_4_5_1/solr/contrib/opennlp/lib/opennlp-tools-1.5.3.jar'
 to classloader
5453 [coreLoadExecutor-3-thread-1] INFO  
org.apache.solr.core.SolrResourceLoader  – Adding 
'file:/var/www/lucene_solr_4_5_1/solr/contrib/opennlp/lib/opennlp-maxent-3.0.3.jar'
 to classloader


Any idea of what I am doing wrong ?

Thank you :)


> Add OpenNLP Analysis capabilities as a module
> -
>
> Key: LUCENE-2899
> URL: https://issues.apache.org/jira/browse/LUCENE-2899
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/analysis
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
> Fix For: 4.6
>
> Attachments: LUCENE-2899-RJN.patch, LUCENE-2899.patch, 
> OpenNLPFilter.java, OpenNLPTokenizer.java
>
>
> Now that OpenNLP is an ASF project and has a nice license, it would be nice 
> to have a submodule (under analysis) that exposed capabilities for it. Drew 
> Farris, Tom Morton and I have code that does:
> * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it 
> would have to change slightly to buffer tokens)
> * NamedEntity recognition as a TokenFilter
> We are also planning a Tokenizer/TokenFilter that can put parts of speech as 
> either payloads (PartOfSpeechAttribute?) on a token or at the same position.
> I'd propose it go under:
> modules/analysis/opennlp



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

Re: DocValue on Strings slow and OOM

[Per Steffensen]

Forget about the quoted comment a the bottom below. It is not true. Both 
the fast/efficient and the slow/memory-consuming query follow the 
getTermCounts-path.


But I have identified another place where they take different paths in 
the code. In SimpleFacets.getTermCounts you will find the code below. I 
have pointed out where the two queries go.

if (params.getFieldBool(field, GroupParams.GROUP_FACET, false)) {
  counts = getGroupedCounts(searcher, docs, field, multiToken, 
offset,limit, mincount, missing, sort, prefix);

} else {
  assert method != null;
  switch (method) {
case ENUM:
  assert TrieField.getMainValuePrefix(ft) == null;
  counts = getFacetTermEnumCounts(searcher, docs, field, 
offset, limit, mincount,missing,sort,prefix);

  break;
case FCS:
  assert !multiToken;
  if (ft.getNumericType() != null && !sf.multiValued()) {
*** ---> The fast/efficient query (facet.field=a_dlng_doc_sto) goes here
// force numeric faceting
if (prefix != null && !prefix.isEmpty()) {
  throw new SolrException(ErrorCode.BAD_REQUEST, 
FacetParams.FACET_PREFIX + " is not supported on numeric types");

}
counts = NumericFacets.getCounts(searcher, docs, field, 
offset, limit, mincount, missing, sort);

  } else {
PerSegmentSingleValuedFaceting ps = new 
PerSegmentSingleValuedFaceting(searcher, docs, field, offset,limit, 
mincount, missing, sort, prefix);
Executor executor = threads == 0 ? directExecutor : 
facetExecutor;

ps.setNumThreads(threads);
counts = ps.getFacetCounts(executor);
  }
  break;
case FC:
  if (sf.hasDocValues()) {
*** ---> The slow/memory-consuming query (facet.field=c_dstr_doc_sto) 
goes here
counts = DocValuesFacets.getCounts(searcher, docs, field, 
offset,limit, mincount, missing, sort, prefix);
  } else if (multiToken || TrieField.getMainValuePrefix(ft) != 
null) {
UnInvertedField uif = 
UnInvertedField.getUnInvertedField(field, searcher);
counts = uif.getCounts(searcher, docs, offset, limit, 
mincount,missing,sort,prefix);

  } else {
counts = getFieldCacheCounts(searcher, docs, field, 
offset,limit, mincount, missing, sort, prefix);

  }
  break;
default:
  throw new AssertionError();
  }
}

I also believe I have found where the huge memory allocation is done. 
Did a memory dump while the slow/memory-consuming c_dstr_doc_sto-query 
was going on (penty of time to do that - 100+ secs). It seems that a lot 
of memory is allocated under SlowCompositeReaderWrapper.cachedOrdMaps 
which holds HashMaps containing MultiDocValues$OrdinalMaps as values, 
and those MultiDocValues$OrdinalMaps have a field ordDeltas-array of 
MonotonicAppendingLongBuffers ... bla bla ... containing Packed64 
containing long-arrays.
See 
https://dl.dropboxusercontent.com/u/25718039/mem-dump-while-searching-on-facet.field-c_dstr_doc_sto.png


SlowCompositeReaderWrapper and all this memory-allocation does not seem 
to be part of the fast a_dlng_doc_sto-query.


Does this information provide any leads on how to fix 
response-time/memory-consumption issue? Maybe it helps telling if going 
to 4.5 will fix the issue?


Regards, Per Steffensen

On 11/5/13 1:47 PM, Per Steffensen wrote:

Looking at threaddumps

It seems like one of the major differences in what is done for 
c_dstr_doc_sto vs a_dlng_doc_sto is in 
SimpleFactes.getFacetFieldCounts, where c_dstr_doc_sto takes the 
"getTermCounts"-path and a_dlng_doc_sto takes the 
"getListedTermCounts"-path.


String termList = localParams == null ? null : 
localParams.get(CommonParams.TERMS);

if (termList != null) {
  res.add(key, getListedTermCounts(facetValue, termList));
} else {
  res.add(key, getTermCounts(facetValue));
}

getTermCounts seems to do a lot more and to be a lot more complex than 
getListedTermCounts

Re: DocValue on Strings slow and OOM

[Robert Muir]

Before lucene 4.5 docvalues were loaded entirely into RAM.

I'm not going to waste time debugging any old code releases here, you
should upgrade to the latest release!

On Wed, Nov 6, 2013 at 4:58 AM, Per Steffensen  wrote:
> Forget about the quoted comment a the bottom below. It is not true. Both the
> fast/efficient and the slow/memory-consuming query follow the
> getTermCounts-path.
>
> But I have identified another place where they take different paths in the
> code. In SimpleFacets.getTermCounts you will find the code below. I have
> pointed out where the two queries go.
> if (params.getFieldBool(field, GroupParams.GROUP_FACET, false)) {
>   counts = getGroupedCounts(searcher, docs, field, multiToken,
> offset,limit, mincount, missing, sort, prefix);
> } else {
>   assert method != null;
>   switch (method) {
> case ENUM:
>   assert TrieField.getMainValuePrefix(ft) == null;
>   counts = getFacetTermEnumCounts(searcher, docs, field, offset,
> limit, mincount,missing,sort,prefix);
>   break;
> case FCS:
>   assert !multiToken;
>   if (ft.getNumericType() != null && !sf.multiValued()) {
> *** ---> The fast/efficient query (facet.field=a_dlng_doc_sto) goes here
> // force numeric faceting
> if (prefix != null && !prefix.isEmpty()) {
>   throw new SolrException(ErrorCode.BAD_REQUEST,
> FacetParams.FACET_PREFIX + " is not supported on numeric types");
> }
> counts = NumericFacets.getCounts(searcher, docs, field, offset,
> limit, mincount, missing, sort);
>   } else {
> PerSegmentSingleValuedFaceting ps = new
> PerSegmentSingleValuedFaceting(searcher, docs, field, offset,limit,
> mincount, missing, sort, prefix);
> Executor executor = threads == 0 ? directExecutor :
> facetExecutor;
> ps.setNumThreads(threads);
> counts = ps.getFacetCounts(executor);
>   }
>   break;
> case FC:
>   if (sf.hasDocValues()) {
> *** ---> The slow/memory-consuming query (facet.field=c_dstr_doc_sto) goes
> here
> counts = DocValuesFacets.getCounts(searcher, docs, field,
> offset,limit, mincount, missing, sort, prefix);
>   } else if (multiToken || TrieField.getMainValuePrefix(ft) != null)
> {
> UnInvertedField uif = UnInvertedField.getUnInvertedField(field,
> searcher);
> counts = uif.getCounts(searcher, docs, offset, limit,
> mincount,missing,sort,prefix);
>   } else {
> counts = getFieldCacheCounts(searcher, docs, field,
> offset,limit, mincount, missing, sort, prefix);
>   }
>   break;
> default:
>   throw new AssertionError();
>   }
> }
>
> I also believe I have found where the huge memory allocation is done. Did a
> memory dump while the slow/memory-consuming c_dstr_doc_sto-query was going
> on (penty of time to do that - 100+ secs). It seems that a lot of memory is
> allocated under SlowCompositeReaderWrapper.cachedOrdMaps which holds
> HashMaps containing MultiDocValues$OrdinalMaps as values, and those
> MultiDocValues$OrdinalMaps have a field ordDeltas-array of
> MonotonicAppendingLongBuffers ... bla bla ... containing Packed64 containing
> long-arrays.
> See
> https://dl.dropboxusercontent.com/u/25718039/mem-dump-while-searching-on-facet.field-c_dstr_doc_sto.png
>
> SlowCompositeReaderWrapper and all this memory-allocation does not seem to
> be part of the fast a_dlng_doc_sto-query.
>
> Does this information provide any leads on how to fix
> response-time/memory-consumption issue? Maybe it helps telling if going to
> 4.5 will fix the issue?
>
> Regards, Per Steffensen
>
>
> On 11/5/13 1:47 PM, Per Steffensen wrote:
>
> Looking at threaddumps
>
> It seems like one of the major differences in what is done for
> c_dstr_doc_sto vs a_dlng_doc_sto is in SimpleFactes.getFacetFieldCounts,
> where c_dstr_doc_sto takes the "getTermCounts"-path and a_dlng_doc_sto takes
> the "getListedTermCounts"-path.
>
> String termList = localParams == null ? null :
> localParams.get(CommonParams.TERMS);
> if (termList != null) {
>   res.add(key, getListedTermCounts(facetValue, termList));
> } else {
>   res.add(key, getTermCounts(facetValue));
> }
>
> getTermCounts seems to do a lot more and to be a lot more complex than
> getListedTermCounts
>
>

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

Re: DocValue on Strings slow and OOM

[Per Steffensen]

It seems like NumericFacets.getCounts is using the FieldCache. This is 
what we wanted to avoid by using doc-values in the first place - because 
we have experienced so many times that the FieldCache makes us go OOM. 
We where told that if we used doc-values the FieldCache would not be 
used. But then again if doing those kinds of doc-value queries with 
docValuesFormat="Disk" will still use enormous amounts of memory 
(lineary dependent on the documents managed by the Solr-node) it is not 
worth much anyway - compared to FieldCache. And/or if it make us end up 
with 100+ secs response-times (on billions of documents all in all, but 
only a limited number hit by the query) it is not worth much either.


Will someone please help clarify
* Will this perform significantly be better in 4.5+ (vs 4.4)? Is 100+ 
secs expected, for a facet search that hits only 6 documents among 12 
billion in total, when facet.field is set to a field like c_dstr_doc_sto?
* Will doc-value (docValuesFormat="Disk") still use memory that is 
lineary dependent on the total number of documents handled by the 
Solr-node, when doing facet searches with facet.field set to one of 
those doc-values fields?


Any help is very appreciated!

Regards, Per Steffensen

On 11/6/13 10:58 AM, Per Steffensen wrote:

  if (ft.getNumericType() != null && !sf.multiValued()) {
*** ---> The fast/efficient query (facet.field=a_dlng_doc_sto) goes here
// force numeric faceting
if (prefix != null && !prefix.isEmpty()) {
  throw new SolrException(ErrorCode.BAD_REQUEST, 
FacetParams.FACET_PREFIX + " is not supported on numeric types");

}
counts = NumericFacets.getCounts(searcher, docs, field, 
offset, limit, mincount, missing, sort);

  } else {

Re: DocValue on Strings slow and OOM

[Per Steffensen]

On 11/6/13 11:43 AM, Robert Muir wrote:

Before lucene 4.5 docvalues were loaded entirely into RAM.

I'm not going to waste time debugging any old code releases here, you
should upgrade to the latest release!

Ok, thanks!

I do not consider it a bug (just a performance issue), so no debugging 
needed.
It is just that we do not want to spend time upgrading to 4.5 if there 
is not a justified hope/explanation that it will probably make things 
better. But I guess there is.


One short question: Will 4.5 index things differently (compared to 4.4) 
for documents with fields like I showed earlier? Im basically asking if 
we need to reindex the 12billion documents again after upgrading to 4.5, 
or if we ought to be able to deploy 4.5 on top of the already indexed 
documents.


Regards, Per Steffensen

[jira] [Commented] (LUCENE-5330) IndexWriter doesn't process all events on getReader / close / rollback

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-5330:


Hmm, besides deleting files too late, are there any other problems caused here?

E.g., if an app that only flushes via getReader, would this mean a merge never 
kicks off (merge starvation)?

> IndexWriter doesn't process all events on getReader / close / rollback
> --
>
> Key: LUCENE-5330
> URL: https://issues.apache.org/jira/browse/LUCENE-5330
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 4.5, 5.0
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: 4.6, 5.0
>
> Attachments: LUCENE-5330.patch
>
>
> IndexWriter misses to apply all pending events in getReader() as well as 
> close() / rollback(). This can lead to files that never get deleted or only 
> very very late. If you are using RAM Directories for instance this quickly 
> fills up a huge amount of memory. It might not be super critical in 
> production and it also doesn't cause any data loss or index corruption.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-5330) IndexWriter doesn't process all events on getReader / close / rollback

[ASF subversion and git services (JIRA)]

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

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

Commit 1539318 from [~mikemccand] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1539318 ]

LUCENE-5330: add test

> IndexWriter doesn't process all events on getReader / close / rollback
> --
>
> Key: LUCENE-5330
> URL: https://issues.apache.org/jira/browse/LUCENE-5330
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 4.5, 5.0
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: 4.6, 5.0
>
> Attachments: LUCENE-5330.patch
>
>
> IndexWriter misses to apply all pending events in getReader() as well as 
> close() / rollback(). This can lead to files that never get deleted or only 
> very very late. If you are using RAM Directories for instance this quickly 
> fills up a huge amount of memory. It might not be super critical in 
> production and it also doesn't cause any data loss or index corruption.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-5330) IndexWriter doesn't process all events on getReader / close / rollback

[ASF subversion and git services (JIRA)]

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

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

Commit 1539317 from [~mikemccand] in branch 'dev/trunk'
[ https://svn.apache.org/r1539317 ]

LUCENE-5330: add test

> IndexWriter doesn't process all events on getReader / close / rollback
> --
>
> Key: LUCENE-5330
> URL: https://issues.apache.org/jira/browse/LUCENE-5330
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 4.5, 5.0
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: 4.6, 5.0
>
> Attachments: LUCENE-5330.patch
>
>
> IndexWriter misses to apply all pending events in getReader() as well as 
> close() / rollback(). This can lead to files that never get deleted or only 
> very very late. If you are using RAM Directories for instance this quickly 
> fills up a huge amount of memory. It might not be super critical in 
> production and it also doesn't cause any data loss or index corruption.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-5330) IndexWriter doesn't process all events on getReader / close / rollback

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-5330:


+1 for the patch.

> IndexWriter doesn't process all events on getReader / close / rollback
> --
>
> Key: LUCENE-5330
> URL: https://issues.apache.org/jira/browse/LUCENE-5330
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 4.5, 5.0
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: 4.6, 5.0
>
> Attachments: LUCENE-5330.patch
>
>
> IndexWriter misses to apply all pending events in getReader() as well as 
> close() / rollback(). This can lead to files that never get deleted or only 
> very very late. If you are using RAM Directories for instance this quickly 
> fills up a huge amount of memory. It might not be super critical in 
> production and it also doesn't cause any data loss or index corruption.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-5330) IndexWriter doesn't process all events on getReader / close / rollback

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-5330:


bq. E.g., if an app that only flushes via getReader, would this mean a merge 
never kicks off (merge starvation)?

OK, we are fine here (I just committed a test): IW.getReader already calls 
maybeMerge itself, separately.

> IndexWriter doesn't process all events on getReader / close / rollback
> --
>
> Key: LUCENE-5330
> URL: https://issues.apache.org/jira/browse/LUCENE-5330
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 4.5, 5.0
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: 4.6, 5.0
>
> Attachments: LUCENE-5330.patch
>
>
> IndexWriter misses to apply all pending events in getReader() as well as 
> close() / rollback(). This can lead to files that never get deleted or only 
> very very late. If you are using RAM Directories for instance this quickly 
> fills up a huge amount of memory. It might not be super critical in 
> production and it also doesn't cause any data loss or index corruption.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (SOLR-5379) Query-time multi-word synonym expansion

[Markus Jelsma (JIRA)]

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

Markus Jelsma commented on SOLR-5379:
-

Bill - did you also test the other multiword-synonym patches?

> Query-time multi-word synonym expansion
> ---
>
> Key: SOLR-5379
> URL: https://issues.apache.org/jira/browse/SOLR-5379
> Project: Solr
>  Issue Type: Improvement
>  Components: query parsers
>Reporter: Nguyen Manh Tien
>  Labels: multi-word, queryparser, synonym
> Fix For: 4.5.1, 4.6
>
> Attachments: quoted.patch, synonym-expander.patch
>
>
> While dealing with synonym at query time, solr failed to work with multi-word 
> synonyms due to some reasons:
> - First the lucene queryparser tokenizes user query by space so it split 
> multi-word term into two terms before feeding to synonym filter, so synonym 
> filter can't recognized multi-word term to do expansion
> - Second, if synonym filter expand into multiple terms which contains 
> multi-word synonym, The SolrQueryParseBase currently use MultiPhraseQuery to 
> handle synonyms. But MultiPhraseQuery don't work with term have different 
> number of words.
> For the first one, we can extend quoted all multi-word synonym in user query 
> so that lucene queryparser don't split it. There are a jira task related to 
> this one https://issues.apache.org/jira/browse/LUCENE-2605.
> For the second, we can replace MultiPhraseQuery by an appropriate BoleanQuery 
> SHOULD which contains multiple PhraseQuery in case tokens stream have 
> multi-word synonym.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-5283) Fail the build if ant test didn't execute any tests (everything filtered out).

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-5283:
-

I'm working on this, don't waste your time, Uwe. Will provide a patch later.

> Fail the build if ant test didn't execute any tests (everything filtered out).
> --
>
> Key: LUCENE-5283
> URL: https://issues.apache.org/jira/browse/LUCENE-5283
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 4.6, 5.0
>
> Attachments: LUCENE-5283.patch, LUCENE-5283.patch
>
>
> This should be an optional setting that defaults to 'false' (the build 
> proceeds).



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

RE: Testing Java Updates with your projects.

[Uwe Schindler]

Hi,

 

JDK 8 b114  is now installed on the Jenkins Linux and Windows machines. The 
first build already succeeded: 
http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/8199/

So at least the Object#clone()-with-interface bug is fixed.

 

Uwe

 

-

Uwe Schindler

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

  http://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Uwe Schindler [mailto:u...@thetaphi.de] 
Sent: Wednesday, November 06, 2013 12:06 AM
To: dev@lucene.apache.org; rory.odonn...@oracle.com
Cc: 'Dalibor Topic'; 'Donald Smith'; 'Seán Coffey'; 'Balchandra Vaidya'
Subject: RE: Testing Java Updates with your projects.

 

Hi Rory,

 

I am back at home since a few hours. Will install the new build at some time 
tomorrow on Jenkins. In the meantime, the MacOS SIGSEGV occurred again - I will 
try to open a conventional “bugs.sun.com” bug report tomorrow, if there is none 
already.

 

Uwe

 

-

Uwe Schindler

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

  http://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Rory O'Donnell Oracle, Dublin ireland [mailto:rory.odonn...@oracle.com] 
Sent: Tuesday, November 05, 2013 11:13 AM
To: Uwe Schindler
Cc: dev@lucene.apache.org; 'Dalibor Topic'; 'Donald Smith'; 'Seán Coffey'; 
'Balchandra Vaidya'
Subject: Re: Testing Java Updates with your projects.

 

Hi Uwe,

b114 , containing the fix,is now available - https://jdk8.java.net/download.html

Very interested to hear your results of testing this build.

Rgds,Rory

On 10/23/13 02:03 PM, Uwe Schindler wrote:

Thanks Rory for the info!

 

I am changing the recipients of this mail, so it no longer goes to the private 
list.

 

@ dev@lao: FYI, the clone() bug seems to be fixed so we can soon upgrade to 
JDK8 latest and run tests again.

 

Uwe

 

-

Uwe Schindler

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

  http://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Rory O'Donnell [mailto:rory.odonn...@oracle.com] 
Sent: Wednesday, October 23, 2013 1:08 PM
To: rory.odonn...@oracle.com
Cc: Uwe Schindler; 'Dawid Weiss'; 'Robert Muir'; 'Dalibor Topic'; 'Donald 
Smith'; 'Seán Coffey'; 'Balchandra Vaidya'; priv...@lucene.apache.org
Subject: Re: Testing Java Updates with your projects.

 

Hi Uwe,

I noticed https://bugs.openjdk.java.net/browse/JDK-8026394 has moved into fixed 
state.
Hope to see this included in the near future, will update you.  

It is not in b112   which is not available.

Rgds, Rory



On 18/10/2013 15:51, Rory O'Donnell Oracle, Dublin Ireland wrote:

Hi Uwe, 

It turns out this is a duplicate of 
https://bugs.openjdk.java.net/browse/JDK-8026394 

Rgds,Rory 

On 18/10/2013 10:09, Rory O'Donnell Oracle, Dublin Ireland wrote: 



Hi Uwe, 


Balchandra has logged a bug for this issue: 

https://bugs.openjdk.java.net/browse/JDK-8026845 

Rgds,Rory 

On 17/10/2013 18:27, Uwe Schindler wrote: 



Hi, 

I was able to reproduce with a simple test case that emulates the UIMA code. 
See attached test case, just compile it with any JDK and run with b111: 

With Java 7 or JDK8b109: 




javac TestCloneInterface.java 
java TestCloneInterface 

With JDK8b111: 




java TestCloneInterface 

Exception in thread "main" java.lang.IllegalAccessError: tried to access method 
java.lang.Object.clone()Ljava/lang/Object; from class TestCloneInterface 
 at TestCloneInterface.test(TestCloneInterface.java:15) 
 at TestCloneInterface.main(TestCloneInterface.java:19) 
The bug happens if the clone() method is declared in a superinterface only. 
Without the additional interface inbetween, test passes. 
Instead of the real interface (the "o" local variable, which is of type 
"FoobarIntf") it checks access flags on "this", which is of type 
"TestCloneInterface". 

Uwe 

- 
Uwe Schindler 
uschind...@apache.org 
Apache Lucene PMC Chair / Committer 
Bremen, Germany 
http://lucene.apache.org/ 





-Original Message- 
From: Rory O'Donnell Oracle, Dublin Ireland 
[mailto:rory.odonn...@oracle.com] 
Sent: Thursday, October 17, 2013 7:19 PM 
To: Uwe Schindler 
Cc: 'Dawid Weiss'; 'Robert Muir'; 'Dalibor Topic'; 'Donald Smith'; 'Seán 
Coffey'; 
priv...@lucene.apache.org; Balchandra Vaidya 
Subject: Re: Testing Java Updates with your projects. 

Hi Uwe, 

The more info you can provide the better. 
Adding Balchandra to email. 

Rgds,Rory 

On 17/10/2013 17:41, Uwe Schindler wrote: 



Hi Rory, 

we found a new bug in 8 b111, not appearing in Java 7 and Java 8 b109: 
It seems to be related to one recent commit, reproduces all the time 

(reproduces with bytecode compiled with JDK8b111 and ran with JDK8b111, 
but also with bytecode compiled with JDK7 and ran with JDK8b111). I am 
trying to understand what's happening, but it looks like the patch fails to 
check the access flags of the method on the correct instance/type/whatever. 



This is the commit that I  think causes this: 
http://hg.openjdk.java.net/jdk

[jira] [Updated] (LUCENE-5283) Fail the build if ant test didn't execute any tests (everything filtered out).

[Dawid Weiss (JIRA)]

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

Dawid Weiss updated LUCENE-5283:


Attachment: LUCENE-5283.patch

- Rewritten in groovy (with dependency on resolve-groovy).
- Moved the tmp. file to build/

Seems to work. I'm running a full build now.

> Fail the build if ant test didn't execute any tests (everything filtered out).
> --
>
> Key: LUCENE-5283
> URL: https://issues.apache.org/jira/browse/LUCENE-5283
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 4.6, 5.0
>
> Attachments: LUCENE-5283.patch, LUCENE-5283.patch, LUCENE-5283.patch
>
>
> This should be an optional setting that defaults to 'false' (the build 
> proceeds).



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-5330) IndexWriter doesn't process all events on getReader / close / rollback

[Simon Willnauer (JIRA)]

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

Simon Willnauer commented on LUCENE-5330:
-

mike thanks for the test! Indeed it takes care of merging though. The issue 
manifests pretty quickly if you use RAM directory and exclusively pull NRT 
readers. It will simply keep the files that should be deleted around until the 
queue gets purged.

> IndexWriter doesn't process all events on getReader / close / rollback
> --
>
> Key: LUCENE-5330
> URL: https://issues.apache.org/jira/browse/LUCENE-5330
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 4.5, 5.0
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: 4.6, 5.0
>
> Attachments: LUCENE-5330.patch
>
>
> IndexWriter misses to apply all pending events in getReader() as well as 
> close() / rollback(). This can lead to files that never get deleted or only 
> very very late. If you are using RAM Directories for instance this quickly 
> fills up a huge amount of memory. It might not be super critical in 
> production and it also doesn't cause any data loss or index corruption.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-5330) IndexWriter doesn't process all events on getReader / close / rollback

[ASF subversion and git services (JIRA)]

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

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

Commit 1539332 from [~simonw] in branch 'dev/trunk'
[ https://svn.apache.org/r1539332 ]

LUCENE-5330: Fix IndexWriter to process all internal events on getReader / 
close / rollback

> IndexWriter doesn't process all events on getReader / close / rollback
> --
>
> Key: LUCENE-5330
> URL: https://issues.apache.org/jira/browse/LUCENE-5330
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 4.5, 5.0
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: 4.6, 5.0
>
> Attachments: LUCENE-5330.patch
>
>
> IndexWriter misses to apply all pending events in getReader() as well as 
> close() / rollback(). This can lead to files that never get deleted or only 
> very very late. If you are using RAM Directories for instance this quickly 
> fills up a huge amount of memory. It might not be super critical in 
> production and it also doesn't cause any data loss or index corruption.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-5330) IndexWriter doesn't process all events on getReader / close / rollback

[ASF subversion and git services (JIRA)]

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

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

Commit 1539335 from [~simonw] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1539335 ]

LUCENE-5330: Fix IndexWriter to process all internal events on getReader / 
close / rollback

> IndexWriter doesn't process all events on getReader / close / rollback
> --
>
> Key: LUCENE-5330
> URL: https://issues.apache.org/jira/browse/LUCENE-5330
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 4.5, 5.0
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: 4.6, 5.0
>
> Attachments: LUCENE-5330.patch
>
>
> IndexWriter misses to apply all pending events in getReader() as well as 
> close() / rollback(). This can lead to files that never get deleted or only 
> very very late. If you are using RAM Directories for instance this quickly 
> fills up a huge amount of memory. It might not be super critical in 
> production and it also doesn't cause any data loss or index corruption.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Resolved] (LUCENE-5330) IndexWriter doesn't process all events on getReader / close / rollback

[Simon Willnauer (JIRA)]

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

Simon Willnauer resolved LUCENE-5330.
-

Resolution: Fixed

> IndexWriter doesn't process all events on getReader / close / rollback
> --
>
> Key: LUCENE-5330
> URL: https://issues.apache.org/jira/browse/LUCENE-5330
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 4.5, 5.0
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: 4.6, 5.0
>
> Attachments: LUCENE-5330.patch
>
>
> IndexWriter misses to apply all pending events in getReader() as well as 
> close() / rollback(). This can lead to files that never get deleted or only 
> very very late. If you are using RAM Directories for instance this quickly 
> fills up a huge amount of memory. It might not be super critical in 
> production and it also doesn't cause any data loss or index corruption.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Updated] (SOLR-5318) create command don't take into account the transient core property

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-5318:
-

Attachment: SOLR-5318.patch

New patch with tests, committing shortly. I changed Oliver's approach a bit so 
we don't need new methods in CoreContainer.

I'm not quite sure we really need all the variants of register, it seems like 
we always have things like the core name, whether the core is transient, all 
that stuff already in the CoreDescriptor we pass around, except maybe in the 
case of renaming the core. Could all this be made simpler? But that's for 
another day.

> create command don't take into account the transient core property
> --
>
> Key: SOLR-5318
> URL: https://issues.apache.org/jira/browse/SOLR-5318
> Project: Solr
>  Issue Type: Bug
>  Components: multicore
>Affects Versions: 4.4, 4.6
>Reporter: olivier soyez
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-5318.patch, SOLR-5318.patch
>
>
> the create core admin command don't take into account the transient core 
> property, when the core is registered (so, the core will be never closed by 
> the transient core cache)
> To reproduce :
> set transientCacheSize=2 and start with no cores
> Create 3 cores :
> curl 
> "http://ip:port/solr/admin/cores?action=CREATE&name=coreX&instanceDir=path_to_instanceDir_coreX&dataDir=path_to_dataDir_coreX&loadOnStartup=false&transient=true";
> Look at the status :
> http://ip:port/solr/admin/cores?action=STATUS
> All cores are still loaded.
> One core should not be loaded (closed by the transient cache)
> The patch in attachment is for svn solr branch_4X (revision number 1526418)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (SOLR-5318) create command don't take into account the transient core property

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-5318:
---

Commit 1539343 from [~erickoerickson] in branch 'dev/trunk'
[ https://svn.apache.org/r1539343 ]

SOLR-5318: create HTTP API command doesn't respect transient core property

> create command don't take into account the transient core property
> --
>
> Key: SOLR-5318
> URL: https://issues.apache.org/jira/browse/SOLR-5318
> Project: Solr
>  Issue Type: Bug
>  Components: multicore
>Affects Versions: 4.4, 4.6
>Reporter: olivier soyez
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-5318.patch, SOLR-5318.patch
>
>
> the create core admin command don't take into account the transient core 
> property, when the core is registered (so, the core will be never closed by 
> the transient core cache)
> To reproduce :
> set transientCacheSize=2 and start with no cores
> Create 3 cores :
> curl 
> "http://ip:port/solr/admin/cores?action=CREATE&name=coreX&instanceDir=path_to_instanceDir_coreX&dataDir=path_to_dataDir_coreX&loadOnStartup=false&transient=true";
> Look at the status :
> http://ip:port/solr/admin/cores?action=STATUS
> All cores are still loaded.
> One core should not be loaded (closed by the transient cache)
> The patch in attachment is for svn solr branch_4X (revision number 1526418)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-5316) Taxonomy tree traversing improvement

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-5316:


Here's ALL_BUT_DIM performance; it looks better!  However, I'm not sure why, 
but sometimes 1-3 of the queries that ran came back w/ all 0 facet counts.  
Maybe a thread safety issue in the quick & dirty patch?

{noformat}
TaskQPS base  StdDevQPS comp  StdDev
Pct diff
  AndHighLow   70.50  (3.1%)   63.66  (5.2%)   
-9.7% ( -17% -   -1%)
   MedPhrase   43.43  (2.2%)   40.79  (3.4%)   
-6.1% ( -11% -0%)
 LowTerm   38.63  (2.0%)   36.46  (3.4%)   
-5.6% ( -10% -0%)
  Fuzzy1   28.41  (1.5%)   27.15  (2.6%)   
-4.4% (  -8% -0%)
OrNotHighLow   31.95  (3.7%)   30.64  (3.9%)   
-4.1% ( -11% -3%)
 LowSloppyPhrase   21.67  (1.5%)   20.96  (2.2%)   
-3.3% (  -6% -0%)
  Fuzzy2   21.39  (1.7%)   20.71  (1.9%)   
-3.2% (  -6% -0%)
OrNotHighMed   17.30  (2.8%)   16.90  (3.3%)   
-2.3% (  -8% -3%)
 Prefix3   10.68  (1.5%)   10.46  (2.2%)   
-2.1% (  -5% -1%)
  AndHighMed   13.85  (1.2%)   13.57  (1.4%)   
-2.0% (  -4% -0%)
 MedSpanNear   15.19  (2.7%)   14.89  (2.9%)   
-2.0% (  -7% -3%)
 AndHighHigh   11.70  (1.0%)   11.51  (1.8%)   
-1.6% (  -4% -1%)
HighSloppyPhrase2.56  (8.0%)2.52  (7.9%)   
-1.5% ( -16% -   15%)
OrHighNotMed5.66  (1.4%)5.58  (1.5%)   
-1.4% (  -4% -1%)
   LowPhrase7.82  (5.7%)7.72  (5.8%)   
-1.2% ( -12% -   10%)
 MedTerm   10.26  (2.0%)   10.14  (1.4%)   
-1.1% (  -4% -2%)
   OrNotHighHigh7.32  (1.7%)7.24  (1.6%)   
-1.0% (  -4% -2%)
 MedSloppyPhrase2.47  (6.1%)2.45  (5.9%)   
-1.0% ( -12% -   11%)
HighTerm6.85  (1.3%)6.78  (1.8%)   
-1.0% (  -4% -2%)
   OrHighMed4.46  (1.6%)4.42  (2.0%)   
-0.9% (  -4% -2%)
 LowSpanNear5.98  (4.0%)5.92  (3.4%)   
-0.9% (  -8% -6%)
HighSpanNear2.54  (2.6%)2.53  (2.9%)   
-0.6% (  -5% -5%)
  HighPhrase2.18  (5.9%)2.16  (6.1%)   
-0.5% ( -11% -   12%)
 Respell   41.46  (3.6%)   41.32  (3.1%)   
-0.3% (  -6% -6%)
   OrHighLow2.19  (1.6%)2.19  (1.6%)   
-0.3% (  -3% -2%)
Wildcard3.65  (1.8%)3.64  (1.5%)   
-0.2% (  -3% -3%)
   OrHighNotHigh3.78  (1.7%)3.77  (1.5%)   
-0.2% (  -3% -3%)
  OrHighHigh1.65  (2.0%)1.64  (1.5%)   
-0.2% (  -3% -3%)
OrHighNotLow3.29  (1.5%)3.28  (1.6%)   
-0.2% (  -3% -3%)
  IntNRQ1.18  (1.8%)1.18  (1.4%)   
-0.1% (  -3% -3%)
{noformat}

> Taxonomy tree traversing improvement
> 
>
> Key: LUCENE-5316
> URL: https://issues.apache.org/jira/browse/LUCENE-5316
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/facet
>Reporter: Gilad Barkai
>Priority: Minor
> Attachments: LUCENE-5316.patch, LUCENE-5316.patch, LUCENE-5316.patch
>
>
> The taxonomy traversing is done today utilizing the 
> {{ParallelTaxonomyArrays}}. In particular, two taxonomy-size {{int}} arrays 
> which hold for each ordinal it's (array #1) youngest child and (array #2) 
> older sibling.
> This is a compact way of holding the tree information in memory, but it's not 
> perfect:
> * Large (8 bytes per ordinal in memory)
> * Exposes internal implementation
> * Utilizing these arrays for tree traversing is not straight forward
> * Lose reference locality while traversing (the array is accessed in 
> increasing only entries, but they may be distant from one another)
> * In NRT, a reopen is always (not worst case) done at O(Taxonomy-size)
> This issue is about making the traversing more easy, the code more readable, 
> and open it for future improvements (i.e memory footprint and NRT cost) - 
> without changing any of the internals. 
> A later issue(s?) could be opened to address the gaps once this one is done.



--
This message was sent by Atlassian JIRA
(v6.1#6

[jira] [Commented] (SOLR-2894) Implement distributed pivot faceting

[Andrew Muldowney (JIRA)]

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

Andrew Muldowney commented on SOLR-2894:


By returning an object you get a pretty date format that does not work when 
doing:
getListedTermCounts(field,firstFieldsValues); -PivotFacetProcessor::104

When it attempts to convert the pretty date it has into the datatype of the 
field it will fail to do so.

> Implement distributed pivot faceting
> 
>
> Key: SOLR-2894
> URL: https://issues.apache.org/jira/browse/SOLR-2894
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erik Hatcher
> Fix For: 4.6
>
> Attachments: SOLR-2894-reworked.patch, SOLR-2894.patch, 
> SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, 
> SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, 
> SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, 
> SOLR-2894.patch
>
>
> Following up on SOLR-792, pivot faceting currently only supports 
> undistributed mode.  Distributed pivot faceting needs to be implemented.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[Apache Jenkins Server]

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

All tests passed

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

[...truncated 4780 lines...]



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

[jira] [Commented] (SOLR-5318) create command don't take into account the transient core property

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-5318:
---

Commit 1539360 from [~erickoerickson] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1539360 ]

SOLR-5318: create HTTP API command doesn't respect transient core property

> create command don't take into account the transient core property
> --
>
> Key: SOLR-5318
> URL: https://issues.apache.org/jira/browse/SOLR-5318
> Project: Solr
>  Issue Type: Bug
>  Components: multicore
>Affects Versions: 4.4, 4.6
>Reporter: olivier soyez
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-5318.patch, SOLR-5318.patch
>
>
> the create core admin command don't take into account the transient core 
> property, when the core is registered (so, the core will be never closed by 
> the transient core cache)
> To reproduce :
> set transientCacheSize=2 and start with no cores
> Create 3 cores :
> curl 
> "http://ip:port/solr/admin/cores?action=CREATE&name=coreX&instanceDir=path_to_instanceDir_coreX&dataDir=path_to_dataDir_coreX&loadOnStartup=false&transient=true";
> Look at the status :
> http://ip:port/solr/admin/cores?action=STATUS
> All cores are still loaded.
> One core should not be loaded (closed by the transient cache)
> The patch in attachment is for svn solr branch_4X (revision number 1526418)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Resolved] (SOLR-5318) create command don't take into account the transient core property

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-5318.
--

   Resolution: Fixed
Fix Version/s: 5.0
   4.6

Thanks Oliver!

> create command don't take into account the transient core property
> --
>
> Key: SOLR-5318
> URL: https://issues.apache.org/jira/browse/SOLR-5318
> Project: Solr
>  Issue Type: Bug
>  Components: multicore
>Affects Versions: 4.4, 4.6
>Reporter: olivier soyez
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 4.6, 5.0
>
> Attachments: SOLR-5318.patch, SOLR-5318.patch
>
>
> the create core admin command don't take into account the transient core 
> property, when the core is registered (so, the core will be never closed by 
> the transient core cache)
> To reproduce :
> set transientCacheSize=2 and start with no cores
> Create 3 cores :
> curl 
> "http://ip:port/solr/admin/cores?action=CREATE&name=coreX&instanceDir=path_to_instanceDir_coreX&dataDir=path_to_dataDir_coreX&loadOnStartup=false&transient=true";
> Look at the status :
> http://ip:port/solr/admin/cores?action=STATUS
> All cores are still loaded.
> One core should not be loaded (closed by the transient cache)
> The patch in attachment is for svn solr branch_4X (revision number 1526418)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-5316) Taxonomy tree traversing improvement

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-5316:


Hmm but this is the NO_PARENTS perf:

{noformat}
TaskQPS base  StdDevQPS comp  StdDev
Pct diff
  AndHighLow   41.14  (2.5%)   14.32  (4.2%)  
-65.2% ( -70% -  -59%)
   MedPhrase   30.42  (2.7%)   12.74  (4.5%)  
-58.1% ( -63% -  -52%)
 LowTerm   28.27  (1.6%)   12.33  (4.6%)  
-56.4% ( -61% -  -50%)
OrNotHighLow   24.15  (2.6%)   11.47  (4.7%)  
-52.5% ( -58% -  -46%)
  Fuzzy1   21.93  (1.6%)   10.94  (4.6%)  
-50.1% ( -55% -  -44%)
  Fuzzy2   18.12  (1.7%)9.89  (4.5%)  
-45.4% ( -50% -  -39%)
 LowSloppyPhrase   17.97  (1.8%)9.84  (4.7%)  
-45.2% ( -50% -  -39%)
OrNotHighMed   14.90  (2.7%)8.89  (4.9%)  
-40.4% ( -46% -  -33%)
 MedSpanNear   13.41  (2.4%)8.25  (4.3%)  
-38.5% ( -44% -  -32%)
  AndHighMed   12.41  (1.5%)7.90  (4.4%)  
-36.4% ( -41% -  -30%)
 AndHighHigh   10.72  (1.1%)7.22  (4.2%)  
-32.7% ( -37% -  -27%)
 Prefix3   10.22  (1.8%)6.93  (4.1%)  
-32.2% ( -37% -  -26%)
 MedTerm9.86  (2.2%)6.76  (4.1%)  
-31.4% ( -36% -  -25%)
   LowPhrase7.28  (6.0%)5.43  (3.9%)  
-25.4% ( -33% -  -16%)
   OrNotHighHigh7.38  (2.1%)5.53  (3.8%)  
-25.2% ( -30% -  -19%)
HighTerm6.85  (2.2%)5.20  (3.6%)  
-24.1% ( -29% -  -18%)
 LowSpanNear5.70  (3.2%)4.48  (4.1%)  
-21.4% ( -27% -  -14%)
OrHighNotMed5.69  (2.2%)4.52  (3.2%)  
-20.6% ( -25% -  -15%)
   OrHighMed4.57  (2.6%)3.78  (2.6%)  
-17.2% ( -21% -  -12%)
   OrHighNotHigh3.89  (2.5%)3.29  (2.7%)  
-15.3% ( -20% -  -10%)
Wildcard3.76  (2.7%)3.20  (2.4%)  
-14.9% ( -19% -  -10%)
OrHighNotLow3.36  (2.1%)2.94  (2.1%)  
-12.4% ( -16% -   -8%)
HighSloppyPhrase2.51  (6.6%)2.23  (5.9%)  
-11.1% ( -22% -1%)
HighSpanNear2.58  (3.5%)2.29  (2.8%)  
-11.0% ( -16% -   -4%)
 MedSloppyPhrase2.43  (5.2%)2.19  (4.8%)   
-9.8% ( -18% -0%)
  HighPhrase2.20  (6.8%)2.00  (4.8%)   
-9.2% ( -19% -2%)
   OrHighLow2.29  (2.3%)2.09  (1.9%)   
-8.8% ( -12% -   -4%)
  OrHighHigh1.72  (2.6%)1.61  (1.6%)   
-6.2% ( -10% -   -2%)
  IntNRQ1.25  (2.7%)1.19  (1.1%)   
-4.5% (  -8% -0%)
 Respell   40.60  (2.8%)   39.77  (2.8%)   
-2.0% (  -7% -3%)
{noformat}


> Taxonomy tree traversing improvement
> 
>
> Key: LUCENE-5316
> URL: https://issues.apache.org/jira/browse/LUCENE-5316
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/facet
>Reporter: Gilad Barkai
>Priority: Minor
> Attachments: LUCENE-5316.patch, LUCENE-5316.patch, LUCENE-5316.patch
>
>
> The taxonomy traversing is done today utilizing the 
> {{ParallelTaxonomyArrays}}. In particular, two taxonomy-size {{int}} arrays 
> which hold for each ordinal it's (array #1) youngest child and (array #2) 
> older sibling.
> This is a compact way of holding the tree information in memory, but it's not 
> perfect:
> * Large (8 bytes per ordinal in memory)
> * Exposes internal implementation
> * Utilizing these arrays for tree traversing is not straight forward
> * Lose reference locality while traversing (the array is accessed in 
> increasing only entries, but they may be distant from one another)
> * In NRT, a reopen is always (not worst case) done at O(Taxonomy-size)
> This issue is about making the traversing more easy, the code more readable, 
> and open it for future improvements (i.e memory footprint and NRT cost) - 
> without changing any of the internals. 
> A later issue(s?) could be opened to address the gaps once this one is done.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Created] (LUCENE-5331) nested SpanNearQuery with repeating groups does not find match

[Jerry Zhou (JIRA)]

Jerry Zhou created LUCENE-5331:
--

 Summary: nested SpanNearQuery with repeating groups does not find 
match
 Key: LUCENE-5331
 URL: https://issues.apache.org/jira/browse/LUCENE-5331
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Jerry Zhou


Nested spanNear queries do not work in some cases when repeating groups are in 
the query.

Test case is attached ...



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Updated] (LUCENE-5331) nested SpanNearQuery with repeating groups does not find match

[Jerry Zhou (JIRA)]

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

Jerry Zhou updated LUCENE-5331:
---

Attachment: NestedSpanNearTest.java

> nested SpanNearQuery with repeating groups does not find match
> --
>
> Key: LUCENE-5331
> URL: https://issues.apache.org/jira/browse/LUCENE-5331
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Jerry Zhou
> Attachments: NestedSpanNearTest.java
>
>
> Nested spanNear queries do not work in some cases when repeating groups are 
> in the query.
> Test case is attached ...



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Updated] (LUCENE-5332) SpanNearQuery with multiple terms does not find match

[Jerry Zhou (JIRA)]

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

Jerry Zhou updated LUCENE-5332:
---

Attachment: MultiTermFlatSpanNearTest.java

> SpanNearQuery with multiple terms does not find match
> -
>
> Key: LUCENE-5332
> URL: https://issues.apache.org/jira/browse/LUCENE-5332
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Jerry Zhou
> Attachments: MultiTermFlatSpanNearTest.java
>
>
> A flat structure (non-nested) for a SpanNearQuery containing multiple terms 
> does not always find the correct match.
> Test case is attached ...



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Created] (LUCENE-5332) SpanNearQuery with multiple terms does not find match

[Jerry Zhou (JIRA)]

Jerry Zhou created LUCENE-5332:
--

 Summary: SpanNearQuery with multiple terms does not find match
 Key: LUCENE-5332
 URL: https://issues.apache.org/jira/browse/LUCENE-5332
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Jerry Zhou
 Attachments: MultiTermFlatSpanNearTest.java

A flat structure (non-nested) for a SpanNearQuery containing multiple terms 
does not always find the correct match.

Test case is attached ...



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Updated] (SOLR-5378) Suggester Version 2

[Areek Zillur (JIRA)]

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

Areek Zillur updated SOLR-5378:
---

Attachment: SOLR-5378.patch

Updated Patch:
 - Added (independent) Distributed support for suggester 
 - new test cases

> Suggester Version 2
> ---
>
> Key: SOLR-5378
> URL: https://issues.apache.org/jira/browse/SOLR-5378
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Areek Zillur
> Attachments: SOLR-5378.patch, SOLR-5378.patch, SOLR-5378.patch, 
> SOLR-5378.patch, SOLR-5378.patch, SOLR-5378.patch
>
>
> The idea is to add a new Suggester Component that will eventually replace the 
> Suggester support through the SpellCheck Component.
> This will enable Solr to fully utilize the Lucene suggester module (along 
> with supporting most of the existing features) in the following ways:
>- Dictionary pluggability (give users the option to choose the dictionary 
> implementation to use for their suggesters to consume)
>- Map the suggester options/ suggester result format (e.g. support for 
> payload)
>- The new Component will also allow us to have "beefier" Lookup support 
> instead of resorting to collation and such. (Move computation from query time 
> to index time) with more freedom
> In addition to this, this suggester version should also have support for 
> distributed support, which was awkward at best with the previous 
> implementation due to SpellCheck requirements.
> Config (index time) options:
>   - name - name of suggester
>   - sourceLocation - external file location (for file-based suggesters)
>   - lookupImpl - type of lookup to use [default JaspellLookupFactory]
>   - dictionaryImpl - type of dictionary to use (lookup input) [default
> (sourceLocation == null ? HighFrequencyDictionaryFactory : 
> FileDictionaryFactory)]
>   - storeDir - location to store in-memory data structure in disk
>   - buildOnCommit - command to build suggester for every commit
>   - buildOnOptimize - command to build suggester for every optimize
> Query time options:
>   - suggest.dictionary - name of suggester to use
>   - suggest.count - number of suggestions to return
>   - suggest.q - query to use for lookup
>   - suggest.build - command to build the suggester
>   - suggest.reload - command to reload the suggester
> Example query:
> {code}
> http://localhost:8983/solr/suggest?suggest.dictionary=mySuggester&suggest=true&suggest.build=true&suggest.q=elec
> {code}
> Distributed query:
> {code}
> http://localhost:7574/solr/suggest?suggest.dictionary=mySuggester&suggest=true&suggest.build=true&suggest.q=elec&shards=localhost:8983/solr,localhost:7574/solr&shards.qt=/suggest
> {code}
> Example Response:
> {code}
> 
>   
> 0
> 28
>   
>   build
>   
>   
> 
>   
> 2
> 
>   electronics and computer1
>   2199
>   
> 
> 
>   electronics
>   649
>   
> 
>   
> 
>   
> 
> {code}
> Example config file:
>- Using DocumentDictionary and FuzzySuggester 
>-- Suggestion on product_name sorted by popularity with the additional 
> product_id in the payload
> {code}  
>   
>   
> suggest_fuzzy_doc_dict
> FuzzyLookupFactory
> DocumentDictionaryFactory
> product_name
> popularity
> product_id
> suggest_fuzzy_doc_dict_payload
> text
>   
> 
> {code}
>   - Using DocumentExpressionDictionary and FuzzySuggester
>   -- Suggestion on product_name sorted by the expression "((price * 2) + 
> ln(popularity))" (where both price and popularity are fields in the document)
> {code}
> 
>   
> suggest_fuzzy_doc_expr_dict
> DocumentExpressionDictionaryFactory
> FuzzyLookupFactory
> product_name
> ((price * 2) + ln(popularity))
> 
>   weight
>   float
> 
> 
>   price
>   float
> 
> suggest_fuzzy_doc_expr_dict
> text
>   
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (SOLR-5378) Suggester Version 2

[Areek Zillur (JIRA)]

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

Areek Zillur commented on SOLR-5378:


Alexey Serba: Thanks for the insightful comment!
The suggester should work independently (without any other component) in the 
distributed case. I added a new patch which will allow the suggester component 
to do so.  

> Suggester Version 2
> ---
>
> Key: SOLR-5378
> URL: https://issues.apache.org/jira/browse/SOLR-5378
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Areek Zillur
> Attachments: SOLR-5378.patch, SOLR-5378.patch, SOLR-5378.patch, 
> SOLR-5378.patch, SOLR-5378.patch, SOLR-5378.patch
>
>
> The idea is to add a new Suggester Component that will eventually replace the 
> Suggester support through the SpellCheck Component.
> This will enable Solr to fully utilize the Lucene suggester module (along 
> with supporting most of the existing features) in the following ways:
>- Dictionary pluggability (give users the option to choose the dictionary 
> implementation to use for their suggesters to consume)
>- Map the suggester options/ suggester result format (e.g. support for 
> payload)
>- The new Component will also allow us to have "beefier" Lookup support 
> instead of resorting to collation and such. (Move computation from query time 
> to index time) with more freedom
> In addition to this, this suggester version should also have support for 
> distributed support, which was awkward at best with the previous 
> implementation due to SpellCheck requirements.
> Config (index time) options:
>   - name - name of suggester
>   - sourceLocation - external file location (for file-based suggesters)
>   - lookupImpl - type of lookup to use [default JaspellLookupFactory]
>   - dictionaryImpl - type of dictionary to use (lookup input) [default
> (sourceLocation == null ? HighFrequencyDictionaryFactory : 
> FileDictionaryFactory)]
>   - storeDir - location to store in-memory data structure in disk
>   - buildOnCommit - command to build suggester for every commit
>   - buildOnOptimize - command to build suggester for every optimize
> Query time options:
>   - suggest.dictionary - name of suggester to use
>   - suggest.count - number of suggestions to return
>   - suggest.q - query to use for lookup
>   - suggest.build - command to build the suggester
>   - suggest.reload - command to reload the suggester
> Example query:
> {code}
> http://localhost:8983/solr/suggest?suggest.dictionary=mySuggester&suggest=true&suggest.build=true&suggest.q=elec
> {code}
> Distributed query:
> {code}
> http://localhost:7574/solr/suggest?suggest.dictionary=mySuggester&suggest=true&suggest.build=true&suggest.q=elec&shards=localhost:8983/solr,localhost:7574/solr&shards.qt=/suggest
> {code}
> Example Response:
> {code}
> 
>   
> 0
> 28
>   
>   build
>   
>   
> 
>   
> 2
> 
>   electronics and computer1
>   2199
>   
> 
> 
>   electronics
>   649
>   
> 
>   
> 
>   
> 
> {code}
> Example config file:
>- Using DocumentDictionary and FuzzySuggester 
>-- Suggestion on product_name sorted by popularity with the additional 
> product_id in the payload
> {code}  
>   
>   
> suggest_fuzzy_doc_dict
> FuzzyLookupFactory
> DocumentDictionaryFactory
> product_name
> popularity
> product_id
> suggest_fuzzy_doc_dict_payload
> text
>   
> 
> {code}
>   - Using DocumentExpressionDictionary and FuzzySuggester
>   -- Suggestion on product_name sorted by the expression "((price * 2) + 
> ln(popularity))" (where both price and popularity are fields in the document)
> {code}
> 
>   
> suggest_fuzzy_doc_expr_dict
> DocumentExpressionDictionaryFactory
> FuzzyLookupFactory
> product_name
> ((price * 2) + ln(popularity))
> 
>   weight
>   float
> 
> 
>   price
>   float
> 
> suggest_fuzzy_doc_expr_dict
> text
>   
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-5283) Fail the build if ant test didn't execute any tests (everything filtered out).

[ASF subversion and git services (JIRA)]

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

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

Commit 1539457 from [~dawidweiss] in branch 'dev/trunk'
[ https://svn.apache.org/r1539457 ]

LUCENE-5283: Fail the build if ant test didn't execute any tests (everything 
filtered out). Take 2: after minor updates and comments from Uwe.

> Fail the build if ant test didn't execute any tests (everything filtered out).
> --
>
> Key: LUCENE-5283
> URL: https://issues.apache.org/jira/browse/LUCENE-5283
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 4.6, 5.0
>
> Attachments: LUCENE-5283.patch, LUCENE-5283.patch, LUCENE-5283.patch
>
>
> This should be an optional setting that defaults to 'false' (the build 
> proceeds).



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-5283) Fail the build if ant test didn't execute any tests (everything filtered out).

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-5283:
---

Hi Dawid:
This is obsolete with the groovy code, right?:


> Fail the build if ant test didn't execute any tests (everything filtered out).
> --
>
> Key: LUCENE-5283
> URL: https://issues.apache.org/jira/browse/LUCENE-5283
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 4.6, 5.0
>
> Attachments: LUCENE-5283.patch, LUCENE-5283.patch, LUCENE-5283.patch
>
>
> This should be an optional setting that defaults to 'false' (the build 
> proceeds).



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Comment Edited] (LUCENE-5283) Fail the build if ant test didn't execute any tests (everything filtered out).

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on LUCENE-5283 at 11/6/13 9:14 PM:


Hi Dawid:
This is obsolete with the groovy code, right?:
{code:xml}


{code}


was (Author: thetaphi):
Hi Dawid:
This is obsolete with the groovy code, right?:


> Fail the build if ant test didn't execute any tests (everything filtered out).
> --
>
> Key: LUCENE-5283
> URL: https://issues.apache.org/jira/browse/LUCENE-5283
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 4.6, 5.0
>
> Attachments: LUCENE-5283.patch, LUCENE-5283.patch, LUCENE-5283.patch
>
>
> This should be an optional setting that defaults to 'false' (the build 
> proceeds).



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Comment Edited] (LUCENE-5283) Fail the build if ant test didn't execute any tests (everything filtered out).

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on LUCENE-5283 at 11/6/13 9:26 PM:


Hi Dawid:
This is obsolete with the groovy code, right?:
{code:xml}


{code}
One additional thing: On the top-level "test", we should add the dependency to 
load groovy, to prevent permgen problems (the comment before explains this for 
the clover one where the same applies). By this, groovy is resolved and 
installed before any modules are run.

The problem is: Dependencies of targets are executed in any case, also 
if/unless wuld not run the target itsself. So every submodule would load groovy 
and then not using it. So it should be loaded before.



was (Author: thetaphi):
Hi Dawid:
This is obsolete with the groovy code, right?:
{code:xml}


{code}

> Fail the build if ant test didn't execute any tests (everything filtered out).
> --
>
> Key: LUCENE-5283
> URL: https://issues.apache.org/jira/browse/LUCENE-5283
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 4.6, 5.0
>
> Attachments: LUCENE-5283.patch, LUCENE-5283.patch, LUCENE-5283.patch
>
>
> This should be an optional setting that defaults to 'false' (the build 
> proceeds).



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Updated] (LUCENE-5283) Fail the build if ant test didn't execute any tests (everything filtered out).

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated LUCENE-5283:
--

Attachment: LUCENE-5283-permgen.patch

Here the fix. Now its much less verbose, because groovy is only loaded at the 
beginning and not in each module.

It also removes the loadfile.

> Fail the build if ant test didn't execute any tests (everything filtered out).
> --
>
> Key: LUCENE-5283
> URL: https://issues.apache.org/jira/browse/LUCENE-5283
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 4.6, 5.0
>
> Attachments: LUCENE-5283-permgen.patch, LUCENE-5283.patch, 
> LUCENE-5283.patch, LUCENE-5283.patch
>
>
> This should be an optional setting that defaults to 'false' (the build 
> proceeds).



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-5283) Fail the build if ant test didn't execute any tests (everything filtered out).

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-5283:
-

I actually deferred it on purpose but I see your point in trying to load 
everything possible up front so that permgen can explode early. The remaining 
stuff is indeed leftover garbage. Will apply your fix shortly.

> Fail the build if ant test didn't execute any tests (everything filtered out).
> --
>
> Key: LUCENE-5283
> URL: https://issues.apache.org/jira/browse/LUCENE-5283
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 4.6, 5.0
>
> Attachments: LUCENE-5283-permgen.patch, LUCENE-5283.patch, 
> LUCENE-5283.patch, LUCENE-5283.patch
>
>
> This should be an optional setting that defaults to 'false' (the build 
> proceeds).



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-5283) Fail the build if ant test didn't execute any tests (everything filtered out).

[ASF subversion and git services (JIRA)]

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

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

Commit 1539475 from [~dawidweiss] in branch 'dev/trunk'
[ https://svn.apache.org/r1539475 ]

LUCENE-5283: Fixup to prevent permgens, removed leftover junk (thx Uwe).

> Fail the build if ant test didn't execute any tests (everything filtered out).
> --
>
> Key: LUCENE-5283
> URL: https://issues.apache.org/jira/browse/LUCENE-5283
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 4.6, 5.0
>
> Attachments: LUCENE-5283-permgen.patch, LUCENE-5283.patch, 
> LUCENE-5283.patch, LUCENE-5283.patch
>
>
> This should be an optional setting that defaults to 'false' (the build 
> proceeds).



--
This message was sent by Atlassian JIRA
(v6.1#6144)

-
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 (32bit/jdk1.7.0_45) - Build # 3359 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Windows/3359/
Java: 32bit/jdk1.7.0_45 -server -XX:+UseParallelGC

1 tests failed.
REGRESSION:  org.apache.lucene.index.TestIndexWriterReader.testTooManySegments

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([B408059962BD948A:F29BCEB3BB5A2C59]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.lucene.index.TestIndexWriterReader.testTooManySegments(TestIndexWriterReader.java:1149)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at java.lang.Thread.run(Thread.java:744)




Build Log:
[...truncated 1087 lines...]
   [junit4] Suite: org.apache.lucene.index.TestIndexWriterReader
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestIndexWriterReader -Dtests.method=testTooManySegments 
-Dtests.seed=B408059962BD948A -Dtests.slow=true -Dtests.locale=en_CA 
-Dtests.timezone=Africa/Johannesburg -Dtests.file.encoding=UTF-8
   [junit4] FAILURE 0.44s | TestIndexWriterReader.testTooManySegments <<<
   [junit4]> Throwable #1: java.lang.AssertionError
   [junit4] 

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/8205/
Java: 64bit/jdk1.8.0-ea-b114 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 29623 lines...]
BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:421: The following 
error occurred while executing this line:
/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:257: The 
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:352: The 
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1990:
 The following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/module-build.xml:495: 
The following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/highlighter/build.xml:39:
 The following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/module-build.xml:79: 
The following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1860:
 Javadoc returned 1

Total time: 45 minutes 6 seconds
Build step 'Invoke Ant' marked build as failure
Description set: Java: 64bit/jdk1.8.0-ea-b114 -XX:+UseCompressedOops 
-XX:+UseConcMarkSweepGC
Archiving artifacts
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure



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

RE: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0-ea-b114) - Build # 8205 - Failure!

[Uwe Schindler]

Hi Rory,

We found another bug with b114, see 
http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/8205/console:
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Loading source files for package 
org.apache.lucene.search.highlight...
  [javadoc] Loading source files for package 
org.apache.lucene.search.postingshighlight...
  [javadoc] Loading source files for package 
org.apache.lucene.search.vectorhighlight...
  [javadoc] Constructing Javadoc information...
  [javadoc] Standard Doclet version 1.8.0-ea
  [javadoc] Building tree for all the packages and classes...
  [javadoc] com.sun.tools.javac.code.Symbol$CompletionFailure: class file for 
sun.util.locale.provider.LocaleProviderAdapter not found
  [javadoc] javadoc: error - com.sun.tools.javac.code.Symbol$CompletionFailure: 
class file for sun.util.locale.provider.LocaleProviderAdapter not found
  [javadoc] Generating 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/docs/highlighter/org/apache/lucene/search/postingshighlight/WholeBreakIterator.html...
  [javadoc] 1 error

Others have seen this, too:
https://www.java.net/forum/topic/jdk/java-se-snapshots-project-feedback/jdk8-b113-javadoc-dies-when-documenting-subclass-javatextnumberformat-any-wor

So there is already a bug report.

Uwe

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


> -Original Message-
> From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de]
> Sent: Wednesday, November 06, 2013 11:49 PM
> To: dev@lucene.apache.org; dwe...@apache.org
> Subject: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0-ea-b114) - Build #
> 8205 - Failure!
> 
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/8205/
> Java: 64bit/jdk1.8.0-ea-b114 -XX:+UseCompressedOops -
> XX:+UseConcMarkSweepGC
> 
> All tests passed
> 
> Build Log:
> [...truncated 29623 lines...]
> BUILD FAILED
> /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:421: The
> following error occurred while executing this line:
> /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:257:
> The following error occurred while executing this line:
> /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:352:
> The following error occurred while executing this line:
> /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-
> build.xml:1990: The following error occurred while executing this line:
> /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/module-
> build.xml:495: The following error occurred while executing this line:
> /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-
> Linux/lucene/highlighter/build.xml:39: The following error occurred while
> executing this line:
> /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/module-
> build.xml:79: The following error occurred while executing this line:
> /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-
> build.xml:1860: Javadoc returned 1
> 
> Total time: 45 minutes 6 seconds
> Build step 'Invoke Ant' marked build as failure Description set: Java:
> 64bit/jdk1.8.0-ea-b114 -XX:+UseCompressedOops -
> XX:+UseConcMarkSweepGC 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-5283) Fail the build if ant test didn't execute any tests (everything filtered out).

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-5283:


Thanks Dawid & Uwe!

> Fail the build if ant test didn't execute any tests (everything filtered out).
> --
>
> Key: LUCENE-5283
> URL: https://issues.apache.org/jira/browse/LUCENE-5283
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 4.6, 5.0
>
> Attachments: LUCENE-5283-permgen.patch, LUCENE-5283.patch, 
> LUCENE-5283.patch, LUCENE-5283.patch
>
>
> This should be an optional setting that defaults to 'false' (the build 
> proceeds).



--
This message was sent by Atlassian JIRA
(v6.1#6144)

-
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 # 965 - Failure!

[Policeman Jenkins Server]

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

1 tests failed.
REGRESSION:  
org.apache.lucene.analysis.core.TestBugInSomething.testUnicodeShinglesAndNgrams

Error Message:
Java heap space

Stack Trace:
java.lang.OutOfMemoryError: Java heap space
at 
__randomizedtesting.SeedInfo.seed([BA01CE700ABFAEEB:C47B4AD88359726A]:0)
at org.apache.lucene.util.ArrayUtil.grow(ArrayUtil.java:346)
at 
org.apache.lucene.codecs.memory.DirectPostingsFormat$DirectField.(DirectPostingsFormat.java:333)
at 
org.apache.lucene.codecs.memory.DirectPostingsFormat$DirectFields.(DirectPostingsFormat.java:129)
at 
org.apache.lucene.codecs.memory.DirectPostingsFormat.fieldsProducer(DirectPostingsFormat.java:113)
at 
org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$FieldsReader.(PerFieldPostingsFormat.java:195)
at 
org.apache.lucene.codecs.perfield.PerFieldPostingsFormat.fieldsProducer(PerFieldPostingsFormat.java:244)
at 
org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:115)
at org.apache.lucene.index.SegmentReader.(SegmentReader.java:95)
at 
org.apache.lucene.index.StandardDirectoryReader$1.doBody(StandardDirectoryReader.java:62)
at 
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:843)
at 
org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:52)
at org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:66)
at 
org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:736)
at org.apache.lucene.util.IOUtils.close(IOUtils.java:140)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:532)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:428)
at 
org.apache.lucene.analysis.core.TestBugInSomething.testUnicodeShinglesAndNgrams(TestBugInSomething.java:255)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)




Build Log:
[...truncated 5465 lines...]
   [junit4] Suite: org.apache.lucene.analysis.core.TestBugInSomething
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestBugInSomething 
-Dtests.method=testUnicodeShinglesAndNgrams -Dtests.seed=BA01CE700ABFAEEB 
-Dtests.slow=true -Dtests.locale=en_MT -Dtests.timezone=America/Regina 
-Dtests.file.encoding=US-ASCII
   [junit4] ERROR113s | TestBugInSomething.testUnicodeShinglesAndNgrams <<<
   [junit4]> Throwable #1: java.lang.OutOfMemoryError: Java heap space
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([BA01CE700ABFAEEB:C47B4AD88359726A]:0)
   [junit4]>at 
org.apache.lucene.util.ArrayUtil.grow(ArrayUtil.java:346)
   [junit4]>at 
org.apache.lucene.codecs.memory.DirectPostingsFormat$DirectField.(DirectPostingsFormat.java:333)
   [junit4]>at 
org.apache.lucene.codecs.memory.DirectPostingsFormat$DirectFields.(DirectPostingsFormat.java:129)
   [junit4]>at 
org.apache.lucene.codecs.memory.DirectPostingsFormat.fieldsProducer(DirectPostingsFormat.java:113)
   [junit4]>at 
org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$FieldsReader.(PerFieldPostingsFormat.java:195)
   [junit4]>at 
org.apache.lucene.codecs.perfield.PerFieldPostingsFormat.fieldsProducer(PerFieldPostingsFormat.java:244)
   [junit4]>at 
org.apache.lucene.index.S

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

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 29646 lines...]
BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:421: The following 
error occurred while executing this line:
/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:257: The 
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:352: The 
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1990:
 The following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/module-build.xml:495: 
The following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/highlighter/build.xml:39:
 The following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/module-build.xml:79: 
The following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1860:
 Javadoc returned 1

Total time: 45 minutes 31 seconds
Build step 'Invoke Ant' marked build as failure
Description set: Java: 64bit/jdk1.8.0-ea-b114 -XX:-UseCompressedOops 
-XX:+UseSerialGC
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-5331) nested SpanNearQuery with repeating groups does not find match

[Tim Allison (JIRA)]

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

Tim Allison commented on LUCENE-5331:
-

Might be related, but the following does incorrectly have a hit:

String value = "w x a b c d b c e y z";

Query query = createNestedSpanQuery("a b c d d b c e");

> nested SpanNearQuery with repeating groups does not find match
> --
>
> Key: LUCENE-5331
> URL: https://issues.apache.org/jira/browse/LUCENE-5331
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Jerry Zhou
> Attachments: NestedSpanNearTest.java
>
>
> Nested spanNear queries do not work in some cases when repeating groups are 
> in the query.
> Test case is attached ...



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Created] (SOLR-5426) org.apache.solr.common.SolrException; org.apache.solr.common.SolrException: org.apache.lucene.search.highlight.InvalidTokenOffsetsException: Token 0 exceeds length of prov

[Nikolay (JIRA)]

Nikolay created SOLR-5426:
-

 Summary: org.apache.solr.common.SolrException; 
org.apache.solr.common.SolrException: 
org.apache.lucene.search.highlight.InvalidTokenOffsetsException: Token 0 
exceeds length of provided text sized 840
 Key: SOLR-5426
 URL: https://issues.apache.org/jira/browse/SOLR-5426
 Project: Solr
  Issue Type: Bug
  Components: highlighter
Affects Versions: 4.4, 4.5.1
Reporter: Nikolay
Priority: Minor
 Fix For: 4.5.1, 4.4






--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Updated] (SOLR-5426) org.apache.solr.common.SolrException; org.apache.solr.common.SolrException: org.apache.lucene.search.highlight.InvalidTokenOffsetsException: Token 0 exceeds length of prov

[Nikolay (JIRA)]

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

Nikolay updated SOLR-5426:
--

Description: 
ERROR - 2013-11-07 10:17:15.797; org.apache.solr.common.SolrException; 
null:org.apache.solr.common.SolrException: 
org.apache.lucene.search.highlight.InvalidTokenOffsetsException: Token 0 
exceeds length of provided text sized 840
at 
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlightingByHighlighter(DefaultSolrHighlighter.java:542)
at 
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlighting(DefaultSolrHighlighter.java:414)
at 
org.apache.solr.handler.component.HighlightComponent.process(HighlightComponent.java:139)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:208)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1859)
at 
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:703)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:406)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:195)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:368)
at 
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
at 
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
at 
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
at 
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
at 
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
at 
org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Unknown Source)
Caused by: org.apache.lucene.search.highlight.InvalidTokenOffsetsException: 
Token 0 exceeds length of provided text sized 840
at 
org.apache.lucene.search.highlight.Highlighter.getBestTextFragments(Highlighter.java:225)
at 
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlightingByHighlighter(DefaultSolrHighlighter.java:527)
... 33 more


> org.apache.solr.common.SolrException; org.apache.solr.common.SolrException: 
> org.apache.lucene.search.highlight.InvalidTokenOffsetsException: Token 0 
> exceeds length of provided text sized 840
> --
>
> Key: SOLR-5426
> URL: https://issues.apache.org/jira/browse/SOLR-5426
> Project: Solr
>  Issue Type: Bug
>  Components: highlighter
>Affects Versions: 4.4, 4.5.1
>Reporter: Nikolay
>Priority: Minor
>
> ERROR - 2013-11-07 10:17:15.797; org.apache.solr.common.SolrException; 
> null:org.apache.solr.common.SolrException: 
> org.apache.lucene.search.highlight.InvalidTokenOffsetsException: Token 0 
> exceeds length of provided text sized 840
>   at 
> org.apache.solr.highlight.DefaultSolrHighlighter.do

[jira] [Updated] (SOLR-5426) org.apache.solr.common.SolrException; org.apache.solr.common.SolrException: org.apache.lucene.search.highlight.InvalidTokenOffsetsException: Token 0 exceeds length of prov

[Nikolay (JIRA)]

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

Nikolay updated SOLR-5426:
--

Description: 


ERROR - 2013-11-07 10:17:15.797; org.apache.solr.common.SolrException; 
null:org.apache.solr.common.SolrException: 
org.apache.lucene.search.highlight.InvalidTokenOffsetsException: Token 0 
exceeds length of provided text sized 840
at 
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlightingByHighlighter(DefaultSolrHighlighter.java:542)
at 
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlighting(DefaultSolrHighlighter.java:414)
at 
org.apache.solr.handler.component.HighlightComponent.process(HighlightComponent.java:139)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:208)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1859)
at 
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:703)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:406)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:195)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:368)
at 
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
at 
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
at 
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
at 
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
at 
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
at 
org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Unknown Source)
Caused by: org.apache.lucene.search.highlight.InvalidTokenOffsetsException: 
Token 0 exceeds length of provided text sized 840
at 
org.apache.lucene.search.highlight.Highlighter.getBestTextFragments(Highlighter.java:225)
at 
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlightingByHighlighter(DefaultSolrHighlighter.java:527)
... 33 more


  was:
ERROR - 2013-11-07 10:17:15.797; org.apache.solr.common.SolrException; 
null:org.apache.solr.common.SolrException: 
org.apache.lucene.search.highlight.InvalidTokenOffsetsException: Token 0 
exceeds length of provided text sized 840
at 
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlightingByHighlighter(DefaultSolrHighlighter.java:542)
at 
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlighting(DefaultSolrHighlighter.java:414)
at 
org.apache.solr.handler.component.HighlightComponent.process(HighlightComponent.java:139)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:208)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1859)
at 
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:703)
at 
org.apache.solr.servlet.SolrDispatchFilter

[jira] [Updated] (SOLR-5426) org.apache.solr.common.SolrException; org.apache.solr.common.SolrException: org.apache.lucene.search.highlight.InvalidTokenOffsetsException: Token 0 exceeds length of prov

[Nikolay (JIRA)]

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

Nikolay updated SOLR-5426:
--

Fix Version/s: (was: 4.5.1)
   (was: 4.4)

> org.apache.solr.common.SolrException; org.apache.solr.common.SolrException: 
> org.apache.lucene.search.highlight.InvalidTokenOffsetsException: Token 0 
> exceeds length of provided text sized 840
> --
>
> Key: SOLR-5426
> URL: https://issues.apache.org/jira/browse/SOLR-5426
> Project: Solr
>  Issue Type: Bug
>  Components: highlighter
>Affects Versions: 4.4, 4.5.1
>Reporter: Nikolay
>Priority: Minor
>
> ERROR - 2013-11-07 10:17:15.797; org.apache.solr.common.SolrException; 
> null:org.apache.solr.common.SolrException: 
> org.apache.lucene.search.highlight.InvalidTokenOffsetsException: Token 0 
> exceeds length of provided text sized 840
>   at 
> org.apache.solr.highlight.DefaultSolrHighlighter.doHighlightingByHighlighter(DefaultSolrHighlighter.java:542)
>   at 
> org.apache.solr.highlight.DefaultSolrHighlighter.doHighlighting(DefaultSolrHighlighter.java:414)
>   at 
> org.apache.solr.handler.component.HighlightComponent.process(HighlightComponent.java:139)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:208)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1859)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:703)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:406)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:195)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>   at org.eclipse.jetty.server.Server.handle(Server.java:368)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
>   at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
>   at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
>   at 
> org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>   at java.lang.Thread.run(Unknown Source)
> Caused by: org.apache.lucene.search.highlight.InvalidTokenOffsetsException: 
> Token 0 exceeds length of provided text sized 840
>   at 
> org.apache.lucene.search.highlight.Highlighter.getBestTextFragments(Highlighter.java:225)
>   at 
> org.apache.solr.highlight.DefaultSolrHighlighter.doHighlightingByHighlighter(DefaultSolrHighlighter.java:527)
>   ... 33 more



--
This message was sent by Atlassian JIRA
(v6.1#6144)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apac

[jira] [Updated] (SOLR-5426) org.apache.solr.common.SolrException; org.apache.solr.common.SolrException: org.apache.lucene.search.highlight.InvalidTokenOffsetsException: Token 0 exceeds length of prov

[Nikolay (JIRA)]

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

Nikolay updated SOLR-5426:
--

Attachment: highlighter.zip

data for reproduce the bug, folder "global" contains lucene index, also there 
are 2 config files (schema.xml, solrconfig.xml)

> org.apache.solr.common.SolrException; org.apache.solr.common.SolrException: 
> org.apache.lucene.search.highlight.InvalidTokenOffsetsException: Token 0 
> exceeds length of provided text sized 840
> --
>
> Key: SOLR-5426
> URL: https://issues.apache.org/jira/browse/SOLR-5426
> Project: Solr
>  Issue Type: Bug
>  Components: highlighter
>Affects Versions: 4.4, 4.5.1
>Reporter: Nikolay
>Priority: Minor
> Attachments: highlighter.zip
>
>
> ERROR - 2013-11-07 10:17:15.797; org.apache.solr.common.SolrException; 
> null:org.apache.solr.common.SolrException: 
> org.apache.lucene.search.highlight.InvalidTokenOffsetsException: Token 0 
> exceeds length of provided text sized 840
>   at 
> org.apache.solr.highlight.DefaultSolrHighlighter.doHighlightingByHighlighter(DefaultSolrHighlighter.java:542)
>   at 
> org.apache.solr.highlight.DefaultSolrHighlighter.doHighlighting(DefaultSolrHighlighter.java:414)
>   at 
> org.apache.solr.handler.component.HighlightComponent.process(HighlightComponent.java:139)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:208)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1859)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:703)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:406)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:195)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>   at org.eclipse.jetty.server.Server.handle(Server.java:368)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
>   at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
>   at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
>   at 
> org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>   at java.lang.Thread.run(Unknown Source)
> Caused by: org.apache.lucene.search.highlight.InvalidTokenOffsetsException: 
> Token 0 exceeds length of provided text sized 840
>   at 
> org.apache.lucene.search.highlight.Highlighter.getBestTextFragments(Highlighter.java:225)
>   at 
> org.apache.solr.highlight.DefaultSolrHighlighter.doHighlightingByHighlighter(DefaultSolrHighlighter.java:527)
>   ... 33 more



--
This message was sent by Atlassian JIRA
(v6

[jira] [Updated] (SOLR-5426) org.apache.solr.common.SolrException; org.apache.solr.common.SolrException: org.apache.lucene.search.highlight.InvalidTokenOffsetsException: Token 0 exceeds length of prov

[Nikolay (JIRA)]

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

Nikolay updated SOLR-5426:
--

Description: 
Highlighter does not work correctly on test-data.
Could you try to reproduce this issue? 
I added index and config files (see attached )


ERROR - 2013-11-07 10:17:15.797; org.apache.solr.common.SolrException; 
null:org.apache.solr.common.SolrException: 
org.apache.lucene.search.highlight.InvalidTokenOffsetsException: Token 0 
exceeds length of provided text sized 840
at 
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlightingByHighlighter(DefaultSolrHighlighter.java:542)
at 
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlighting(DefaultSolrHighlighter.java:414)
at 
org.apache.solr.handler.component.HighlightComponent.process(HighlightComponent.java:139)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:208)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1859)
at 
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:703)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:406)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:195)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:368)
at 
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
at 
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
at 
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
at 
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
at 
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
at 
org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Unknown Source)
Caused by: org.apache.lucene.search.highlight.InvalidTokenOffsetsException: 
Token 0 exceeds length of provided text sized 840
at 
org.apache.lucene.search.highlight.Highlighter.getBestTextFragments(Highlighter.java:225)
at 
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlightingByHighlighter(DefaultSolrHighlighter.java:527)
... 33 more


  was:


ERROR - 2013-11-07 10:17:15.797; org.apache.solr.common.SolrException; 
null:org.apache.solr.common.SolrException: 
org.apache.lucene.search.highlight.InvalidTokenOffsetsException: Token 0 
exceeds length of provided text sized 840
at 
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlightingByHighlighter(DefaultSolrHighlighter.java:542)
at 
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlighting(DefaultSolrHighlighter.java:414)
at 
org.apache.solr.handler.component.HighlightComponent.process(HighlightComponent.java:139)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:208)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1859)
   

[jira] [Updated] (SOLR-5426) org.apache.solr.common.SolrException; org.apache.solr.common.SolrException: org.apache.lucene.search.highlight.InvalidTokenOffsetsException: Token 0 exceeds length of prov

[Nikolay (JIRA)]

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

Nikolay updated SOLR-5426:
--

Description: 
Highlighter does not work correctly on test-data.
I added index- and config- files (see attached highlighter.zip) for reproducing 
this issue.
Everything works fine if I search without highlighting:

http://localhost:8983/solr/global/select?q=aa&wt=json&indent=true

But if search with highlighting: 

http://localhost:8983/solr/global/select?q=aa&wt=json&indent=true&hl=true&hl.fl=*_stx&hl.simple.pre=&hl.simple.post=<%2Fem>

I'm get the error:

ERROR - 2013-11-07 10:17:15.797; org.apache.solr.common.SolrException; 
null:org.apache.solr.common.SolrException: 
org.apache.lucene.search.highlight.InvalidTokenOffsetsException: Token 0 
exceeds length of provided text sized 840
at 
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlightingByHighlighter(DefaultSolrHighlighter.java:542)
at 
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlighting(DefaultSolrHighlighter.java:414)
at 
org.apache.solr.handler.component.HighlightComponent.process(HighlightComponent.java:139)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:208)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1859)
at 
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:703)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:406)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:195)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:368)
at 
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
at 
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
at 
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
at 
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
at 
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
at 
org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Unknown Source)
Caused by: org.apache.lucene.search.highlight.InvalidTokenOffsetsException: 
Token 0 exceeds length of provided text sized 840
at 
org.apache.lucene.search.highlight.Highlighter.getBestTextFragments(Highlighter.java:225)
at 
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlightingByHighlighter(DefaultSolrHighlighter.java:527)
... 33 more


  was:
Highlighter does not work correctly on test-data.
Could you try to reproduce this issue? 
I added index and config files (see attached )


ERROR - 2013-11-07 10:17:15.797; org.apache.solr.common.SolrException; 
null:org.apache.solr.common.SolrException: 
org.apache.lucene.search.highlight.InvalidTokenOffsetsException: Token 0 
exceeds length of provided text sized 840
at 
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlightingByHighlighter(DefaultSolrHighlighter.java:542)
at 
org.apache.solr.highlight.Defa

[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0-ea-b114) - Build # 8209 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/8209/
Java: 64bit/jdk1.8.0-ea-b114 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 29515 lines...]
BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:421: The following 
error occurred while executing this line:
/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:257: The 
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:352: The 
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1990:
 The following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/module-build.xml:495: 
The following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/highlighter/build.xml:39:
 The following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/module-build.xml:79: 
The following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1860:
 Javadoc returned 1

Total time: 46 minutes 50 seconds
Build step 'Invoke Ant' marked build as failure
Description set: Java: 64bit/jdk1.8.0-ea-b114 -XX:+UseCompressedOops 
-XX:+UseConcMarkSweepGC
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] [Assigned] (SOLR-5378) Suggester Version 2

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar reassigned SOLR-5378:
---

Assignee: Shalin Shekhar Mangar

> Suggester Version 2
> ---
>
> Key: SOLR-5378
> URL: https://issues.apache.org/jira/browse/SOLR-5378
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Areek Zillur
>Assignee: Shalin Shekhar Mangar
> Attachments: SOLR-5378.patch, SOLR-5378.patch, SOLR-5378.patch, 
> SOLR-5378.patch, SOLR-5378.patch, SOLR-5378.patch
>
>
> The idea is to add a new Suggester Component that will eventually replace the 
> Suggester support through the SpellCheck Component.
> This will enable Solr to fully utilize the Lucene suggester module (along 
> with supporting most of the existing features) in the following ways:
>- Dictionary pluggability (give users the option to choose the dictionary 
> implementation to use for their suggesters to consume)
>- Map the suggester options/ suggester result format (e.g. support for 
> payload)
>- The new Component will also allow us to have "beefier" Lookup support 
> instead of resorting to collation and such. (Move computation from query time 
> to index time) with more freedom
> In addition to this, this suggester version should also have support for 
> distributed support, which was awkward at best with the previous 
> implementation due to SpellCheck requirements.
> Config (index time) options:
>   - name - name of suggester
>   - sourceLocation - external file location (for file-based suggesters)
>   - lookupImpl - type of lookup to use [default JaspellLookupFactory]
>   - dictionaryImpl - type of dictionary to use (lookup input) [default
> (sourceLocation == null ? HighFrequencyDictionaryFactory : 
> FileDictionaryFactory)]
>   - storeDir - location to store in-memory data structure in disk
>   - buildOnCommit - command to build suggester for every commit
>   - buildOnOptimize - command to build suggester for every optimize
> Query time options:
>   - suggest.dictionary - name of suggester to use
>   - suggest.count - number of suggestions to return
>   - suggest.q - query to use for lookup
>   - suggest.build - command to build the suggester
>   - suggest.reload - command to reload the suggester
> Example query:
> {code}
> http://localhost:8983/solr/suggest?suggest.dictionary=mySuggester&suggest=true&suggest.build=true&suggest.q=elec
> {code}
> Distributed query:
> {code}
> http://localhost:7574/solr/suggest?suggest.dictionary=mySuggester&suggest=true&suggest.build=true&suggest.q=elec&shards=localhost:8983/solr,localhost:7574/solr&shards.qt=/suggest
> {code}
> Example Response:
> {code}
> 
>   
> 0
> 28
>   
>   build
>   
>   
> 
>   
> 2
> 
>   electronics and computer1
>   2199
>   
> 
> 
>   electronics
>   649
>   
> 
>   
> 
>   
> 
> {code}
> Example config file:
>- Using DocumentDictionary and FuzzySuggester 
>-- Suggestion on product_name sorted by popularity with the additional 
> product_id in the payload
> {code}  
>   
>   
> suggest_fuzzy_doc_dict
> FuzzyLookupFactory
> DocumentDictionaryFactory
> product_name
> popularity
> product_id
> suggest_fuzzy_doc_dict_payload
> text
>   
> 
> {code}
>   - Using DocumentExpressionDictionary and FuzzySuggester
>   -- Suggestion on product_name sorted by the expression "((price * 2) + 
> ln(popularity))" (where both price and popularity are fields in the document)
> {code}
> 
>   
> suggest_fuzzy_doc_expr_dict
> DocumentExpressionDictionaryFactory
> FuzzyLookupFactory
> product_name
> ((price * 2) + ln(popularity))
> 
>   weight
>   float
> 
> 
>   price
>   float
> 
> suggest_fuzzy_doc_expr_dict
> text
>   
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (SOLR-5378) Suggester Version 2

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-5378:
-

This is looking awesome Areek! Thanks for contributing this. I'm going to spend 
some time this week going over this.

> Suggester Version 2
> ---
>
> Key: SOLR-5378
> URL: https://issues.apache.org/jira/browse/SOLR-5378
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Areek Zillur
>Assignee: Shalin Shekhar Mangar
> Attachments: SOLR-5378.patch, SOLR-5378.patch, SOLR-5378.patch, 
> SOLR-5378.patch, SOLR-5378.patch, SOLR-5378.patch
>
>
> The idea is to add a new Suggester Component that will eventually replace the 
> Suggester support through the SpellCheck Component.
> This will enable Solr to fully utilize the Lucene suggester module (along 
> with supporting most of the existing features) in the following ways:
>- Dictionary pluggability (give users the option to choose the dictionary 
> implementation to use for their suggesters to consume)
>- Map the suggester options/ suggester result format (e.g. support for 
> payload)
>- The new Component will also allow us to have "beefier" Lookup support 
> instead of resorting to collation and such. (Move computation from query time 
> to index time) with more freedom
> In addition to this, this suggester version should also have support for 
> distributed support, which was awkward at best with the previous 
> implementation due to SpellCheck requirements.
> Config (index time) options:
>   - name - name of suggester
>   - sourceLocation - external file location (for file-based suggesters)
>   - lookupImpl - type of lookup to use [default JaspellLookupFactory]
>   - dictionaryImpl - type of dictionary to use (lookup input) [default
> (sourceLocation == null ? HighFrequencyDictionaryFactory : 
> FileDictionaryFactory)]
>   - storeDir - location to store in-memory data structure in disk
>   - buildOnCommit - command to build suggester for every commit
>   - buildOnOptimize - command to build suggester for every optimize
> Query time options:
>   - suggest.dictionary - name of suggester to use
>   - suggest.count - number of suggestions to return
>   - suggest.q - query to use for lookup
>   - suggest.build - command to build the suggester
>   - suggest.reload - command to reload the suggester
> Example query:
> {code}
> http://localhost:8983/solr/suggest?suggest.dictionary=mySuggester&suggest=true&suggest.build=true&suggest.q=elec
> {code}
> Distributed query:
> {code}
> http://localhost:7574/solr/suggest?suggest.dictionary=mySuggester&suggest=true&suggest.build=true&suggest.q=elec&shards=localhost:8983/solr,localhost:7574/solr&shards.qt=/suggest
> {code}
> Example Response:
> {code}
> 
>   
> 0
> 28
>   
>   build
>   
>   
> 
>   
> 2
> 
>   electronics and computer1
>   2199
>   
> 
> 
>   electronics
>   649
>   
> 
>   
> 
>   
> 
> {code}
> Example config file:
>- Using DocumentDictionary and FuzzySuggester 
>-- Suggestion on product_name sorted by popularity with the additional 
> product_id in the payload
> {code}  
>   
>   
> suggest_fuzzy_doc_dict
> FuzzyLookupFactory
> DocumentDictionaryFactory
> product_name
> popularity
> product_id
> suggest_fuzzy_doc_dict_payload
> text
>   
> 
> {code}
>   - Using DocumentExpressionDictionary and FuzzySuggester
>   -- Suggestion on product_name sorted by the expression "((price * 2) + 
> ln(popularity))" (where both price and popularity are fields in the document)
> {code}
> 
>   
> suggest_fuzzy_doc_expr_dict
> DocumentExpressionDictionaryFactory
> FuzzyLookupFactory
> product_name
> ((price * 2) + ln(popularity))
> 
>   weight
>   float
> 
> 
>   price
>   float
> 
> suggest_fuzzy_doc_expr_dict
> text
>   
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

-
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-b114) - Build # 8113 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/8113/
Java: 64bit/jdk1.8.0-ea-b114 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 29696 lines...]
BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:428: The following 
error occurred while executing this line:
/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:257: The 
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build.xml:352: The 
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/common-build.xml:1919: 
The following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/module-build.xml:495: 
The following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/highlighter/build.xml:39:
 The following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/module-build.xml:79: 
The following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/common-build.xml:1789: 
Javadoc returned 1

Total time: 44 minutes 55 seconds
Build step 'Invoke Ant' marked build as failure
Description set: Java: 64bit/jdk1.8.0-ea-b114 -XX:-UseCompressedOops 
-XX:+UseConcMarkSweepGC
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

[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0-ea-b114) - Build # 8210 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/8210/
Java: 64bit/jdk1.8.0-ea-b114 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 29593 lines...]
BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:421: The following 
error occurred while executing this line:
/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:257: The 
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:352: The 
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1990:
 The following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/module-build.xml:495: 
The following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/highlighter/build.xml:39:
 The following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/module-build.xml:79: 
The following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1860:
 Javadoc returned 1

Total time: 42 minutes 57 seconds
Build step 'Invoke Ant' marked build as failure
Description set: Java: 64bit/jdk1.8.0-ea-b114 -XX:-UseCompressedOops 
-XX:+UseConcMarkSweepGC
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-5298) Allow aggregating facets by any ValueSource

[ASF subversion and git services (JIRA)]

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

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

Commit 1539541 from [~steve_rowe] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1539541 ]

LUCENE-5298: Maven config: add new lucene-queries dependency to the 
lucene-facet module; add new lucene-queries and lucene-expressions dependencies 
to the lucene-demo module

> Allow aggregating facets by any ValueSource
> ---
>
> Key: LUCENE-5298
> URL: https://issues.apache.org/jira/browse/LUCENE-5298
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/facet
>Reporter: Shai Erera
>Assignee: Shai Erera
> Fix For: 4.6, 5.0
>
> Attachments: LUCENE-5298.patch, LUCENE-5298.patch
>
>
> Facets can be aggregated today by counting them, aggregating by summing their 
> association values, or summing the scores of the documents. Applications can 
> write their own FacetsAggregator to compute the value of the facet in other 
> ways. Following the new expressions module, I think it will be interesting to 
> allow aggregating facets by arbitrary expressions, e.g. {{_score * 
> sqrt(price)}} where 'price' is an NDV field. I'd like to explore allowing any 
> ValueSource to be passed in and write a ValueSourceFacetsAggregator.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[Steve Rowe]

I committed a fix: LUCENE-5298 introduced new inter-module dependencies

On Nov 6, 2013, at 3:19 PM, Apache Jenkins Server  
wrote:

> Build: https://builds.apache.org/job/Lucene-Solr-Maven-4.x/499/
> 
> All tests passed
> 
> Build Log:
> [...truncated 31928 lines...]
>  [mvn] [INFO] 
> -
>  [mvn] [INFO] 
> -
>  [mvn] [ERROR] COMPILATION ERROR : 
>  [mvn] [INFO] 
> -
> 
> [...truncated 4780 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