Suggester Version 2 Code Complete

[Areek Zillur]

I sent out an email couple of weeks ago about the Suggester Version 2 (
https://issues.apache.org/jira/browse/SOLR-5378) and what I was planning to
improve. The status of the patch is now code-complete, along with
documentation (javadocs) and tests.

It would be awesome if I could get some feedback/input regarding the patch.

Here are some highlights (the options,config, request and response formats
are all detailed in the jira description):

Features:
  - Simplified Configuration
  - Added distributed support for Suggesters (merge using suggestion
weights)
  - Added dictionary pluggability support to allow easy way to manipulate
underlying suggester input (index time), along with factories for all
available lucene dictionaries.
  - Added statistics to be displayed [including size of the underlying
in-memory data structures created by various suggesters]

Available Dictionary Factories
  - DocumentDictionary - input from stored documents (users can specify
fields for suggestions, weight and optionally payload)
  - DocumentExpressionDictionary - same as DocumentDictionary but using
expressions to specify suggestion weights
  - FileDictionary - input from external file
  - HighFrequencyDictionary - input from documents but where weight is
the term frequency

Available lookup Factories (same as previous suggester version)
  - AnalyzingSuggester
  - FuzzySuggester
  - AnalyzingInfixSuggester
  - FSTLookup
  - JaspellLookup
  - TSTLookup
  - WFSTLookup

Thanks in advance,

Areek Zillur

[jira] [Commented] (SOLR-5320) Multi level compositeId router

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-5320:


[~ysee...@gmail.com] it'd be great if you could have a look at this and give 
some feedback.

> Multi level compositeId router
> --
>
> Key: SOLR-5320
> URL: https://issues.apache.org/jira/browse/SOLR-5320
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Reporter: Anshum Gupta
> Attachments: SOLR-5320-refactored.patch, SOLR-5320.patch, 
> SOLR-5320.patch, SOLR-5320.patch, SOLR-5320.patch
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> This would enable multi level routing as compared to the 2 level routing 
> available as of now. On the usage bit, here's an example:
> Document Id: myapp!dummyuser!doc
> myapp!dummyuser! can be used as the shardkey for searching content for 
> dummyuser.
> myapp! can be used for searching across all users of myapp.
> I am looking at either a 3 (or 4) level routing. The 32 bit hash would then 
> comprise of 8X4 components from each part (in case of 4 level).



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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/8086/
Java: 32bit/jdk1.7.0_45 -client -XX:+UseG1GC

1 tests failed.
REGRESSION:  org.apache.lucene.index.sorter.TestBlockJoinSorter.test

Error Message:
this codec cannot write docvalues

Stack Trace:
java.lang.UnsupportedOperationException: this codec cannot write docvalues
at 
__randomizedtesting.SeedInfo.seed([3B9A0C70055DC908:B3CE33AAABA1A4F0]:0)
at 
org.apache.lucene.codecs.lucene3x.Lucene3xCodec$1.fieldsConsumer(Lucene3xCodec.java:73)
at 
org.apache.lucene.index.DocValuesProcessor.flush(DocValuesProcessor.java:77)
at 
org.apache.lucene.index.TwoStoredFieldsConsumers.flush(TwoStoredFieldsConsumers.java:42)
at 
org.apache.lucene.index.DocFieldProcessor.flush(DocFieldProcessor.java:80)
at 
org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:465)
at 
org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:506)
at 
org.apache.lucene.index.DocumentsWriter.postUpdate(DocumentsWriter.java:378)
at 
org.apache.lucene.index.DocumentsWriter.updateDocuments(DocumentsWriter.java:432)
at 
org.apache.lucene.index.IndexWriter.updateDocuments(IndexWriter.java:1286)
at 
org.apache.lucene.index.IndexWriter.addDocuments(IndexWriter.java:1247)
at 
org.apache.lucene.index.IndexWriter.addDocuments(IndexWriter.java:1232)
at 
org.apache.lucene.index.RandomIndexWriter.addDocuments(RandomIndexWriter.java:167)
at 
org.apache.lucene.index.sorter.TestBlockJoinSorter.test(TestBlockJoinSorter.java:83)
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)

Re: [JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.7.0_45) - Build # 8086 - Failure!

[Adrien Grand]

I committed a fix.

On Tue, Nov 5, 2013 at 9:36 AM, Policeman Jenkins Server
 wrote:
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/8086/
> Java: 32bit/jdk1.7.0_45 -client -XX:+UseG1GC
>
> 1 tests failed.
> REGRESSION:  org.apache.lucene.index.sorter.TestBlockJoinSorter.test
>
> Error Message:
> this codec cannot write docvalues
>
> Stack Trace:
> java.lang.UnsupportedOperationException: this codec cannot write docvalues
> at 
> __randomizedtesting.SeedInfo.seed([3B9A0C70055DC908:B3CE33AAABA1A4F0]:0)
> at 
> org.apache.lucene.codecs.lucene3x.Lucene3xCodec$1.fieldsConsumer(Lucene3xCodec.java:73)
> at 
> org.apache.lucene.index.DocValuesProcessor.flush(DocValuesProcessor.java:77)
> at 
> org.apache.lucene.index.TwoStoredFieldsConsumers.flush(TwoStoredFieldsConsumers.java:42)
> at 
> org.apache.lucene.index.DocFieldProcessor.flush(DocFieldProcessor.java:80)
> at 
> org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:465)
> at 
> org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:506)
> at 
> org.apache.lucene.index.DocumentsWriter.postUpdate(DocumentsWriter.java:378)
> at 
> org.apache.lucene.index.DocumentsWriter.updateDocuments(DocumentsWriter.java:432)
> at 
> org.apache.lucene.index.IndexWriter.updateDocuments(IndexWriter.java:1286)
> at 
> org.apache.lucene.index.IndexWriter.addDocuments(IndexWriter.java:1247)
> at 
> org.apache.lucene.index.IndexWriter.addDocuments(IndexWriter.java:1232)
> at 
> org.apache.lucene.index.RandomIndexWriter.addDocuments(RandomIndexWriter.java:167)
> at 
> org.apache.lucene.index.sorter.TestBlockJoinSorter.test(TestBlockJoinSorter.java:83)
> 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.randomiz

[jira] [Created] (LUCENE-5329) Make DocumentDictionary and co more lenient to dirty documents

[Areek Zillur (JIRA)]

Areek Zillur created LUCENE-5329:


 Summary: Make DocumentDictionary and co more lenient to dirty 
documents
 Key: LUCENE-5329
 URL: https://issues.apache.org/jira/browse/LUCENE-5329
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/search
Reporter: Areek Zillur


Currently DocumentDictionary errors out whenever any document does not have 
value for any relevant stored fields. It would be nice to make it lenient and 
instead ignore the invalid documents.

Another "issue" with the DocumentDictionary is that it only allows string 
fields as suggestions and binary fields as payloads. When exposing these 
dictionaries to solr (via https://issues.apache.org/jira/browse/SOLR-5378), it 
is inconvenient for the user to ensure that a suggestion field is a string 
field and a payload field is a binary field. It would be nice to have the 
dictionary "just work" whenever a string/binary field is passed to 
suggestion/payload field. The patch provides one solution to this problem (by 
accepting string or binary values), though it would be great if there are any 
other solution to this, without making the DocumentDictionary "too flexible"



--
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-5329) Make DocumentDictionary and co more lenient to dirty documents

[Areek Zillur (JIRA)]

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

Areek Zillur updated LUCENE-5329:
-

Attachment: LUCENE-5329.patch

Initial patch:
  - skip documents that have any invalid fields
  - improved tests to test it
  - allow suggestion/payload field to accept string/binary values
  - improved documentation

> Make DocumentDictionary and co more lenient to dirty documents
> --
>
> Key: LUCENE-5329
> URL: https://issues.apache.org/jira/browse/LUCENE-5329
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Reporter: Areek Zillur
> Attachments: LUCENE-5329.patch
>
>
> Currently DocumentDictionary errors out whenever any document does not have 
> value for any relevant stored fields. It would be nice to make it lenient and 
> instead ignore the invalid documents.
> Another "issue" with the DocumentDictionary is that it only allows string 
> fields as suggestions and binary fields as payloads. When exposing these 
> dictionaries to solr (via https://issues.apache.org/jira/browse/SOLR-5378), 
> it is inconvenient for the user to ensure that a suggestion field is a string 
> field and a payload field is a binary field. It would be nice to have the 
> dictionary "just work" whenever a string/binary field is passed to 
> suggestion/payload field. The patch provides one solution to this problem (by 
> accepting string or binary values), though it would be great if there are any 
> other solution to this, without making the DocumentDictionary "too flexible"



--
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-5329) Make DocumentDictionary and co more lenient to dirty documents

[Varun Thacker (JIRA)]

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

Varun Thacker commented on LUCENE-5329:
---

Hi Areek,

I was asking myself the same question the other day.

I felt making payloads binary values was too restrictive. Also I thought if we 
don't use binary values you could have multiple payload fields.

A use case where multiple payload fields would be useful:
You have product autosuggest in an eCommerce store.
You might want back in the suggested document - link, image url, price etc. as 
payloads making it easier for someone for integrate.

Is there a negative side to making any such changes? 

> Make DocumentDictionary and co more lenient to dirty documents
> --
>
> Key: LUCENE-5329
> URL: https://issues.apache.org/jira/browse/LUCENE-5329
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Reporter: Areek Zillur
> Attachments: LUCENE-5329.patch
>
>
> Currently DocumentDictionary errors out whenever any document does not have 
> value for any relevant stored fields. It would be nice to make it lenient and 
> instead ignore the invalid documents.
> Another "issue" with the DocumentDictionary is that it only allows string 
> fields as suggestions and binary fields as payloads. When exposing these 
> dictionaries to solr (via https://issues.apache.org/jira/browse/SOLR-5378), 
> it is inconvenient for the user to ensure that a suggestion field is a string 
> field and a payload field is a binary field. It would be nice to have the 
> dictionary "just work" whenever a string/binary field is passed to 
> suggestion/payload field. The patch provides one solution to this problem (by 
> accepting string or binary values), though it would be great if there are any 
> other solution to this, without making the DocumentDictionary "too flexible"



--
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-5422) Support mask for dynamic fields in the language detection processor

[Irina Gorbunova (JIRA)]

Irina Gorbunova created SOLR-5422:
-

 Summary: Support mask for dynamic fields in the language detection 
processor
 Key: SOLR-5422
 URL: https://issues.apache.org/jira/browse/SOLR-5422
 Project: Solr
  Issue Type: Improvement
Reporter: Irina Gorbunova


h3. User Story
I need to stem multilingual document for indexing.
I have several fields to stem and I use update request processor with 
*langid.map.individual.fl*, because I need to define language individually for 
every field. I have troubles with multivalued field. There is a field *tag*. 
First, I made this field multivalued, because my documents can have several 
tags.
But processor didn't define language separately for *tag* values in follow case
{code}
"document" : {
...
"tag" : ["spanish", "español"]
...
}
{code}

So, I changed my schema and made field *tag* dynamic.
{code}
"document" : {
...
"tag_1" : "spanish",
"tag_2" : "español"
...
}
{code}
But language detection processor ignores field like tag_*.
Count of tags isn't limited for the document, so I can't define 
*langid.map.individual.fl* like tag_1, tag_2, ..., tag_37, because there can be 
tag_38 field in the document.

*So, I think it will be useful improvement if language detection processor 
supports definitions like*
{code}
blah*, *blahblah
blah*, *blahblah 
blah*, *blahblah
{code}

Or if there will be possibility to tell solr : "I want you define language of 
my multivalued field separately for every value"




--
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-5320) Multi level compositeId router

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-5320:
---

Description: 
This would enable multi level routing as compared to the 2 level routing 
available as of now. On the usage bit, here's an example:

Document Id: myapp!dummyuser!doc
myapp!dummyuser! can be used as the shardkey for searching content for 
dummyuser.
myapp! can be used for searching across all users of myapp.

I am looking at either a 3 (or 4) level routing. The 32 bit hash would then 
comprise of 8X4 components from each part (in case of 4 level).

Usage:

Document Id: myapp!dummyuser!doc

To query all users for a particular app (default setup), the route key should 
be: 'myapp/8!'.
To query a particular user for a specific app, the route key should be: 
'myapp!dummyuser!'

The syntax for querying all users for a particular app is required because this 
router works at both 2 and 3 level of composite id.
A route key of 'myapp!' would technically translate to constructing the hash 
range with 16 bits coming from the key i.e. 2-level composite id.

  was:
This would enable multi level routing as compared to the 2 level routing 
available as of now. On the usage bit, here's an example:

Document Id: myapp!dummyuser!doc
myapp!dummyuser! can be used as the shardkey for searching content for 
dummyuser.
myapp! can be used for searching across all users of myapp.

I am looking at either a 3 (or 4) level routing. The 32 bit hash would then 
comprise of 8X4 components from each part (in case of 4 level).


> Multi level compositeId router
> --
>
> Key: SOLR-5320
> URL: https://issues.apache.org/jira/browse/SOLR-5320
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Reporter: Anshum Gupta
> Attachments: SOLR-5320-refactored.patch, SOLR-5320.patch, 
> SOLR-5320.patch, SOLR-5320.patch, SOLR-5320.patch
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> This would enable multi level routing as compared to the 2 level routing 
> available as of now. On the usage bit, here's an example:
> Document Id: myapp!dummyuser!doc
> myapp!dummyuser! can be used as the shardkey for searching content for 
> dummyuser.
> myapp! can be used for searching across all users of myapp.
> I am looking at either a 3 (or 4) level routing. The 32 bit hash would then 
> comprise of 8X4 components from each part (in case of 4 level).
> Usage:
> Document Id: myapp!dummyuser!doc
> To query all users for a particular app (default setup), the route key should 
> be: 'myapp/8!'.
> To query a particular user for a specific app, the route key should be: 
> 'myapp!dummyuser!'
> The syntax for querying all users for a particular app is required because 
> this router works at both 2 and 3 level of composite id.
> A route key of 'myapp!' would technically translate to constructing the hash 
> range with 16 bits coming from the key i.e. 2-level composite id.



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

[Rory O'Donnell Oracle, Dublin ireland]

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/jdk8/jdk8/hotspot/rev/36b97be47bde
Issue: https://bugs.openjdk.java.net/browse/JDK-8011311

What happens:
When running Apache Lucene's UIMA tests (UIMA is foreign code, not
part

of Lucene):

cd lucene/analysis/uima
ant test

*All* tests fail here:

java.lang.IllegalAccessError: tried to access method

java.lang.Object.clone()Ljava/lang/Object; from class
org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase

at

__randomizedtesting.SeedInfo.seed([BC36C2DC5FC6C107:4A94D14D35381F8
8]:0)

at

org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.initialize(Anal

ysisEngineImplBase.java:163)

at

org.apache.uima.analysis_engine.impl.AggregateAnalysisEngine_impl.initializ

e(AggregateAnalysisEngine_impl.java:127)

at

org.apache.uima.impl.AnalysisEngineFactory_impl.produceResource(Analysi

sEngineFactory_impl.java:94)

at

org.apache.uima.impl.CompositeResourceFactory_impl.produceResource(C
ompositeResourceFactory_impl.java:62)

at

org.apache.ui

[jira] [Created] (SOLR-5423) CSV output doesn't include function field

[James Wilson (JIRA)]

James Wilson created SOLR-5423:
--

 Summary: CSV output doesn't include function field
 Key: SOLR-5423
 URL: https://issues.apache.org/jira/browse/SOLR-5423
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.4
Reporter: James Wilson


Given a schema with 

   
   
  
the following query returns no rows:

http://localhost:8983/solr/collection1/select?q=*%3A*&rows=30&fl=div(price%2Cnumpages)&wt=csv&indent=true

However, setting wt=json or wt=xml, it works.




--
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-1298) FunctionQuery results as pseudo-fields

[James Wilson (JIRA)]

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

James Wilson commented on SOLR-1298:


I just added https://issues.apache.org/jira/browse/SOLR-5423 but someone 
brought this story to my attention. Feel free to combine the stories.

> FunctionQuery results as pseudo-fields
> --
>
> Key: SOLR-1298
> URL: https://issues.apache.org/jira/browse/SOLR-1298
> Project: Solr
>  Issue Type: New Feature
>Reporter: Grant Ingersoll
>Assignee: Yonik Seeley
>Priority: Minor
> Fix For: 4.0-ALPHA
>
> Attachments: SOLR-1298-FieldValues.patch, SOLR-1298.patch
>
>
> It would be helpful if the results of FunctionQueries could be added as 
> fields to a document. 
> Couple of options here:
> 1. Run FunctionQuery as part of relevance score and add that piece to the 
> document
> 2. Run the function (not really a query) during Document/Field retrieval



--
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-4260) Inconsistent numDocs between leader and replica

[Yago Riveiro (JIRA)]

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

Yago Riveiro commented on SOLR-4260:


Hi, I hit this bug with solr 4.5.1

replica 1:

lastModified:20 minutes ago
version:80616
numDocs:6072661
maxDoc:6072841
deletedDocs:180

replica 2 (leader)

lastModified:20 minutes ago
version:77595
numDocs:6072575
maxDoc:6072771
deletedDocs:196

I don't know when this happened, therefore I have no time frame to find in log 
valuable information on logs.

> Inconsistent numDocs between leader and replica
> ---
>
> Key: SOLR-4260
> URL: https://issues.apache.org/jira/browse/SOLR-4260
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.0
> Environment: 5.0.0.2013.01.04.15.31.51
>Reporter: Markus Jelsma
>Priority: Critical
> Fix For: 5.0
>
>
> After wiping all cores and reindexing some 3.3 million docs from Nutch using 
> CloudSolrServer we see inconsistencies between the leader and replica for 
> some shards.
> Each core hold about 3.3k documents. For some reason 5 out of 10 shards have 
> a small deviation in then number of documents. The leader and slave deviate 
> for roughly 10-20 documents, not more.
> Results hopping ranks in the result set for identical queries got my 
> attention, there were small IDF differences for exactly the same record 
> causing a record to shift positions in the result set. During those tests no 
> records were indexed. Consecutive catch all queries also return different 
> number of numDocs.
> We're running a 10 node test cluster with 10 shards and a replication factor 
> of two and frequently reindex using a fresh build from trunk. I've not seen 
> this issue for quite some time until a few days ago.



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

DocValue on Strings slow and OOM

[Per Steffensen]

Hi

We have a 6-Solr-node (release 4.4.0) setup with 12billion "small" 
documents loadad. The documents have the following fields

* a_dlng_doc_sto
* b_dlng_doc_sto
* c_dstr_doc_sto
* timestamp_lng_ind_sto
* d_lng_ind_sto
From schema.xml
stored="true" required="true" docValues="true"/>
stored="true"/>
stored="true" required="true" docValues="true"/>

...
sortMissingLast="true" docValuesFormat="Disk"/>
positionIncrementGap="0" docValuesFormat="Disk"/>


We execute queries on the following format:
* q=timestamp_lng_ind_sto:[x TO y] AND d_lng_ind_sto:(a OR b OR ... OR n)
* facet=true&facet.field=&facet.zeros=false&facet.mincount=1

F.ex executing a query with values for x, y, a, b ... and n that hits 
only 6 documents (out of the 12billion) total
* With =a_dlng_doc_sto (long docvalue) the query responds fairly 
quick (< 2 sec)
* With =c_dstr_doc_sto (string docvalue) the query responds very 
slowly (> 100 sec) and only if we give the Solr-nodes a lot of Xmx. If 
Xmx is too low we experience OOM on involved Solr-nodes and never see a 
response
c_dstr_doc_sto strings are all about 10-15 chars, so it is not very long 
strings


Is it a known issue that there is such a big difference between facet 
searches on longs and strings? And that memory usage seems to very 
different, also?

If yes, has it been optimized after 4.4.0?

Regards, Per Steffensen

[jira] [Comment Edited] (SOLR-5167) Ability to use AnalyzingInfixSuggester in Solr

[Arcadius Ahouansou (JIRA)]

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

Arcadius Ahouansou edited comment on SOLR-5167 at 11/5/13 10:54 AM:


A quick question: 
Does this new AnalyzingInfixSuggester play well with NRT indexing? i.e does it 
pick up changes done via soft commit?

Thanks.



was (Author: arcadius):
A quick question: 
This this new AnalyzingInfixSuggester play well with NRT indexing? i.e does it 
pick up changes done via soft commit?

Thanks.


> Ability to use AnalyzingInfixSuggester in Solr
> --
>
> Key: SOLR-5167
> URL: https://issues.apache.org/jira/browse/SOLR-5167
> Project: Solr
>  Issue Type: New Feature
>  Components: SearchComponents - other
>Reporter: Varun Thacker
>Priority: Minor
> Fix For: 4.6, 5.0
>
> Attachments: SOLR-5167.patch, SOLR-5167.patch
>
>
> We should be able to use AnalyzingInfixSuggester in Solr by defining it in 
> solrconfig.xml



--
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-5167) Ability to use AnalyzingInfixSuggester in Solr

[Arcadius Ahouansou (JIRA)]

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

Arcadius Ahouansou commented on SOLR-5167:
--

A quick question: 
This this new AnalyzingInfixSuggester play well with NRT indexing? i.e does it 
pick up changes done via soft commit?

Thanks.


> Ability to use AnalyzingInfixSuggester in Solr
> --
>
> Key: SOLR-5167
> URL: https://issues.apache.org/jira/browse/SOLR-5167
> Project: Solr
>  Issue Type: New Feature
>  Components: SearchComponents - other
>Reporter: Varun Thacker
>Priority: Minor
> Fix For: 4.6, 5.0
>
> Attachments: SOLR-5167.patch, SOLR-5167.patch
>
>
> We should be able to use AnalyzingInfixSuggester in Solr by defining it in 
> solrconfig.xml



--
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-4260) Inconsistent numDocs between leader and replica

[Yago Riveiro (JIRA)]

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

Yago Riveiro updated SOLR-4260:
---

Attachment: 192.168.20.102-replica1.png
192.168.20.104-replica2.png
clusterstate.png

> Inconsistent numDocs between leader and replica
> ---
>
> Key: SOLR-4260
> URL: https://issues.apache.org/jira/browse/SOLR-4260
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.0
> Environment: 5.0.0.2013.01.04.15.31.51
>Reporter: Markus Jelsma
>Priority: Critical
> Fix For: 5.0
>
> Attachments: 192.168.20.102-replica1.png, 
> 192.168.20.104-replica2.png, clusterstate.png
>
>
> After wiping all cores and reindexing some 3.3 million docs from Nutch using 
> CloudSolrServer we see inconsistencies between the leader and replica for 
> some shards.
> Each core hold about 3.3k documents. For some reason 5 out of 10 shards have 
> a small deviation in then number of documents. The leader and slave deviate 
> for roughly 10-20 documents, not more.
> Results hopping ranks in the result set for identical queries got my 
> attention, there were small IDF differences for exactly the same record 
> causing a record to shift positions in the result set. During those tests no 
> records were indexed. Consecutive catch all queries also return different 
> number of numDocs.
> We're running a 10 node test cluster with 10 shards and a replication factor 
> of two and frequently reindex using a fresh build from trunk. I've not seen 
> this issue for quite some time until a few days ago.



--
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-4260) Inconsistent numDocs between leader and replica

[Yago Riveiro (JIRA)]

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

Yago Riveiro commented on SOLR-4260:


I attached some screenshots

1 - clusterstate: this screenshot shows replica2 192.168.20.104 as the leader
2 - the replica 2 has lower gen that replica1 and is the leader, is this 
correct?

> Inconsistent numDocs between leader and replica
> ---
>
> Key: SOLR-4260
> URL: https://issues.apache.org/jira/browse/SOLR-4260
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.0
> Environment: 5.0.0.2013.01.04.15.31.51
>Reporter: Markus Jelsma
>Priority: Critical
> Fix For: 5.0
>
> Attachments: 192.168.20.102-replica1.png, 
> 192.168.20.104-replica2.png, clusterstate.png
>
>
> After wiping all cores and reindexing some 3.3 million docs from Nutch using 
> CloudSolrServer we see inconsistencies between the leader and replica for 
> some shards.
> Each core hold about 3.3k documents. For some reason 5 out of 10 shards have 
> a small deviation in then number of documents. The leader and slave deviate 
> for roughly 10-20 documents, not more.
> Results hopping ranks in the result set for identical queries got my 
> attention, there were small IDF differences for exactly the same record 
> causing a record to shift positions in the result set. During those tests no 
> records were indexed. Consecutive catch all queries also return different 
> number of numDocs.
> We're running a 10 node test cluster with 10 shards and a replication factor 
> of two and frequently reindex using a fresh build from trunk. I've not seen 
> this issue for quite some time until a few days ago.



--
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] (SOLR-4260) Inconsistent numDocs between leader and replica

[Yago Riveiro (JIRA)]

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

Yago Riveiro edited comment on SOLR-4260 at 11/5/13 11:14 AM:
--

I attached some screenshots

The shard in question is the shard11:

1 - clusterstate: this screenshot shows replica2 192.168.20.104 as the leader
2 - the replica 2 has lower gen that replica1 and is the leader, is this 
correct?


was (Author: yriveiro):
I attached some screenshots

1 - clusterstate: this screenshot shows replica2 192.168.20.104 as the leader
2 - the replica 2 has lower gen that replica1 and is the leader, is this 
correct?

> Inconsistent numDocs between leader and replica
> ---
>
> Key: SOLR-4260
> URL: https://issues.apache.org/jira/browse/SOLR-4260
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.0
> Environment: 5.0.0.2013.01.04.15.31.51
>Reporter: Markus Jelsma
>Priority: Critical
> Fix For: 5.0
>
> Attachments: 192.168.20.102-replica1.png, 
> 192.168.20.104-replica2.png, clusterstate.png
>
>
> After wiping all cores and reindexing some 3.3 million docs from Nutch using 
> CloudSolrServer we see inconsistencies between the leader and replica for 
> some shards.
> Each core hold about 3.3k documents. For some reason 5 out of 10 shards have 
> a small deviation in then number of documents. The leader and slave deviate 
> for roughly 10-20 documents, not more.
> Results hopping ranks in the result set for identical queries got my 
> attention, there were small IDF differences for exactly the same record 
> causing a record to shift positions in the result set. During those tests no 
> records were indexed. Consecutive catch all queries also return different 
> number of numDocs.
> We're running a 10 node test cluster with 10 shards and a replication factor 
> of two and frequently reindex using a fresh build from trunk. I've not seen 
> this issue for quite some time until a few days ago.



--
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] (SOLR-4260) Inconsistent numDocs between leader and replica

[Yago Riveiro (JIRA)]

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

Yago Riveiro edited comment on SOLR-4260 at 11/5/13 11:15 AM:
--

I attached some screenshots

The shard is the shard11:

1 - clusterstate: this screenshot shows replica2 192.168.20.104 as the leader
2 - the replica 2 has lower gen that replica1 and is the leader, is this 
correct?


was (Author: yriveiro):
I attached some screenshots

The shard in question is the shard11:

1 - clusterstate: this screenshot shows replica2 192.168.20.104 as the leader
2 - the replica 2 has lower gen that replica1 and is the leader, is this 
correct?

> Inconsistent numDocs between leader and replica
> ---
>
> Key: SOLR-4260
> URL: https://issues.apache.org/jira/browse/SOLR-4260
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.0
> Environment: 5.0.0.2013.01.04.15.31.51
>Reporter: Markus Jelsma
>Priority: Critical
> Fix For: 5.0
>
> Attachments: 192.168.20.102-replica1.png, 
> 192.168.20.104-replica2.png, clusterstate.png
>
>
> After wiping all cores and reindexing some 3.3 million docs from Nutch using 
> CloudSolrServer we see inconsistencies between the leader and replica for 
> some shards.
> Each core hold about 3.3k documents. For some reason 5 out of 10 shards have 
> a small deviation in then number of documents. The leader and slave deviate 
> for roughly 10-20 documents, not more.
> Results hopping ranks in the result set for identical queries got my 
> attention, there were small IDF differences for exactly the same record 
> causing a record to shift positions in the result set. During those tests no 
> records were indexed. Consecutive catch all queries also return different 
> number of numDocs.
> We're running a 10 node test cluster with 10 shards and a replication factor 
> of two and frequently reindex using a fresh build from trunk. I've not seen 
> this issue for quite some time until a few days ago.



--
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-5386) Solr hangs on spellcheck.maxCollationTries

[Jeroen Steggink (JIRA)]

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

Jeroen Steggink commented on SOLR-5386:
---

James, it's very weird. I'm not able to recreate the problem with the same 
settings. I duplicated the core with a clean index. Now I don't have any 
problems at all. I guess something in the index is causing the problem. Do you 
have any tips on how to find out what is causing this strange behaviour?

> Solr hangs on spellcheck.maxCollationTries
> --
>
> Key: SOLR-5386
> URL: https://issues.apache.org/jira/browse/SOLR-5386
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 4.4, 4.5
>Reporter: Jeroen Steggink
>  Labels: collate, maxCollationTries, spellcheck
>
> When spellcheck.maxCollationTries is set (>0) Solr hangs in combination with 
> that requestHandler set to default="true".
> When I make another requestHandler default, one without the 
> maxCollationTries, all requestHandlers work just fine.



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

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


On 11/5/13 11:47 AM, Per Steffensen wrote:

Hi

We have a 6-Solr-node (release 4.4.0) setup with 12billion "small" 
documents loadad. The documents have the following fields

* a_dlng_doc_sto
* b_dlng_doc_sto
* c_dstr_doc_sto
* timestamp_lng_ind_sto
* d_lng_ind_sto
From schema.xml
stored="true" required="true" docValues="true"/>
stored="true"/>
stored="true" required="true" docValues="true"/>

...
sortMissingLast="true" docValuesFormat="Disk"/>
precisionStep="0" positionIncrementGap="0" docValuesFormat="Disk"/>


We execute queries on the following format:
* q=timestamp_lng_ind_sto:[x TO y] AND d_lng_ind_sto:(a OR b OR ... OR n)
* facet=true&facet.field=&facet.zeros=false&facet.mincount=1

F.ex executing a query with values for x, y, a, b ... and n that hits 
only 6 documents (out of the 12billion) total
* With =a_dlng_doc_sto (long docvalue) the query responds 
fairly quick (< 2 sec)
* With =c_dstr_doc_sto (string docvalue) the query responds 
very slowly (> 100 sec) and only if we give the Solr-nodes a lot of 
Xmx. If Xmx is too low we experience OOM on involved Solr-nodes and 
never see a response
c_dstr_doc_sto strings are all about 10-15 chars, so it is not very 
long strings


Is it a known issue that there is such a big difference between facet 
searches on longs and strings? And that memory usage seems to very 
different, also?

If yes, has it been optimized after 4.4.0?

Regards, Per Steffensen

[jira] [Comment Edited] (SOLR-5386) Solr hangs on spellcheck.maxCollationTries

[Jeroen Steggink (JIRA)]

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

Jeroen Steggink edited comment on SOLR-5386 at 11/5/13 12:48 PM:
-

James, it's very weird. I'm not able to recreate the problem with the same 
settings. I duplicated the core with a clean index. Now I don't have any 
problems at all. I guess something in the index is causing the problem. Do you 
have any tips on how to find out what is causing this strange behaviour?
Edit: After a re-index I no longer have the problem.


was (Author: jeroens):
James, it's very weird. I'm not able to recreate the problem with the same 
settings. I duplicated the core with a clean index. Now I don't have any 
problems at all. I guess something in the index is causing the problem. Do you 
have any tips on how to find out what is causing this strange behaviour?

> Solr hangs on spellcheck.maxCollationTries
> --
>
> Key: SOLR-5386
> URL: https://issues.apache.org/jira/browse/SOLR-5386
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 4.4, 4.5
>Reporter: Jeroen Steggink
>  Labels: collate, maxCollationTries, spellcheck
>
> When spellcheck.maxCollationTries is set (>0) Solr hangs in combination with 
> that requestHandler set to default="true".
> When I make another requestHandler default, one without the 
> maxCollationTries, all requestHandlers work just fine.



--
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: [jira] [Commented] (SOLR-1298) FunctionQuery results as pseudo-fields

[Erick Erickson]

They shouldn't be combined since 1298 is closed and works in the json and
xml case, just not in the CSV case. So your JIRA should be tracking this as
a separate issue

FWIW,
Erick


On Tue, Nov 5, 2013 at 5:15 AM, James Wilson (JIRA)  wrote:

>
> [
> https://issues.apache.org/jira/browse/SOLR-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13813822#comment-13813822]
>
> James Wilson commented on SOLR-1298:
> 
>
> I just added https://issues.apache.org/jira/browse/SOLR-5423 but someone
> brought this story to my attention. Feel free to combine the stories.
>
> > FunctionQuery results as pseudo-fields
> > --
> >
> > Key: SOLR-1298
> > URL: https://issues.apache.org/jira/browse/SOLR-1298
> > Project: Solr
> >  Issue Type: New Feature
> >Reporter: Grant Ingersoll
> >Assignee: Yonik Seeley
> >Priority: Minor
> > Fix For: 4.0-ALPHA
> >
> > Attachments: SOLR-1298-FieldValues.patch, SOLR-1298.patch
> >
> >
> > It would be helpful if the results of FunctionQueries could be added as
> fields to a document.
> > Couple of options here:
> > 1. Run FunctionQuery as part of relevance score and add that piece to
> the document
> > 2. Run the function (not really a query) during Document/Field retrieval
>
>
>
> --
> 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

[Robert Muir]

If you are querying on a field, you should index it!

On Tue, Nov 5, 2013 at 5:47 AM, Per Steffensen  wrote:
> Hi
>
> We have a 6-Solr-node (release 4.4.0) setup with 12billion "small" documents
> loadad. The documents have the following fields
> * a_dlng_doc_sto
> * b_dlng_doc_sto
> * c_dstr_doc_sto
> * timestamp_lng_ind_sto
> * d_lng_ind_sto
> From schema.xml
>  stored="true" required="true" docValues="true"/>
>  stored="true"/>
>  stored="true" required="true" docValues="true"/>
> ...
>  docValuesFormat="Disk"/>
>  positionIncrementGap="0" docValuesFormat="Disk"/>
>
> We execute queries on the following format:
> * q=timestamp_lng_ind_sto:[x TO y] AND d_lng_ind_sto:(a OR b OR ... OR n)
> * facet=true&facet.field=&facet.zeros=false&facet.mincount=1
>
> F.ex executing a query with values for x, y, a, b ... and n that hits only 6
> documents (out of the 12billion) total
> * With =a_dlng_doc_sto (long docvalue) the query responds fairly
> quick (< 2 sec)
> * With =c_dstr_doc_sto (string docvalue) the query responds very
> slowly (> 100 sec) and only if we give the Solr-nodes a lot of Xmx. If Xmx
> is too low we experience OOM on involved Solr-nodes and never see a response
> c_dstr_doc_sto strings are all about 10-15 chars, so it is not very long
> strings
>
> Is it a known issue that there is such a big difference between facet
> searches on longs and strings? And that memory usage seems to very
> different, also?
> If yes, has it been optimized after 4.4.0?
>
> Regards, Per Steffensen

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

On 11/5/13 3:30 PM, Robert Muir wrote:

If you are querying on a field, you should index it!
Believe I do that. Query looks like this "timestamp_lng_ind_sto:[x TO y] 
AND d_lng_ind_sto:(a OR b OR ... OR n)" and both "timestamp_lng_ind_sto" 
and "d_lng_ind_sto" are indexed.

Please elaborate!

I facet/group on fields that are indexed=false and docValues=true, but 
that is the case for both of the facet.fields "a_dlng_doc_sto" and 
"c_dstr_doc_sto", so it shouldnt explain the big difference between 
faceting on the long-field vs faceting on the string-field.




-
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

[Robert Muir]

On Tue, Nov 5, 2013 at 9:42 AM, Per Steffensen  wrote:
> On 11/5/13 3:30 PM, Robert Muir wrote:
>>
>> If you are querying on a field, you should index it!
>
> Believe I do that. Query looks like this "timestamp_lng_ind_sto:[x TO y] AND
> d_lng_ind_sto:(a OR b OR ... OR n)" and both "timestamp_lng_ind_sto" and
> "d_lng_ind_sto" are indexed.
> Please elaborate!
>

solr faceting often runs queries behind the scenes. please, only turn
off indexed=true if you are really really sure you do not need it.

and use 4.5.0 if you have memory concerns.

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

[jira] [Commented] (LUCENE-5327) Expose getNumericDocValues and getBinaryDocValues at toplevel reader and searcher levels

[John Wang (JIRA)]

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

John Wang commented on LUCENE-5327:
---

Oh, I didn't know about MultiDocValues.
I am happy to change it to use MultiDocValues. Before doing this, do you think 
this makes sense? I suppose there was a reason for leaving it out of the 
IndexReader api and introduce MultiDocValues in the first place?

> Expose getNumericDocValues and getBinaryDocValues at toplevel reader and 
> searcher levels
> 
>
> Key: LUCENE-5327
> URL: https://issues.apache.org/jira/browse/LUCENE-5327
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Affects Versions: 4.5
>Reporter: John Wang
> Attachments: patch.diff
>
>
> Expose NumericDocValues and BinaryDocValues in both IndexReader and 
> IndexSearcher apis.



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

[Erick Erickson]

H. I was just looking at the DocValues Wiki page. Should I add a bit
about docValuesFormat supporting "Disk" as a 4.5 plus feature? Currently it
kind of looks like you can do that with 4.2

Or am I off base here? I'm going from CHANGES.txt about LUCENE-5124

Erick


On Tue, Nov 5, 2013 at 9:46 AM, Robert Muir  wrote:

> On Tue, Nov 5, 2013 at 9:42 AM, Per Steffensen 
> wrote:
> > On 11/5/13 3:30 PM, Robert Muir wrote:
> >>
> >> If you are querying on a field, you should index it!
> >
> > Believe I do that. Query looks like this "timestamp_lng_ind_sto:[x TO y]
> AND
> > d_lng_ind_sto:(a OR b OR ... OR n)" and both "timestamp_lng_ind_sto" and
> > "d_lng_ind_sto" are indexed.
> > Please elaborate!
> >
>
> solr faceting often runs queries behind the scenes. please, only turn
> off indexed=true if you are really really sure you do not need it.
>
> and use 4.5.0 if you have memory concerns.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Updated] (LUCENE-5285) FastVectorHighlighter copies segments scores when splitting segments across multi-valued fields

[Nik Everett (JIRA)]

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

Nik Everett updated LUCENE-5285:


Attachment: (was: LUCENE-5285.patch)

> FastVectorHighlighter copies segments scores when splitting segments across 
> multi-valued fields
> ---
>
> Key: LUCENE-5285
> URL: https://issues.apache.org/jira/browse/LUCENE-5285
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Nik Everett
>Priority: Minor
> Attachments: LUCENE-5285.patch
>
>
> FastVectorHighlighter copies segments scores when splitting segments across 
> multi-valued fields.  This is only a problem when you want to sort the 
> fragments by score. Technically BaseFragmentsBuilder (line 261 in my copy of 
> the source) does the copying.
> Rather than copying the score I _think_ it'd be more right to pull that 
> copying logic into a protected method that child classes (such as 
> ScoreOrderFragmentsBuilder) can override to do more intelligent things.  
> Exactly what that means isn't clear to me at the moment.



--
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-4x-Linux-Java7-64-test-only - Build # 2034 - Still Failing!

[builder]

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

No tests ran.

Build Log:
[...truncated 5 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.SVNErrorM

[JENKINS] Lucene-4.5.1-Linux-Java7-64-test-only - Build # 2033 - Still Failing!

[builder]

Build: builds.flonkings.com/job/Lucene-4.5.1-Linux-Java7-64-test-only/2033/

No tests ran.

Build Log:
[...truncated 5 lines...]
ERROR: Failed to update 
http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_5
org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS 
/repos/asf/lucene/dev/branches/lucene_solr_4_5 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/lucene_solr_4_5 
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/lucene_solr_4_5'
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/lucene_solr_4_5'
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

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

[builder]

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

No tests ran.

Build Log:
[...truncated 5 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-trunk-Linux-Java7-64-test-only - Build # 65720 - Failure!

[builder]

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

No tests ran.

Build Log:
[...truncated 12 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.tmates

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

[builder]

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

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

[Cassandra Targett]

On Tue, Nov 5, 2013 at 3:27 PM, Erick Erickson  wrote:
> H. I was just looking at the DocValues Wiki page. Should I add a bit
> about docValuesFormat supporting "Disk" as a 4.5 plus feature? Currently it
> kind of looks like you can do that with 4.2
>

It's in the Solr Ref Guide:
https://cwiki.apache.org/confluence/display/solr/DocValues, fixed for
4.5

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

[jira] [Commented] (SOLR-5167) Ability to use AnalyzingInfixSuggester in Solr

[Michael McCandless (JIRA)]

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

Michael McCandless commented on SOLR-5167:
--

bq. Does this new AnalyzingInfixSuggester play well with NRT indexing?

It doesn't right now, but that should be simple to fix since it's just a Lucene 
index under the hood... patches welcome!

> Ability to use AnalyzingInfixSuggester in Solr
> --
>
> Key: SOLR-5167
> URL: https://issues.apache.org/jira/browse/SOLR-5167
> Project: Solr
>  Issue Type: New Feature
>  Components: SearchComponents - other
>Reporter: Varun Thacker
>Priority: Minor
> Fix For: 4.6, 5.0
>
> Attachments: SOLR-5167.patch, SOLR-5167.patch
>
>
> We should be able to use AnalyzingInfixSuggester in Solr by defining it in 
> solrconfig.xml



--
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-4.5.1-Linux-Java7-64-test-only - Build # 2032 - Failure!

[builder]

Build: builds.flonkings.com/job/Lucene-4.5.1-Linux-Java7-64-test-only/2032/

No tests ran.

Build Log:
[...truncated 14 lines...]
ERROR: Failed to update 
http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_5
org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS 
/repos/asf/lucene/dev/branches/lucene_solr_4_5 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/lucene_solr_4_5 
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/lucene_solr_4_5'
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/lucene_solr_4_5'
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
a

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

[Apache Jenkins Server]

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

No tests ran.

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



-
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

[Erick Erickson]

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



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


On Tue, Nov 5, 2013 at 11:43 AM, Cassandra Targett wrote:

> On Tue, Nov 5, 2013 at 3:27 PM, Erick Erickson 
> wrote:
> > H. I was just looking at the DocValues Wiki page. Should I add a bit
> > about docValuesFormat supporting "Disk" as a 4.5 plus feature? Currently
> it
> > kind of looks like you can do that with 4.2
> >
>
> It's in the Solr Ref Guide:
> https://cwiki.apache.org/confluence/display/solr/DocValues, fixed for
> 4.5
>
> -
> 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=13814155#comment-13814155
 ] 

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

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

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

> 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

[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=13814156#comment-13814156
 ] 

Dawid Weiss commented on LUCENE-5283:
-

Committed to trunk. Will let it settle a bit before backporting to 4x.

> 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

[jira] [Updated] (SOLR-5084) new field type - EnumField

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-5084:
-

Attachment: Solr-5084.trunk.patch

Some changes/additions. Mostly this is making tests work. The addition of the 
enum to the schema.xml file caused failures in other places that used that file 
but didn't have access to the underlying config files. I suspect they were 
somehow being found on Elran's machine but not on mine.

Anyway, new patch. I'll be committing momentarily.

> new field type - EnumField
> --
>
> Key: SOLR-5084
> URL: https://issues.apache.org/jira/browse/SOLR-5084
> Project: Solr
>  Issue Type: New Feature
>Reporter: Elran Dvir
>Assignee: Erick Erickson
> Attachments: Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, 
> Solr-5084.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
> Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
> Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
> enumsConfig.xml, schema_example.xml
>
>
> We have encountered a use case in our system where we have a few fields 
> (Severity. Risk etc) with a closed set of values, where the sort order for 
> these values is pre-determined but not lexicographic (Critical is higher than 
> High). Generically this is very close to how enums work.
> To implement, I have prototyped a new type of field: EnumField where the 
> inputs are a closed predefined  set of strings in a special configuration 
> file (similar to currency.xml).
> The code is based on 4.2.1.



--
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-5084) new field type - EnumField

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-5084:
-

Attachment: Solr-5084.trunk.patch

Added entry to CHANGES.txt for Solr.

> new field type - EnumField
> --
>
> Key: SOLR-5084
> URL: https://issues.apache.org/jira/browse/SOLR-5084
> Project: Solr
>  Issue Type: New Feature
>Reporter: Elran Dvir
>Assignee: Erick Erickson
> Attachments: Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, 
> Solr-5084.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
> Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
> Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
> Solr-5084.trunk.patch, enumsConfig.xml, schema_example.xml
>
>
> We have encountered a use case in our system where we have a few fields 
> (Severity. Risk etc) with a closed set of values, where the sort order for 
> these values is pre-determined but not lexicographic (Critical is higher than 
> High). Generically this is very close to how enums work.
> To implement, I have prototyped a new type of field: EnumField where the 
> inputs are a closed predefined  set of strings in a special configuration 
> file (similar to currency.xml).
> The code is based on 4.2.1.



--
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-5084) new field type - EnumField

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-5084: added enum field type to Solr

> new field type - EnumField
> --
>
> Key: SOLR-5084
> URL: https://issues.apache.org/jira/browse/SOLR-5084
> Project: Solr
>  Issue Type: New Feature
>Reporter: Elran Dvir
>Assignee: Erick Erickson
> Attachments: Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, 
> Solr-5084.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
> Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
> Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
> Solr-5084.trunk.patch, enumsConfig.xml, schema_example.xml
>
>
> We have encountered a use case in our system where we have a few fields 
> (Severity. Risk etc) with a closed set of values, where the sort order for 
> these values is pre-determined but not lexicographic (Critical is higher than 
> High). Generically this is very close to how enums work.
> To implement, I have prototyped a new type of field: EnumField where the 
> inputs are a closed predefined  set of strings in a special configuration 
> file (similar to currency.xml).
> The code is based on 4.2.1.



--
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-5084) new field type - EnumField

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-5084:
--

Elran:

I broke out the addition of the enums into the schema.xml used for testing into 
it's own file so we didn't have issues with other tests FWIW.

> new field type - EnumField
> --
>
> Key: SOLR-5084
> URL: https://issues.apache.org/jira/browse/SOLR-5084
> Project: Solr
>  Issue Type: New Feature
>Reporter: Elran Dvir
>Assignee: Erick Erickson
> Attachments: Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, 
> Solr-5084.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
> Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
> Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
> Solr-5084.trunk.patch, enumsConfig.xml, schema_example.xml
>
>
> We have encountered a use case in our system where we have a few fields 
> (Severity. Risk etc) with a closed set of values, where the sort order for 
> these values is pre-determined but not lexicographic (Critical is higher than 
> High). Generically this is very close to how enums work.
> To implement, I have prototyped a new type of field: EnumField where the 
> inputs are a closed predefined  set of strings in a special configuration 
> file (similar to currency.xml).
> The code is based on 4.2.1.



--
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-5329) Make DocumentDictionary and co more lenient to dirty documents

[Areek Zillur (JIRA)]

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

Areek Zillur commented on LUCENE-5329:
--

These are my thoughts on this:
  - From the Lucene Suggester perspective, it makes perfect sense to have the 
payload as a binary field. Because the payload is just 'stored' as is and then 
returned, no processing is done on it, hence it makes sense that the lucene 
suggester just treats it as binary data.
  - Having said that when exposing it from Solr, it would be nice to make it 
"just work", rather than the user having to make sure what field will spit what 
out, hence the proposed changes
  - Regarding the use-case with ecommerce store, the payload does not 
necessarily have  to be a field, it can be the aggregate of other fields or 
some arbitrary associated data. (though there is no way to do so in Solr now, 
but I plan to make it possible with the new Solr Suggester (SOLR-5378) :).
  - As far as I understand, payloads should remain binary in the Lucene 
Suggesters, but the dilemma is whether the input to the suggester be flexible 

> Make DocumentDictionary and co more lenient to dirty documents
> --
>
> Key: LUCENE-5329
> URL: https://issues.apache.org/jira/browse/LUCENE-5329
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Reporter: Areek Zillur
> Attachments: LUCENE-5329.patch
>
>
> Currently DocumentDictionary errors out whenever any document does not have 
> value for any relevant stored fields. It would be nice to make it lenient and 
> instead ignore the invalid documents.
> Another "issue" with the DocumentDictionary is that it only allows string 
> fields as suggestions and binary fields as payloads. When exposing these 
> dictionaries to solr (via https://issues.apache.org/jira/browse/SOLR-5378), 
> it is inconvenient for the user to ensure that a suggestion field is a string 
> field and a payload field is a binary field. It would be nice to have the 
> dictionary "just work" whenever a string/binary field is passed to 
> suggestion/payload field. The patch provides one solution to this problem (by 
> accepting string or binary values), though it would be great if there are any 
> other solution to this, without making the DocumentDictionary "too flexible"



--
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-5316) Taxonomy tree traversing improvement

[Gilad Barkai (JIRA)]

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

Gilad Barkai updated LUCENE-5316:
-

Attachment: LUCENE-5316.patch

Introducing a map-based children iterator, which holds for every ordinal (real 
parent) an {{int[]}} containing its direct children.

Each such {{int[]}} has an extra last slot for 
{{TaxonomyReader.INVALID_ORDINAL}} which spares an {{if}} call for every 
{{ChildrenIterator.next()}} call. 

This is a quick and dirty patch, just so we could verify the penalty for moving 
to the API/map is not great. If it is great, the whole issue should be 
reconsidered, and perhaps a move to direct {{int[]}} for iterating over 
children should be implemented.

> 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...@lucene.apache.org

[jira] [Created] (SOLR-5424) /solr/select/ returned fields

[antoine s (JIRA)]

antoine s created SOLR-5424:
---

 Summary: /solr/select/ returned fields
 Key: SOLR-5424
 URL: https://issues.apache.org/jira/browse/SOLR-5424
 Project: Solr
  Issue Type: Bug
 Environment: 
solr-spec
4.5.1

solr-impl
4.5.1 1533280 - mark - 2013-10-17 21:44:41

lucene-spec
4.5.1

lucene-impl
4.5.1 1533280 - mark - 2013-10-17 21:40:03
Reporter: antoine s


I have a field in schema.xml 
 

http://localhost:8983/solr/select/?q=video&defType=edismax&qf=name^20.0+text^0.3
 
does not return the 'description' 

http://localhost:8983/solr/select/?q=video&defType=edismax&qf=name^20.0+text^0.3
 
returns it



--
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-5084) new field type - EnumField

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-5084: new enum field type

> new field type - EnumField
> --
>
> Key: SOLR-5084
> URL: https://issues.apache.org/jira/browse/SOLR-5084
> Project: Solr
>  Issue Type: New Feature
>Reporter: Elran Dvir
>Assignee: Erick Erickson
> Fix For: 4.6, 5.0
>
> Attachments: Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, 
> Solr-5084.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
> Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
> Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
> Solr-5084.trunk.patch, enumsConfig.xml, schema_example.xml
>
>
> We have encountered a use case in our system where we have a few fields 
> (Severity. Risk etc) with a closed set of values, where the sort order for 
> these values is pre-determined but not lexicographic (Critical is higher than 
> High). Generically this is very close to how enums work.
> To implement, I have prototyped a new type of field: EnumField where the 
> inputs are a closed predefined  set of strings in a special configuration 
> file (similar to currency.xml).
> The code is based on 4.2.1.



--
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-5084) new field type - EnumField

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-5084.
--

   Resolution: Fixed
Fix Version/s: 5.0
   4.6

I had a bit of work to reconcile the trunk and 4x versions, there's 
StorableField used in the patch that's not available in 4.x, but I think it's 
just a rename.

We can open up any issues with enums in new JIRAs.

> new field type - EnumField
> --
>
> Key: SOLR-5084
> URL: https://issues.apache.org/jira/browse/SOLR-5084
> Project: Solr
>  Issue Type: New Feature
>Reporter: Elran Dvir
>Assignee: Erick Erickson
> Fix For: 4.6, 5.0
>
> Attachments: Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, 
> Solr-5084.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
> Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
> Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
> Solr-5084.trunk.patch, enumsConfig.xml, schema_example.xml
>
>
> We have encountered a use case in our system where we have a few fields 
> (Severity. Risk etc) with a closed set of values, where the sort order for 
> these values is pre-determined but not lexicographic (Critical is higher than 
> High). Generically this is very close to how enums work.
> To implement, I have prototyped a new type of field: EnumField where the 
> inputs are a closed predefined  set of strings in a special configuration 
> file (similar to currency.xml).
> The code is based on 4.2.1.



--
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-5084) new field type - EnumField

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-5084:
--

Thanks Elran!!

> new field type - EnumField
> --
>
> Key: SOLR-5084
> URL: https://issues.apache.org/jira/browse/SOLR-5084
> Project: Solr
>  Issue Type: New Feature
>Reporter: Elran Dvir
>Assignee: Erick Erickson
> Fix For: 4.6, 5.0
>
> Attachments: Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, 
> Solr-5084.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
> Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
> Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
> Solr-5084.trunk.patch, enumsConfig.xml, schema_example.xml
>
>
> We have encountered a use case in our system where we have a few fields 
> (Severity. Risk etc) with a closed set of values, where the sort order for 
> these values is pre-determined but not lexicographic (Critical is higher than 
> High). Generically this is very close to how enums work.
> To implement, I have prototyped a new type of field: EnumField where the 
> inputs are a closed predefined  set of strings in a special configuration 
> file (similar to currency.xml).
> The code is based on 4.2.1.



--
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-trunk-Linux (64bit/jdk1.8.0-ea-b109) - Build # 8189 - Still Failing!

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 36008 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:360: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/extra-targets.xml:66: The 
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/extra-targets.xml:137: 
Source checkout is dirty after running tests!!! Offending files:
* ./lucene/.test-totals-922324336062316929.tmp
* ./solr/.test-totals-5710645736889619892.tmp

Total time: 50 minutes 15 seconds
Build step 'Invoke Ant' marked build as failure
Description set: Java: 64bit/jdk1.8.0-ea-b109 -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] (SOLR-5379) Query-time multi-word synonym expansion

[Bill Steele (JIRA)]

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

Bill Steele commented on SOLR-5379:
---

We found this to be much more useful code for multiword synonyms.  We ran some 
tests, and when having a synonym set such as:

seabiscuit, sea biscuit, sea biscit

Search on the following:

seabiscuit article

Returned matches with the following terms

Sea biscit article
Sea biscuit article
Seabiscuit article
Biscuit Sea article
Sea article
Biscit article

With this patch, the above search query just returned the terms:

Sea biscit article
Sea biscuit article
Seabiscuit article



> 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

RE: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0-ea-b109) - Build # 8189 - Still Failing!

[Uwe Schindler]

Hi,

it looks like Dawid's commit placed these .tests.totals files in the wrong 
directory. Should be inside build! Maybe some property is incorrectly 
initialized.

In addition I will add  another comment to the corresponding issue, because of 
some dependency of the commit to javascript, that’s not fully guaranteed to be 
available in every JVM (e.g., on FreeBSD we don't have it).

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 10:23 PM
> To: dev@lucene.apache.org; er...@apache.org; dwe...@apache.org
> Subject: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0-ea-b109) - Build #
> 8189 - Still Failing!
> 
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/8189/
> Java: 64bit/jdk1.8.0-ea-b109 -XX:+UseCompressedOops -XX:+UseSerialGC
> 
> All tests passed
> 
> Build Log:
> [...truncated 36008 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:360: The
> following error occurred while executing this line:
> /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/extra-targets.xml:66:
> The following error occurred while executing this line:
> /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/extra-
> targets.xml:137: Source checkout is dirty after running tests!!! Offending
> files:
> * ./lucene/.test-totals-922324336062316929.tmp
> * ./solr/.test-totals-5710645736889619892.tmp
> 
> Total time: 50 minutes 15 seconds
> Build step 'Invoke Ant' marked build as failure Description set: Java:
> 64bit/jdk1.8.0-ea-b109 -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] [Created] (LUCENE-5330) IndexWriter doesn't process all events on getReader / close / rollback

[Simon Willnauer (JIRA)]

Simon Willnauer created LUCENE-5330:
---

 Summary: 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
 Fix For: 4.6, 5.0


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] (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 updated LUCENE-5330:


Attachment: LUCENE-5330.patch

here is a patch that adds asserts and beefs up a test that fails without 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
> 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-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=13814330#comment-13814330
 ] 

Uwe Schindler commented on LUCENE-5283:
---

Hi Dawid,

I was out of offfice, so had no time to review your patch. The current commit 
seems to leave the checkout unclean after running tests; my response to the 
failure mail:

{quote}
it looks like Dawid's commit placed these .tests.totals files in the wrong 
directory. Should be inside build! Maybe some property is incorrectly 
initialized.

In addition I will add  another comment to the corresponding issue, because of 
some dependency of the commit to javascript, that’s not fully guaranteed to be 
available in every JVM (e.g., on FreeBSD we don't have it).
{quote}

The second thing is a problem on some platforms. We discussed about that 
already in the past (you know I was fighting pro Javascript), but other 
convinced me: Javascript is not guaranteed to be a available on every JDK (the 
JDK only defines the abstract script interface and mandates that some example 
script engine is avilable, but not which one). So I changed all scripts in out 
ANT build to use groovy. For Groovy, ideally use the  ant task 
(installed by common-build when you depend on the corresponding install-groovy 
task. You can also use it with  or  but this leads 
to permgen problems when called in every module. The reason for this is: 
 creates a new classloader every time and loads a new groovy, while 
installing the  ant task can be reused in sub-modules (so we only need 
to install top-level).

So I would rewrite the  to a simple  executed before 
the condition task, which sets a property thats used by the condition. Or 
alternatively directly throw a BuildException in the groovy without using a 
scriptcondition at all.

I can provide a patch tomorrow.

> 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

[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=13814343#comment-13814343
 ] 

Dawid Weiss commented on LUCENE-5283:
-

Eh... Yeah, thanks Uwe.

Regarding the temporary file -- this should have been removed at the end of the 
build, don't know why it wasn't. I initially placed it under build/ but this 
wasn't initialized for Solr (if I recall correctly). 

I also didn't want to make this any heavier than needed (by loading Groovy, 
etc) because this gets executed pretty often. I will revert for now and try to 
work on this in the background.



> 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: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0-ea-b109) - Build # 8189 - Still Failing!

[Dawid Weiss]

Thanks Uwe, will revert it and refine the patch. I am still not happy
with how this is implemented but I honestly don't think there is a
cleaner way to run such a "wrapper" target at the top-level of Ant
invocation (including sub-module level).

Dawid

On Tue, Nov 5, 2013 at 11:18 PM, Uwe Schindler  wrote:
> Hi,
>
> it looks like Dawid's commit placed these .tests.totals files in the wrong 
> directory. Should be inside build! Maybe some property is incorrectly 
> initialized.
>
> In addition I will add  another comment to the corresponding issue, because 
> of some dependency of the commit to javascript, that’s not fully guaranteed 
> to be available in every JVM (e.g., on FreeBSD we don't have it).
>
> 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 10:23 PM
>> To: dev@lucene.apache.org; er...@apache.org; dwe...@apache.org
>> Subject: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0-ea-b109) - Build #
>> 8189 - Still Failing!
>>
>> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/8189/
>> Java: 64bit/jdk1.8.0-ea-b109 -XX:+UseCompressedOops -XX:+UseSerialGC
>>
>> All tests passed
>>
>> Build Log:
>> [...truncated 36008 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:360: The
>> following error occurred while executing this line:
>> /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/extra-targets.xml:66:
>> The following error occurred while executing this line:
>> /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/extra-
>> targets.xml:137: Source checkout is dirty after running tests!!! Offending
>> files:
>> * ./lucene/.test-totals-922324336062316929.tmp
>> * ./solr/.test-totals-5710645736889619892.tmp
>>
>> Total time: 50 minutes 15 seconds
>> Build step 'Invoke Ant' marked build as failure Description set: Java:
>> 64bit/jdk1.8.0-ea-b109 -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
>

-
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

[Shawn Heisey]

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

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

[Policeman Jenkins Server]

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/Lucene-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-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/analysis/kuromoji/lucene-analyzers-kuromoji-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/analysis/phonetic/lucene-analyzers-phonetic-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/codecs/lucene-codecs-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/highlighter/lucene-highlighter-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/memory/lucene-memory-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/misc/lucene-misc-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/spatial/lucene-spatial-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/suggest/lucene-suggest-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/grouping/lucene-grouping-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/que

[jira] [Comment Edited] (SOLR-5419) Solr Admin UI Query Result Does Nothing at Error

[Furkan KAMACI (JIRA)]

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

Furkan KAMACI edited comment on SOLR-5419 at 11/5/13 10:59 PM:
---

I've resolved the issue and fixed logic at Ajax request.


was (Author: kamaci):
I've resolved issue and fixed logic at Ajax request.

> Solr Admin UI Query Result Does Nothing at Error
> 
>
> Key: SOLR-5419
> URL: https://issues.apache.org/jira/browse/SOLR-5419
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 4.5.1
>Reporter: Furkan KAMACI
>Priority: Minor
> Fix For: 4.6
>
> Attachments: SOLR-5419.patch
>
>
> When you make a query into Solr via Solr Admin Page and if error occurs there 
> writes "Loading.." and does nothing. 
> i.e. if you write an invalid Request Handler at Query page even response is 
> 404 Not Found "Loading..." is still there.



--
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-5419) Solr Admin UI Query Result Does Nothing at Error

[Furkan KAMACI (JIRA)]

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

Furkan KAMACI updated SOLR-5419:


Summary: Solr Admin UI Query Result Does Nothing at Error  (was: Solr Admın 
UI Query Result Does Nothing at Error)

> Solr Admin UI Query Result Does Nothing at Error
> 
>
> Key: SOLR-5419
> URL: https://issues.apache.org/jira/browse/SOLR-5419
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 4.5.1
>Reporter: Furkan KAMACI
>Priority: Minor
> Fix For: 4.6
>
> Attachments: SOLR-5419.patch
>
>
> When you make a query into Solr via Solr Admin Page and if error occurs there 
> writes "Loading.." and does nothing. 
> i.e. if you write an invalid Request Handler at Query page even response is 
> 404 Not Found "Loading..." is still there.



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

[Dawid Weiss]

This is the same JVM bug as in SOLR-4593 (updated JVM but the problem persists).

Dawid

On Tue, Nov 5, 2013 at 11:56 PM, Policeman Jenkins Server
 wrote:
> 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/Lucene-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-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/analysis/kuromoji/lucene-analyzers-kuromoji-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/analysis/phonetic/lucene-analyzers-phonetic-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/codecs/lucene-codecs-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/highlighter/lucene-highlighter-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/memory/lucene-memory-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/misc/lucene-misc-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/spatial/lucene-spatial-5.0-SNAPSHOT.jar:

RE: [JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.7.0) - Build # 987 - Still Failing!

[Uwe Schindler]

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

RE: Testing Java Updates with your projects.

[Uwe Schindler]

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/jdk8/jdk8/hotspot/rev/36b97be47bde 
Issue: https://bugs.openjdk.java.net/browse/JDK-8011311 

What happens: 
When running Apache Lucene's UIMA tests (UIMA is foreign code, not part 

of Lucene): 




cd lucene/analysis/uima 
ant test 

*All* tests fail here: 

java.lang.IllegalAccessError: tried to access method 

java.lang.Object.clone()Ljava/lang/Object; from class 
org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase 




at 

__randomizedtesting.SeedInfo.seed([BC36C2DC5FC6C107:4A94D14D35381F8 
8]:0) 




at 

org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.initialize(Anal 
ysisEngineImplBase.java:163) 




at 

or

[jira] [Commented] (SOLR-5027) Field Collapsing PostFilter

[Greg Harris (JIRA)]

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

Greg Harris commented on SOLR-5027:
---

I have a request from a customer on this who would really benefit from this 
filter -- Ability to sort by two fields. I have looked into the code and 
understand this may not be easily feasible. Just getting it out there. 

> Field Collapsing PostFilter
> ---
>
> Key: SOLR-5027
> URL: https://issues.apache.org/jira/browse/SOLR-5027
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Affects Versions: 5.0
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Minor
> Fix For: 4.6, 5.0
>
> Attachments: SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch, 
> SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch, 
> SOLR-5027.patch, SOLR-5027.patch
>
>
> This ticket introduces the *CollapsingQParserPlugin* 
> The *CollapsingQParserPlugin* is a PostFilter that performs field collapsing. 
> This is a high performance alternative to standard Solr field collapsing 
> (with *ngroups*) when the number of distinct groups in the result set is high.
> For example in one performance test, a search with 10 million full results 
> and 1 million collapsed groups:
> Standard grouping with ngroups : 17 seconds.
> CollapsingQParserPlugin: 300 milli-seconds.
> Sample syntax:
> Collapse based on the highest scoring document:
> {code}
> fq=(!collapse field=}
> {code}
> Collapse based on the min value of a numeric field:
> {code}
> fq={!collapse field= min=}
> {code}
> Collapse based on the max value of a numeric field:
> {code}
> fq={!collapse field= max=}
> {code}
> Collapse with a null policy:
> {code}
> fq={!collapse field= nullPolicy=}
> {code}
> There are three null policies:
> ignore : removes docs with a null value in the collapse field (default).
> expand : treats each doc with a null value in the collapse field as a 
> separate group.
> collapse : collapses all docs with a null value into a single group using 
> either highest score, or min/max.
> The CollapsingQParserPlugin also fully supports the QueryElevationComponent
> *Note:*  The July 16 patch also includes and ExpandComponent that expands the 
> collapsed groups for the current search result page. This functionality will 
> be moved to it's own ticket.



--
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-5425) PostFilters are executed twice when used with grouping

[Greg Harris (JIRA)]

Greg Harris created SOLR-5425:
-

 Summary: PostFilters are executed twice when used with grouping
 Key: SOLR-5425
 URL: https://issues.apache.org/jira/browse/SOLR-5425
 Project: Solr
  Issue Type: Improvement
Reporter: Greg Harris
Priority: Minor


PostFilters are executed twice when used with grouping:

Have experimented with removal at one stage but always comes in with wrong 
answers and it seems for now this is necessary. Makes an expensive PostFilter 
doubly so, which can be a problem.




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

Use grouping on MLT results from MLT handler

[vineeth mohan]

Hi ,

I need to find similar documents to a document and also group the result
based on a field say category.

I could find the MLT handler and I could find the grouping feature.

   - MLT handler - http://wiki.apache.org/solr/MoreLikeThisHandler
   - Grouping - http://wiki.apache.org/solr/FieldCollapsing

But I couldn't find a way to apply the grouping on the response given by
MLT handler. Is there any way I can achieve this ?

Just adding grouping variables to the MLT handler didn't help

http://$HOST:8983/solr/collection1/mlt?q=id:SP2514N&wt=json&indent=true&mlt.fl=name&mlt.mintf=1&mlt.mindf=0&group=true&group.field=manu_id_s


Let me know , what can be done about it.

Thanks
  Vineeth

[jira] [Assigned] (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 reassigned LUCENE-5330:
---

Assignee: Simon Willnauer

> 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-5084) new field type - EnumField

[Elran Dvir (JIRA)]

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

Elran Dvir commented on SOLR-5084:
--

Thank you, Erick!

> new field type - EnumField
> --
>
> Key: SOLR-5084
> URL: https://issues.apache.org/jira/browse/SOLR-5084
> Project: Solr
>  Issue Type: New Feature
>Reporter: Elran Dvir
>Assignee: Erick Erickson
> Fix For: 4.6, 5.0
>
> Attachments: Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, 
> Solr-5084.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
> Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
> Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, 
> Solr-5084.trunk.patch, enumsConfig.xml, schema_example.xml
>
>
> We have encountered a use case in our system where we have a few fields 
> (Severity. Risk etc) with a closed set of values, where the sort order for 
> these values is pre-determined but not lexicographic (Critical is higher than 
> High). Generically this is very close to how enums work.
> To implement, I have prototyped a new type of field: EnumField where the 
> inputs are a closed predefined  set of strings in a special configuration 
> file (similar to currency.xml).
> The code is based on 4.2.1.



--
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-5320) Multi level compositeId router

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-5320:
---

Remaining Estimate: 24h  (was: 336h)
 Original Estimate: 24h  (was: 336h)

> Multi level compositeId router
> --
>
> Key: SOLR-5320
> URL: https://issues.apache.org/jira/browse/SOLR-5320
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Reporter: Anshum Gupta
> Attachments: SOLR-5320-refactored.patch, SOLR-5320.patch, 
> SOLR-5320.patch, SOLR-5320.patch, SOLR-5320.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> This would enable multi level routing as compared to the 2 level routing 
> available as of now. On the usage bit, here's an example:
> Document Id: myapp!dummyuser!doc
> myapp!dummyuser! can be used as the shardkey for searching content for 
> dummyuser.
> myapp! can be used for searching across all users of myapp.
> I am looking at either a 3 (or 4) level routing. The 32 bit hash would then 
> comprise of 8X4 components from each part (in case of 4 level).
> Usage:
> Document Id: myapp!dummyuser!doc
> To query all users for a particular app (default setup), the route key should 
> be: 'myapp/8!'.
> To query a particular user for a specific app, the route key should be: 
> 'myapp!dummyuser!'
> The syntax for querying all users for a particular app is required because 
> this router works at both 2 and 3 level of composite id.
> A route key of 'myapp!' would technically translate to constructing the hash 
> range with 16 bits coming from the key i.e. 2-level composite id.



--
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-trunk-Linux-Java7-64-test-only - Build # 65778 - Failure!

[builder]

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

No tests ran.

Build Log:
[...truncated 13 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.tmates

[JENKINS] Lucene-4.5.1-Linux-Java7-64-test-only - Build # 2091 - Failure!

[builder]

Build: builds.flonkings.com/job/Lucene-4.5.1-Linux-Java7-64-test-only/2091/

No tests ran.

Build Log:
[...truncated 12 lines...]
ERROR: Failed to update 
http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_5
org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS 
/repos/asf/lucene/dev/branches/lucene_solr_4_5 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/lucene_solr_4_5 
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/lucene_solr_4_5'
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/lucene_solr_4_5'
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
a

[JENKINS] Lucene-4.5.1-Linux-Java7-64-test-only - Build # 2092 - Still Failing!

[builder]

Build: builds.flonkings.com/job/Lucene-4.5.1-Linux-Java7-64-test-only/2092/

No tests ran.

Build Log:
[...truncated 5 lines...]
ERROR: Failed to update 
http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_5
org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS 
/repos/asf/lucene/dev/branches/lucene_solr_4_5 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/lucene_solr_4_5 
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/lucene_solr_4_5'
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/lucene_solr_4_5'
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

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

[builder]

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

No tests ran.

Build Log:
[...truncated 5 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