[jira] [Commented] (LUCENE-5215) Add support for FieldInfos generation

[Shai Erera (JIRA)]

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

Shai Erera commented on LUCENE-5215:


Committed to trunk. I'll move on to LUCENE-5216

> Add support for FieldInfos generation
> -
>
> Key: LUCENE-5215
> URL: https://issues.apache.org/jira/browse/LUCENE-5215
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: core/index
>Reporter: Shai Erera
>Assignee: Shai Erera
> Attachments: LUCENE-5215.patch, LUCENE-5215.patch, LUCENE-5215.patch, 
> LUCENE-5215.patch, LUCENE-5215.patch, LUCENE-5215.patch, LUCENE-5215.patch
>
>
> In LUCENE-5189 we've identified few reasons to do that:
> # If you want to update docs' values of field 'foo', where 'foo' exists in 
> the index, but not in a specific segment (sparse DV), we cannot allow that 
> and have to throw a late UOE. If we could rewrite FieldInfos (with 
> generation), this would be possible since we'd also write a new generation of 
> FIS.
> # When we apply NDV updates, we call DVF.fieldsConsumer. Currently the 
> consumer isn't allowed to change FI.attributes because we cannot modify the 
> existing FIS. This is implicit however, and we silently ignore any modified 
> attributes. FieldInfos.gen will allow that too.
> The idea is to add to SIPC fieldInfosGen, add to each FieldInfo a dvGen and 
> add support for FIS generation in FieldInfosFormat, SegReader etc., like we 
> now do for DocValues. I'll work on a patch.
> Also on LUCENE-5189, Rob raised a concern about SegmentInfo.attributes that 
> have same limitation -- if a Codec modifies them, they are silently being 
> ignored, since we don't gen the .si files. I think we can easily solve that 
> by recording SI.attributes in SegmentInfos, so they are recorded per-commit. 
> But I think it should be handled in a separate issue.

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

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

[jira] [Commented] (LUCENE-5215) Add support for FieldInfos generation

[ASF subversion and git services (JIRA)]

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

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

Commit 1527154 from [~shaie] in branch 'dev/trunk'
[ https://svn.apache.org/r1527154 ]

LUCENE-5215: Add support for FieldInfos generation

> Add support for FieldInfos generation
> -
>
> Key: LUCENE-5215
> URL: https://issues.apache.org/jira/browse/LUCENE-5215
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: core/index
>Reporter: Shai Erera
>Assignee: Shai Erera
> Attachments: LUCENE-5215.patch, LUCENE-5215.patch, LUCENE-5215.patch, 
> LUCENE-5215.patch, LUCENE-5215.patch, LUCENE-5215.patch, LUCENE-5215.patch
>
>
> In LUCENE-5189 we've identified few reasons to do that:
> # If you want to update docs' values of field 'foo', where 'foo' exists in 
> the index, but not in a specific segment (sparse DV), we cannot allow that 
> and have to throw a late UOE. If we could rewrite FieldInfos (with 
> generation), this would be possible since we'd also write a new generation of 
> FIS.
> # When we apply NDV updates, we call DVF.fieldsConsumer. Currently the 
> consumer isn't allowed to change FI.attributes because we cannot modify the 
> existing FIS. This is implicit however, and we silently ignore any modified 
> attributes. FieldInfos.gen will allow that too.
> The idea is to add to SIPC fieldInfosGen, add to each FieldInfo a dvGen and 
> add support for FIS generation in FieldInfosFormat, SegReader etc., like we 
> now do for DocValues. I'll work on a patch.
> Also on LUCENE-5189, Rob raised a concern about SegmentInfo.attributes that 
> have same limitation -- if a Codec modifies them, they are silently being 
> ignored, since we don't gen the .si files. I think we can easily solve that 
> by recording SI.attributes in SegmentInfos, so they are recorded per-commit. 
> But I think it should be handled in a separate issue.

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

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

[JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.7.0_40) - Build # 7568 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/7568/
Java: 32bit/jdk1.7.0_40 -client -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 1632 lines...]
   [junit4] ERROR: JVM J0 ended with an exception, command line: 
/var/lib/jenkins/tools/java/32bit/jdk1.7.0_40/jre/bin/java -client 
-XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/heapdumps 
-Dtests.prefix=tests -Dtests.seed=94F1B34532F99A72 -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=4.6 
-Dtests.cleanthreads=perMethod 
-Djava.util.logging.config.file=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/junit4/logging.properties
 -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true 
-Dtests.asserts.gracious=false -Dtests.multiplier=3 -DtempDir=. 
-Djava.io.tmpdir=. 
-Djunit4.tempDir=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/core/test/temp
 
-Dclover.db.dir=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/clover/db
 -Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
-Djava.security.policy=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/junit4/tests.policy
 -Dlucene.version=4.6-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 
-Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory 
-Djava.awt.headless=true -Dtests.disableHdfs=true -classpath 
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/test-framework/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/codecs/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/test-framework/lib/junit-4.10.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/test-framework/lib/randomizedtesting-runner-2.0.10.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/core/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/core/classes/test:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-launcher.jar:/var/lib/jenkins/.ant/lib/ivy-2.3.0.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jai.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-swing.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-oro.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jmf.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-xalan2.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-javamail.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-resolver.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-testutil.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-commons-logging.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-log4j.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-junit.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jsch.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-commons-net.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-bsf.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jdepend.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-netrexx.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-regexp.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-junit4.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-bcel.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-antlr.jar:/var/lib/jenkins/tools/java/32bit/jdk1.7.0_40/lib/tools.jar:/var/lib/jenkins/.ivy2/cache/com.carrotsearch.randomizedtesting/junit4-ant/jars/junit4-ant-2.0.10.jar
 -ea:org.apache.lucene... -ea:org.apache.solr... 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe -eventsfile 
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/core/test/temp/junit4-J0-20130928_044816_071.events
 
@/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/core/test/temp/junit4-J0-20130928_044816_071.suites
   [junit4] ERROR: JVM J0 ended with an exception: Forked process returned with 
error code: 134. Very likely a JVM crash.  Process output piped in logs above.
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.JUnit4.executeSlave(JUnit4.java:1254)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.JUnit4.access$000(JUnit4.jav

[jira] [Commented] (SOLR-2397) main example solrconfig.xml needs cleanup before 3.1

[ASF subversion and git services (JIRA)]

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

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

Commit 1527150 from [~dsmiley] in branch 'dev/trunk'
[ https://svn.apache.org/r1527150 ]

SOLR-5005: remove accidental inclusion of JavaScriptRequestHandler in r1075960 
(SOLR-2397)

> main example solrconfig.xml needs cleanup before 3.1
> 
>
> Key: SOLR-2397
> URL: https://issues.apache.org/jira/browse/SOLR-2397
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 3.1, 4.0-ALPHA
>
> Attachments: SOLR-2397.patch, SOLR-2397.patch, solrconfig.xml, 
> solrconfig.xml
>
>
> the main solconfig.xml example file has gotten cluttered, doesn't use 
> consistent indenting, lists various things in a haphazard order, and contains 
> relics of outdated/deprecated plugins/terminology.  this really needs to be 
> dealt with prior to 3.1 since most people reuse this example as the basis for 
> their own configs.
> rather then trying to opening individual issues for little one off changes 
> (which is how a lot of the haphazard came about) i'm going to take a stab at 
> one big cleanup here and seek feedback on the end result

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

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

[jira] [Commented] (SOLR-5005) JavaScriptRequestHandler

[ASF subversion and git services (JIRA)]

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

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

Commit 1527150 from [~dsmiley] in branch 'dev/trunk'
[ https://svn.apache.org/r1527150 ]

SOLR-5005: remove accidental inclusion of JavaScriptRequestHandler in r1075960 
(SOLR-2397)

> JavaScriptRequestHandler
> 
>
> Key: SOLR-5005
> URL: https://issues.apache.org/jira/browse/SOLR-5005
> Project: Solr
>  Issue Type: New Feature
>Reporter: David Smiley
>Assignee: Noble Paul
> Attachments: patch, SOLR-5005.patch, SOLR-5005.patch, SOLR-5005.patch
>
>
> A user customizable script based request handler would be very useful.  It's 
> inspired from the ScriptUpdateRequestProcessor, but on the search end. A user 
> could write a script that submits searches to Solr (in-VM) and can react to 
> the results of one search before making another that is formulated 
> dynamically.  And it can assemble the response data, potentially reducing 
> both the latency and data that would move over the wire if this feature 
> didn't exist.  It could also be used to easily add a user-specifiable search 
> API at the Solr server with request parameters governed by what the user 
> wants to advertise -- especially useful within enterprises.  And, it could be 
> used to enforce security requirements on allowable parameter valuables to 
> Solr, so a javascript based Solr client could be allowed to talk to only a 
> script based request handler which enforces the rules.

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

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

[jira] [Created] (SOLR-5285) Solr response format should support child Docs

[Varun Thacker (JIRA)]

Varun Thacker created SOLR-5285:
---

 Summary: Solr response format should support child Docs
 Key: SOLR-5285
 URL: https://issues.apache.org/jira/browse/SOLR-5285
 Project: Solr
  Issue Type: New Feature
Reporter: Varun Thacker
 Fix For: 5.0, 4.6


Solr has added support for taking childDocs as input ( only XML till now ). 
It's currently used for BlockJoinQuery. 

I feel that if a user indexes a document with child docs, even if he isn't 
using the BJQ features and is just searching which results in a hit on the 
parentDoc, it's childDocs should be returned in the response format.

[~hossman_luc...@fucit.org] on IRC suggested that the DocTransformers would be 
the place to add childDocs to the response.

Now given a docId one needs to find out all the childDoc id's. A couple of 
approaches which I could think of are 
1. Maintain the relation between a parentDoc and it's childDocs during indexing 
time in maybe a separate index?
2. Somehow emulate what happens in ToParentBlockJoinQuery.nextDoc() - Given a 
parentDoc it finds out all the childDocs but this requires a childScorer.

Am I missing something obvious on how to find the relation between a parentDoc 
and it's childDocs because none of the above solutions for this look right.

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

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

Re: [VOTE] Release Lucene/Solr 4.5.0 RC4

[Steve Rowe]

I noticed when merging CHANGES.txt entries to the 4_5 branch that on Sept. 17th 
Mark Miller committed a 4.5 CHANGES.txt modification to add credit for somebody 
 (that's the branch_4x commit), but didn't also 
commit to the then-five-day-old 4_5 branch.  So I merged Mark's branch_4x 
commit to the 4_5 branch.

Steve

On Sep 27, 2013, at 5:26 PM, Steve Rowe  wrote:

> Thanks Adrien.
> 
> I've finished backporting SOLR-5279, and also backported SOLR-5281.
> 
> Steve
> 
> On Sep 27, 2013, at 4:30 PM, Adrien Grand  wrote:
> 
>> Hi Steve,
>> 
>> On Fri, Sep 27, 2013 at 9:30 PM, Steve Rowe  wrote:
>>> I attached a fix to the issue Shawn created for the missing implicit 
>>> Solr-core-properties-on-RELOAD issue: SOLR-5279
>>> 
>>> IMHO, this regression should be fixed in 4.5.
>>> 
>>> Adrien, I tried to raise you on IRC but didn't get a response - is it okay 
>>> with you to do a respin?  I'll commit to trunk and branch_4x with the 
>>> CHANGES.txt entry under 4.6 until you say it's okay.
>> 
>> Indeed, I was not keeping an eye on IRC. I will respin tomorrow
>> morning european time. Thanks for fixing this issue!
>> 
>> -- 
>> Adrien
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
> 


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

Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_40) - Build # 7639 - Failure!

[Shai Erera]

Committed a fix - disabled merges in order to keep the test focused and
simple.

Shai


On Sat, Sep 28, 2013 at 6:09 AM, Shai Erera  wrote:

> It appears to be a test bug -- the test indexes two documents, while
> changing Codec and commit in between (so two segments are created). It then
> assumes that the order of the documents in the reader remains the same (d0,
> d1), but it's actually d1,d0, hence the failure.
>
> I see that MockRandomMergePolicy is picked, and that it shuffles the
> segments. I'll fix the test to be less sensitive to that.
>
> Shai
>
>
> On Fri, Sep 27, 2013 at 11:11 PM, Michael McCandless <
> luc...@mikemccandless.com> wrote:
>
>> This one reproduces; is anyone looking?
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>>
>> On Thu, Sep 26, 2013 at 4:27 PM, Policeman Jenkins Server
>>  wrote:
>> > Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/7639/
>> > Java: 32bit/jdk1.7.0_40 -client -XX:+UseSerialGC
>> >
>> > 1 tests failed.
>> > REGRESSION:
>>  org.apache.lucene.index.TestNumericDocValuesUpdates.testChangeCodec
>> >
>> > Error Message:
>> > expected:<12> but was:<17>
>> >
>> > Stack Trace:
>> > java.lang.AssertionError: expected:<12> but was:<17>
>> > at
>> __randomizedtesting.SeedInfo.seed([A099DBB8181A4538:C1FFAD77A92F9D1E]:0)
>> > at org.junit.Assert.fail(Assert.java:93)
>> > at org.junit.Assert.failNotEquals(Assert.java:647)
>> > at org.junit.Assert.assertEquals(Assert.java:128)
>> > at org.junit.Assert.assertEquals(Assert.java:472)
>> > at org.junit.Assert.assertEquals(Assert.java:456)
>> > at
>> org.apache.lucene.index.TestNumericDocValuesUpdates.testChangeCodec(TestNumericDocValuesUpdates.java:1074)
>> > 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(NoShadowingOrOverridesOnMethod

[jira] [Commented] (LUCENE-5189) Numeric DocValues Updates

[ASF subversion and git services (JIRA)]

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

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

Commit 1527147 from [~shaie] in branch 'dev/trunk'
[ https://svn.apache.org/r1527147 ]

LUCENE-5189: disable merges in testChangeCodec

> Numeric DocValues Updates
> -
>
> Key: LUCENE-5189
> URL: https://issues.apache.org/jira/browse/LUCENE-5189
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: core/index
>Reporter: Shai Erera
>Assignee: Shai Erera
> Attachments: LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, 
> LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, 
> LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch
>
>
> In LUCENE-4258 we started to work on incremental field updates, however the 
> amount of changes are immense and hard to follow/consume. The reason is that 
> we targeted postings, stored fields, DV etc., all from the get go.
> I'd like to start afresh here, with numeric-dv-field updates only. There are 
> a couple of reasons to that:
> * NumericDV fields should be easier to update, if e.g. we write all the 
> values of all the documents in a segment for the updated field (similar to 
> how livedocs work, and previously norms).
> * It's a fairly contained issue, attempting to handle just one data type to 
> update, yet requires many changes to core code which will also be useful for 
> updating other data types.
> * It has value in and on itself, and we don't need to allow updating all the 
> data types in Lucene at once ... we can do that gradually.
> I have some working patch already which I'll upload next, explaining the 
> changes.

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

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

Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_40) - Build # 7639 - Failure!

[Shai Erera]

It appears to be a test bug -- the test indexes two documents, while
changing Codec and commit in between (so two segments are created). It then
assumes that the order of the documents in the reader remains the same (d0,
d1), but it's actually d1,d0, hence the failure.

I see that MockRandomMergePolicy is picked, and that it shuffles the
segments. I'll fix the test to be less sensitive to that.

Shai


On Fri, Sep 27, 2013 at 11:11 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:

> This one reproduces; is anyone looking?
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Thu, Sep 26, 2013 at 4:27 PM, Policeman Jenkins Server
>  wrote:
> > Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/7639/
> > Java: 32bit/jdk1.7.0_40 -client -XX:+UseSerialGC
> >
> > 1 tests failed.
> > REGRESSION:
>  org.apache.lucene.index.TestNumericDocValuesUpdates.testChangeCodec
> >
> > Error Message:
> > expected:<12> but was:<17>
> >
> > Stack Trace:
> > java.lang.AssertionError: expected:<12> but was:<17>
> > at
> __randomizedtesting.SeedInfo.seed([A099DBB8181A4538:C1FFAD77A92F9D1E]:0)
> > at org.junit.Assert.fail(Assert.java:93)
> > at org.junit.Assert.failNotEquals(Assert.java:647)
> > at org.junit.Assert.assertEquals(Assert.java:128)
> > at org.junit.Assert.assertEquals(Assert.java:472)
> > at org.junit.Assert.assertEquals(Assert.java:456)
> > at
> org.apache.lucene.index.TestNumericDocValuesUpdates.testChangeCodec(TestNumericDocValuesUpdates.java:1074)
> > 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)
> >

[jira] [Commented] (SOLR-4816) Add document routing to CloudSolrServer

[ASF subversion and git services (JIRA)]

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

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

Commit 1527131 from [~steve_rowe] in branch 'dev/branches/lucene_solr_4_5'
[ https://svn.apache.org/r1527131 ]

SOLR-4816: add missing CHANGES credit (merged branch_4x r1524177)

> Add document routing to CloudSolrServer
> ---
>
> Key: SOLR-4816
> URL: https://issues.apache.org/jira/browse/SOLR-4816
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 4.3
>Reporter: Joel Bernstein
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 4.5, 5.0
>
> Attachments: RequestTask-removal.patch, SOLR-4816.patch, 
> SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, 
> SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, 
> SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, 
> SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, 
> SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, 
> SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, 
> SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816-sriesenberg.patch
>
>
> This issue adds the following enhancements to CloudSolrServer's update logic:
> 1) Document routing: Updates are routed directly to the correct shard leader 
> eliminating document routing at the server.
> 2) Optional parallel update execution: Updates for each shard are executed in 
> a separate thread so parallel indexing can occur across the cluster.
> These enhancements should allow for near linear scalability on indexing 
> throughput.
> Usage:
> CloudSolrServer cloudClient = new CloudSolrServer(zkAddress);
> cloudClient.setParallelUpdates(true); 
> SolrInputDocument doc1 = new SolrInputDocument();
> doc1.addField(id, "0");
> doc1.addField("a_t", "hello1");
> SolrInputDocument doc2 = new SolrInputDocument();
> doc2.addField(id, "2");
> doc2.addField("a_t", "hello2");
> UpdateRequest request = new UpdateRequest();
> request.add(doc1);
> request.add(doc2);
> request.setAction(AbstractUpdateRequest.ACTION.OPTIMIZE, false, false);
> NamedList response = cloudClient.request(request); // Returns a backwards 
> compatible condensed response.
> //To get more detailed response down cast to RouteResponse:
> CloudSolrServer.RouteResponse rr = (CloudSolrServer.RouteResponse)response;

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

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

Re: [VOTE] Release Lucene/Solr 4.5.0 RC4

[Steve Rowe]

Thanks Adrien.

I've finished backporting SOLR-5279, and also backported SOLR-5281.

Steve

On Sep 27, 2013, at 4:30 PM, Adrien Grand  wrote:

> Hi Steve,
> 
> On Fri, Sep 27, 2013 at 9:30 PM, Steve Rowe  wrote:
>> I attached a fix to the issue Shawn created for the missing implicit 
>> Solr-core-properties-on-RELOAD issue: SOLR-5279
>> 
>> IMHO, this regression should be fixed in 4.5.
>> 
>> Adrien, I tried to raise you on IRC but didn't get a response - is it okay 
>> with you to do a respin?  I'll commit to trunk and branch_4x with the 
>> CHANGES.txt entry under 4.6 until you say it's okay.
> 
> Indeed, I was not keeping an eye on IRC. I will respin tomorrow
> morning european time. Thanks for fixing this issue!
> 
> -- 
> Adrien
> 
> -
> 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

[jira] [Updated] (SOLR-5281) Incorrect access core.properties in IndexSchema.java

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-5281:
-

Fix Version/s: 4.5

> Incorrect access core.properties in IndexSchema.java
> 
>
> Key: SOLR-5281
> URL: https://issues.apache.org/jira/browse/SOLR-5281
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.5
>Reporter: Jun Ohtani
>Assignee: Steve Rowe
>Priority: Minor
> Fix For: 4.5, 5.0, 4.6
>
> Attachments: SOLR-5281.patch
>
>
> IndexSchema use core name for logging.
> But core name always output "[null] Schema..", the following.
> ---
>  "3814 [coreLoadExecutor-3-thread-1] INFO  org.apache.solr.schema.IndexSchema 
>  – Reading Solr Schema from schema.xml
> 3926 [coreLoadExecutor-3-thread-1] INFO  org.apache.solr.schema.IndexSchema  
> – [null] Schema name=example
> ---
> Maybe, property name pattern changed "name" to "solr.core.name" at SOLR-5162.
> --- IndexSchema.java
> ...
>   public static final String NAME = "name";
> ...
>   if (loader.getCoreProperties() != null) {
> sb.append(loader.getCoreProperties().getProperty(NAME));
>   } else {
> sb.append("null");
>   }

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

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

[jira] [Resolved] (SOLR-5279) Implicit properties don't seem to exist on core RELOAD

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-5279.
--

Resolution: Fixed

Committed to trunk, branch_4x and lucene_solr_4_5 branch.

Thanks Shawn!

> Implicit properties don't seem to exist on core RELOAD
> --
>
> Key: SOLR-5279
> URL: https://issues.apache.org/jira/browse/SOLR-5279
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.5
> Environment: Solr 4.5.0 RC4
> Linux bigindy5 2.6.32-358.6.1.el6.centos.plus.x86_64 #1 SMP Wed Apr 24 
> 03:21:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.7.0_21"
> Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)
>Reporter: Shawn Heisey
> Fix For: 4.5, 5.0, 4.6
>
> Attachments: SOLR-5279.patch, SOLR-5279-test.patch
>
>
> The implicit properties (specifically solr.core.name) work fine for Solr 
> startup, but on core RELOAD, they no longer exist, so configurations that use 
> them result in the core not initializing.
> Problem discovered on 4.5.0 RC4, works fine in 4.4.0.

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

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

[jira] [Commented] (SOLR-5279) Implicit properties don't seem to exist on core RELOAD

[ASF subversion and git services (JIRA)]

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

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

Commit 1527085 from [~steve_rowe] in branch 'dev/branches/lucene_solr_4_5'
[ https://svn.apache.org/r1527085 ]

SOLR-5279: Implicit properties don't seem to exist on core RELOAD (merged trunk 
r1527042 and r1527076)

> Implicit properties don't seem to exist on core RELOAD
> --
>
> Key: SOLR-5279
> URL: https://issues.apache.org/jira/browse/SOLR-5279
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.5
> Environment: Solr 4.5.0 RC4
> Linux bigindy5 2.6.32-358.6.1.el6.centos.plus.x86_64 #1 SMP Wed Apr 24 
> 03:21:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.7.0_21"
> Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)
>Reporter: Shawn Heisey
> Fix For: 4.5, 5.0, 4.6
>
> Attachments: SOLR-5279.patch, SOLR-5279-test.patch
>
>
> The implicit properties (specifically solr.core.name) work fine for Solr 
> startup, but on core RELOAD, they no longer exist, so configurations that use 
> them result in the core not initializing.
> Problem discovered on 4.5.0 RC4, works fine in 4.4.0.

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

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

[jira] [Commented] (SOLR-5281) Incorrect access core.properties in IndexSchema.java

[ASF subversion and git services (JIRA)]

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

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

Commit 1527080 from [~steve_rowe] in branch 'dev/branches/lucene_solr_4_5'
[ https://svn.apache.org/r1527080 ]

SOLR-5281: IndexSchema log message was printing '[null]' instead of '[]' (merge trunk r1526972 and 1527074)

> Incorrect access core.properties in IndexSchema.java
> 
>
> Key: SOLR-5281
> URL: https://issues.apache.org/jira/browse/SOLR-5281
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.5
>Reporter: Jun Ohtani
>Assignee: Steve Rowe
>Priority: Minor
> Fix For: 5.0, 4.6
>
> Attachments: SOLR-5281.patch
>
>
> IndexSchema use core name for logging.
> But core name always output "[null] Schema..", the following.
> ---
>  "3814 [coreLoadExecutor-3-thread-1] INFO  org.apache.solr.schema.IndexSchema 
>  – Reading Solr Schema from schema.xml
> 3926 [coreLoadExecutor-3-thread-1] INFO  org.apache.solr.schema.IndexSchema  
> – [null] Schema name=example
> ---
> Maybe, property name pattern changed "name" to "solr.core.name" at SOLR-5162.
> --- IndexSchema.java
> ...
>   public static final String NAME = "name";
> ...
>   if (loader.getCoreProperties() != null) {
> sb.append(loader.getCoreProperties().getProperty(NAME));
>   } else {
> sb.append("null");
>   }

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

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

[jira] [Updated] (SOLR-5284) Solr Admin shows error message in Links GUI, even though no error

[Eric Pugh (JIRA)]

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

Eric Pugh updated SOLR-5284:


Attachment: solr-error.png

Screenshot of the CSS error.   Links is a critical browser ;-)

> Solr Admin shows error message in Links GUI, even though no error
> -
>
> Key: SOLR-5284
> URL: https://issues.apache.org/jira/browse/SOLR-5284
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.4
>Reporter: Eric Pugh
>Priority: Minor
> Attachments: solr-error.png
>
>
> Using the Links browser, when I browse to /solr/ the default admin interface 
> shows the SolrCore error message "SolrCore Initialization failure", even 
> though there was no error!  The CSS I think isn't properly hiding that 
> standard div.   

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

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

[jira] [Commented] (SOLR-5279) Implicit properties don't seem to exist on core RELOAD

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-5279: Move CHANGES.txt entry from 4.6 to 4.5 (merged trunk r1527076)

> Implicit properties don't seem to exist on core RELOAD
> --
>
> Key: SOLR-5279
> URL: https://issues.apache.org/jira/browse/SOLR-5279
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.5
> Environment: Solr 4.5.0 RC4
> Linux bigindy5 2.6.32-358.6.1.el6.centos.plus.x86_64 #1 SMP Wed Apr 24 
> 03:21:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.7.0_21"
> Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)
>Reporter: Shawn Heisey
> Fix For: 4.5, 5.0, 4.6
>
> Attachments: SOLR-5279.patch, SOLR-5279-test.patch
>
>
> The implicit properties (specifically solr.core.name) work fine for Solr 
> startup, but on core RELOAD, they no longer exist, so configurations that use 
> them result in the core not initializing.
> Problem discovered on 4.5.0 RC4, works fine in 4.4.0.

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

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

[jira] [Commented] (SOLR-5279) Implicit properties don't seem to exist on core RELOAD

[ASF subversion and git services (JIRA)]

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

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

Commit 1527076 from [~steve_rowe] in branch 'dev/trunk'
[ https://svn.apache.org/r1527076 ]

SOLR-5279: Move CHANGES.txt entry from 4.6 to 4.5

> Implicit properties don't seem to exist on core RELOAD
> --
>
> Key: SOLR-5279
> URL: https://issues.apache.org/jira/browse/SOLR-5279
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.5
> Environment: Solr 4.5.0 RC4
> Linux bigindy5 2.6.32-358.6.1.el6.centos.plus.x86_64 #1 SMP Wed Apr 24 
> 03:21:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.7.0_21"
> Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)
>Reporter: Shawn Heisey
> Fix For: 4.5, 5.0, 4.6
>
> Attachments: SOLR-5279.patch, SOLR-5279-test.patch
>
>
> The implicit properties (specifically solr.core.name) work fine for Solr 
> startup, but on core RELOAD, they no longer exist, so configurations that use 
> them result in the core not initializing.
> Problem discovered on 4.5.0 RC4, works fine in 4.4.0.

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

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

[jira] [Commented] (SOLR-5281) Incorrect access core.properties in IndexSchema.java

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-5281: Move CHANGES.txt entry from 4.6 to 4.5 (merged trunk r1527074)

> Incorrect access core.properties in IndexSchema.java
> 
>
> Key: SOLR-5281
> URL: https://issues.apache.org/jira/browse/SOLR-5281
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.5
>Reporter: Jun Ohtani
>Assignee: Steve Rowe
>Priority: Minor
> Fix For: 5.0, 4.6
>
> Attachments: SOLR-5281.patch
>
>
> IndexSchema use core name for logging.
> But core name always output "[null] Schema..", the following.
> ---
>  "3814 [coreLoadExecutor-3-thread-1] INFO  org.apache.solr.schema.IndexSchema 
>  – Reading Solr Schema from schema.xml
> 3926 [coreLoadExecutor-3-thread-1] INFO  org.apache.solr.schema.IndexSchema  
> – [null] Schema name=example
> ---
> Maybe, property name pattern changed "name" to "solr.core.name" at SOLR-5162.
> --- IndexSchema.java
> ...
>   public static final String NAME = "name";
> ...
>   if (loader.getCoreProperties() != null) {
> sb.append(loader.getCoreProperties().getProperty(NAME));
>   } else {
> sb.append("null");
>   }

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

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

[jira] [Commented] (SOLR-5281) Incorrect access core.properties in IndexSchema.java

[ASF subversion and git services (JIRA)]

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

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

Commit 1527074 from [~steve_rowe] in branch 'dev/trunk'
[ https://svn.apache.org/r1527074 ]

SOLR-5281: Move CHANGES.txt entry from 4.6 to 4.5

> Incorrect access core.properties in IndexSchema.java
> 
>
> Key: SOLR-5281
> URL: https://issues.apache.org/jira/browse/SOLR-5281
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.5
>Reporter: Jun Ohtani
>Assignee: Steve Rowe
>Priority: Minor
> Fix For: 5.0, 4.6
>
> Attachments: SOLR-5281.patch
>
>
> IndexSchema use core name for logging.
> But core name always output "[null] Schema..", the following.
> ---
>  "3814 [coreLoadExecutor-3-thread-1] INFO  org.apache.solr.schema.IndexSchema 
>  – Reading Solr Schema from schema.xml
> 3926 [coreLoadExecutor-3-thread-1] INFO  org.apache.solr.schema.IndexSchema  
> – [null] Schema name=example
> ---
> Maybe, property name pattern changed "name" to "solr.core.name" at SOLR-5162.
> --- IndexSchema.java
> ...
>   public static final String NAME = "name";
> ...
>   if (loader.getCoreProperties() != null) {
> sb.append(loader.getCoreProperties().getProperty(NAME));
>   } else {
> sb.append("null");
>   }

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

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

[jira] [Created] (SOLR-5284) Solr Admin shows error message in Links GUI, even though no error

[Eric Pugh (JIRA)]

Eric Pugh created SOLR-5284:
---

 Summary: Solr Admin shows error message in Links GUI, even though 
no error
 Key: SOLR-5284
 URL: https://issues.apache.org/jira/browse/SOLR-5284
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.4
Reporter: Eric Pugh
Priority: Minor


Using the Links browser, when I browse to /solr/ the default admin interface 
shows the SolrCore error message "SolrCore Initialization failure", even though 
there was no error!  The CSS I think isn't properly hiding that standard div.   

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

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

Re: [VOTE] Release Lucene/Solr 4.5.0 RC4

[Adrien Grand]

Hi Steve,

On Fri, Sep 27, 2013 at 9:30 PM, Steve Rowe  wrote:
> I attached a fix to the issue Shawn created for the missing implicit 
> Solr-core-properties-on-RELOAD issue: SOLR-5279
>
> IMHO, this regression should be fixed in 4.5.
>
> Adrien, I tried to raise you on IRC but didn't get a response - is it okay 
> with you to do a respin?  I'll commit to trunk and branch_4x with the 
> CHANGES.txt entry under 4.6 until you say it's okay.

Indeed, I was not keeping an eye on IRC. I will respin tomorrow
morning european time. Thanks for fixing this issue!

-- 
Adrien

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

Re: VOTE RC0 Release apache-solr-ref-guide-4.5.pdf"

[Otis Gospodnetic]

I have just 3 chars to contribute: WOW

Otis



On Thu, Sep 26, 2013 at 8:29 AM, Steve Rowe  wrote:
> Except for #1/#34 - internal links to beginning-of-page sections point one 
> page earlier than they should - and #8/#41 - missing Thai and Polish chars - 
> which I don't know how to fix, I'll try to address the other items on this 
> (um, very long) list of mostly minor stuff I found:
>
> 0. All examples in the exported PDF have an extra blank line at the top.  I 
> was able to eliminate these from this page 
>  
> ("What is an analyzer?") by eliminating the newline between the initial {code 
> …} line and the first line of the examples.  This doesn't have any apparent 
> effect on the layout of the page on the wiki, but the PDF export of that page 
> no longer has the extra blank lines.  Any objections to switching all {code} 
> examples in the guide like this?
>
> 1. Pg 2: The section links from the TOC all take you to the previous page, 
> rather than to the top of the page where the section starts.  (Same behavior 
> on OS X Preview, and under Windows, on Firefox's built-in PDF viewer and on 
> Adobe Reader.)  This looks like a general problem - see e.g. #34.
>
> 2. Pg 68: Stray asterisks in the  tags in the  example 
> under "Analysis Phases", apparently to make the surrounded text bold (which 
> also didn't happen).
>
> 3. Pg 69: The solr.KeywordTokenizerFactory example is missing one quotation 
> mark from each of the left and right hand sides.
>
> 4. Pg 70: Under "solr.TokenizerFactory", there is a bogus "StandardTokenizer" 
> link in the sentence "Theere aren't any filters that use StandardTokenizer's 
> types" - the link is to the non-existent "StandardTokenizer" page on the Solr 
> wiki.  (It might be useful to systematically link stuff like this to the 
> corresponding Lucene or Solr javadocs, but this should probably be templated 
> or scripted, so that the version-specific links are handled properly.)
>
> 5. Pg 71: Under "Standard Tokenizer", the email addresses recognition claim 
> is false, and Internet domain name recognition isn't validation per se, e.g. 
> "google.supercomputername" will be tokenized as a single token along with 
> "google.com".  The "Out" example output needs fixup accordingly.  I see that 
> the "Classic Tokenizer" section on pg 72 has the verbatim email/domain text; 
> for ClassicTokenizer, the email claim is true, but it has the same issue with 
> internet domain names as StandardTokenizer.
>
> 6. Pg 74: The NGram Tokenizer example output should be ("bicy", "bicyc", 
> "icyc", "icycl", "cycl", "cycle", "ycle") instead of all of the 4grams before 
> the 5grams (I think this class's behavior was changed in 4.4 by LUCENE-5042).
>
> 7. Pg 75: The ICU tokenizer "rulefiles" argument is missing.
>
> 8. Pg 75: The ICU Tokenizer's "In" input and "Out" output are completely 
> missing the Thai text that's visible on the wiki.
>
> 9. Pg 75: Missing spaces in the Regular Expression Pattern Tokenizer's 
> "group" attribute description, at the boundaries between the first two 
> sentences: "token(s).The" and "tokens.Non-negative".
>
> 10. Pg 72, 76, 77, etc.: Many analysis components' factory class names should 
> be styled with a fixed-width font.
>
> 11. Pg 77: UAX29 URL Email Tokenizer recognizes not only .com Internet domain 
> names, but also domain names including any other valid top-level domain 
> (i.e., unlike StandardTokenizer and ClassicTokenizer, domain names are 
> validated against the white list drawn from the IANA Root Zone database 
>  as of the last time "ant gen-tld" 
> was performed and the tokenizer was generated.)
>
> 12. Pg 77: UAX29 tokenizer: "file:://" should be "file://"
>
> 13. Pg 77: UAX29 tokenizer's  and  type names are missing angle 
> brackets.
>
> 14. Pg 77: UAX29 tokenizer's maxTokenLength attribute name should be styled 
> with a fixed-width font.
>
> 15. Pg 78: In the example demonstrating how arguments can be given to 
>  elements via attributes, there is a stray asterisk, apparently 
> intended to bold the surrounding text, which also didn't work: *min="2" 
> max="7"/>
>
> 16. Pg 79: The ASCII Folding Filter's "Out" output should have the accent 
> stripped from the "á" -> "a" and the ASCII character value adjusted -> (ASCII 
> character 97)
>
> 17. Pg 81: The Edge N-gram Filter's 4-6 gram size example "Out" should be 
> ("four", "scor", "score", "twen", "twent", "twenty") - some of these are 
> missing.
>
> 18. Pg 83: The ICU Normalizer 2 Filter example should include the "name" and 
> "mode" attributes in the  element.
>
> 19. Pg 87: Stray asterisks in both of the N-Gram Filter examples: 
> *minGramSize="...
>
> 20. Pg 87: The N-Gram Filter 3-5 gram size example "Out" output should be 
> ("fou", "four", "our", "sco", "scor", "score", "cor", "core", "ore") - rather 
> than ordering by gram size, output is now ordered first by

Re: NumericRangeTermsEnum

[Michael McCandless]

Normally you'd create a NumericRangeFilter/Query and just use that?

Under the hood, Lucene uses that protected API to visit all matching terms...

Mike McCandless

http://blog.mikemccandless.com


On Thu, Sep 26, 2013 at 9:59 AM, Chet Vora  wrote:
> Hi all
>
> I was trying to use the above enum to do some range search on dates... this
> enum is returned by NumericRangeQuery.getTermsEnum() but I realized that
> this is a protected method of the class and since this is a final class, I
> can't see how I can use it. Maybe I'm missing something ?
>
> Would appreciate any pointers.
>
> Thanks
>
> CV

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

[Michael McCandless]

This one reproduces; is anyone looking?

Mike McCandless

http://blog.mikemccandless.com


On Thu, Sep 26, 2013 at 4:27 PM, Policeman Jenkins Server
 wrote:
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/7639/
> Java: 32bit/jdk1.7.0_40 -client -XX:+UseSerialGC
>
> 1 tests failed.
> REGRESSION:  
> org.apache.lucene.index.TestNumericDocValuesUpdates.testChangeCodec
>
> Error Message:
> expected:<12> but was:<17>
>
> Stack Trace:
> java.lang.AssertionError: expected:<12> but was:<17>
> at 
> __randomizedtesting.SeedInfo.seed([A099DBB8181A4538:C1FFAD77A92F9D1E]:0)
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:472)
> at org.junit.Assert.assertEquals(Assert.java:456)
> at 
> org.apache.lucene.index.TestNumericDocValuesUpdates.testChangeCodec(TestNumericDocValuesUpdates.java:1074)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
> at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
> at 
> org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
> at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
> at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
> at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
> at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
> at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at 
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
> at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
> at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
> at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
> at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
> at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
> at 
> org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
> at java.lang.Thread.ru

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

[Apache Jenkins Server]

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

No tests ran.

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



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

[jira] [Commented] (SOLR-5279) Implicit properties don't seem to exist on core RELOAD

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-5279: Implicit properties don't seem to exist on core RELOAD (merged trunk 
r1527042)

> Implicit properties don't seem to exist on core RELOAD
> --
>
> Key: SOLR-5279
> URL: https://issues.apache.org/jira/browse/SOLR-5279
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.5
> Environment: Solr 4.5.0 RC4
> Linux bigindy5 2.6.32-358.6.1.el6.centos.plus.x86_64 #1 SMP Wed Apr 24 
> 03:21:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.7.0_21"
> Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)
>Reporter: Shawn Heisey
> Fix For: 4.5, 5.0, 4.6
>
> Attachments: SOLR-5279.patch, SOLR-5279-test.patch
>
>
> The implicit properties (specifically solr.core.name) work fine for Solr 
> startup, but on core RELOAD, they no longer exist, so configurations that use 
> them result in the core not initializing.
> Problem discovered on 4.5.0 RC4, works fine in 4.4.0.

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

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

[jira] [Commented] (SOLR-5279) Implicit properties don't seem to exist on core RELOAD

[ASF subversion and git services (JIRA)]

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

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

Commit 1527042 from [~steve_rowe] in branch 'dev/trunk'
[ https://svn.apache.org/r1527042 ]

SOLR-5279: Implicit properties don't seem to exist on core RELOAD

> Implicit properties don't seem to exist on core RELOAD
> --
>
> Key: SOLR-5279
> URL: https://issues.apache.org/jira/browse/SOLR-5279
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.5
> Environment: Solr 4.5.0 RC4
> Linux bigindy5 2.6.32-358.6.1.el6.centos.plus.x86_64 #1 SMP Wed Apr 24 
> 03:21:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.7.0_21"
> Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)
>Reporter: Shawn Heisey
> Fix For: 4.5, 5.0, 4.6
>
> Attachments: SOLR-5279.patch, SOLR-5279-test.patch
>
>
> The implicit properties (specifically solr.core.name) work fine for Solr 
> startup, but on core RELOAD, they no longer exist, so configurations that use 
> them result in the core not initializing.
> Problem discovered on 4.5.0 RC4, works fine in 4.4.0.

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

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

Re: [VOTE] Release Lucene/Solr 4.5.0 RC4

[Steve Rowe]

I attached a fix to the issue Shawn created for the missing implicit 
Solr-core-properties-on-RELOAD issue: SOLR-5279

IMHO, this regression should be fixed in 4.5.

Adrien, I tried to raise you on IRC but didn't get a response - is it okay with 
you to do a respin?  I'll commit to trunk and branch_4x with the CHANGES.txt 
entry under 4.6 until you say it's okay.

Steve

On Sep 26, 2013, at 7:36 PM, Shawn Heisey  wrote:

> On 9/26/2013 1:26 PM, Adrien Grand wrote:
>> Here is a new release candidate for which LUCENE-5218, LUCENE-5245 and
>> LUCENE-5233 have been backported. Please vote to release the following
>> artifacts:
>>   
>> http://people.apache.org/~jpountz/staging_area/lucene-solr-4.5.0-RC4-rev1526586/
>> 
>> This vote is open until Tuesday.
>> 
>> Smoke tester was happy on my end, so here is my +1.
>> 
> 
> I just ran into a problem with the release candidate, let me know if you 
> think it's a release-stopper.  I wasn't looking for anything wrong, I was 
> just putting the release candidate on my dev server.  I noticed a cosmetic 
> issue, and while I was trying to track down that, I stumbled across something 
> bigger.  This is not running with zookeeper.
> 
> 
> Pieces of my solrconfig.xml file are shared (via symlinks and xinclude 
> directives) with many different cores.  In the file for the indexConfig 
> section, I have this:
> 
>  false
> 
> During startup, this doesn't cause any problem at all.  On core reload, 
> however, I get a big exception and it can't initialize the core.  The cause:
> 
> Caused by: org.apache.solr.common.SolrException: No system property or 
> default value specified for solr.core.name 
> value:INFOSTREAM-${solr.core.name}.txt
>at 
> org.apache.solr.util.PropertiesUtil.substituteProperty(PropertiesUtil.java:66)
>at org.apache.solr.util.DOMUtil.substituteProperties(DOMUtil.java:298)
>at org.apache.solr.util.DOMUtil.substituteProperties(DOMUtil.java:300)
>at org.apache.solr.util.DOMUtil.substituteProperties(DOMUtil.java:300)
>at org.apache.solr.core.Config.(Config.java:141)
>at org.apache.solr.core.Config.(Config.java:86)
>at org.apache.solr.core.SolrConfig.(SolrConfig.java:129)
>at org.apache.solr.core.SolrCore.reload(SolrCore.java:403)
>at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:681)
>... 31 more
> 
> I've run into problems with the implicit properties before, but that was at 
> Solr startup.  This is the first time in quite a while that I've tried a 
> RELOAD on my dev server, so I don't know how long this problem has existed.
> 
> At one point, I had to use ${name} instead of ${solr.core.name} in branch_4x 
> versions, but that got fixed.  If I need to use a different property going 
> forward, I'm OK with that.  I know that Hoss was doing something recently 
> with implicit properties in the Reference Guide, but I haven't looked at it 
> closely.
> 
> Thanks,
> Shawn
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

[jira] [Updated] (SOLR-5279) Implicit properties don't seem to exist on core RELOAD

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-5279:
-

Attachment: SOLR-5279.patch

Patch, test passes under trunk and lucene_solr_4_5 branch; includes 
{{SOLR-5279-test.patch}}.

The problem appears to be that when [~romseygeek] fixed implicit core 
properties in {{CoreDescriptor.java}} under SOLR-5162, he forgot to include 
copying over the new {{substitutableProperties}} in the 
copy-constructor-with-new-core-name: {{CoreDescriptor(String,CoreDescriptor)}}. 
 I added this there, and that allowed the new test to pass.

Committing shortly.

> Implicit properties don't seem to exist on core RELOAD
> --
>
> Key: SOLR-5279
> URL: https://issues.apache.org/jira/browse/SOLR-5279
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.5
> Environment: Solr 4.5.0 RC4
> Linux bigindy5 2.6.32-358.6.1.el6.centos.plus.x86_64 #1 SMP Wed Apr 24 
> 03:21:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.7.0_21"
> Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)
>Reporter: Shawn Heisey
> Fix For: 4.5, 5.0, 4.6
>
> Attachments: SOLR-5279.patch, SOLR-5279-test.patch
>
>
> The implicit properties (specifically solr.core.name) work fine for Solr 
> startup, but on core RELOAD, they no longer exist, so configurations that use 
> them result in the core not initializing.
> Problem discovered on 4.5.0 RC4, works fine in 4.4.0.

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

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

[jira] [Commented] (SOLR-5279) Implicit properties don't seem to exist on core RELOAD

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-5279:
--

The test in the patch fails for me on lucene_solr_4_5 (after I first apply 
Hoss's test expansion patch to this branch: http://svn.apache.org/r1525733).  
I'm digging.

> Implicit properties don't seem to exist on core RELOAD
> --
>
> Key: SOLR-5279
> URL: https://issues.apache.org/jira/browse/SOLR-5279
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.5
> Environment: Solr 4.5.0 RC4
> Linux bigindy5 2.6.32-358.6.1.el6.centos.plus.x86_64 #1 SMP Wed Apr 24 
> 03:21:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.7.0_21"
> Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)
>Reporter: Shawn Heisey
> Fix For: 4.5, 5.0, 4.6
>
> Attachments: SOLR-5279-test.patch
>
>
> The implicit properties (specifically solr.core.name) work fine for Solr 
> startup, but on core RELOAD, they no longer exist, so configurations that use 
> them result in the core not initializing.
> Problem discovered on 4.5.0 RC4, works fine in 4.4.0.

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

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

[jira] [Commented] (SOLR-5027) Result Set Collapse and Expand Plugins

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-5027:
--

Simon,

Your idea sounds good and should be no problem to implement. When I finish up 
the work on the Expand component I'll work on getting this in.



> Result Set Collapse and Expand Plugins
> --
>
> 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
>Priority: Minor
> Attachments: SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch, 
> SOLR-5027.patch
>
>
> This ticket introduces two new Solr plugins, the *CollapsingQParserPlugin* 
> and the *ExpandComponent*.
> The *CollapsingQParserPlugin* is a PostFilter that performs field collapsing.
> 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 *ExpandComponent* is a search component that takes the collapsed docList 
> and expands the groups for a single page based on parameters provided.
> Initial syntax:
> expand=true   - Turns on the expand component.
> expand.field= - Expands results for this field
> expand.limit=5 - Limits the documents for each expanded group.
> expand.sort= - The sort spec for the expanded documents. Default 
> is score.
> expand.rows=500 - The max number of expanded results to bring back. Default 
> is 500.
> *Note:* Recent patches don't contain the expand component. The July 16 patch 
> does. This will be brought back in when the collapse is finished, or possible 
> moved to it's own ticket.

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

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

[jira] [Commented] (SOLR-5281) Incorrect access core.properties in IndexSchema.java

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-5281:
--

FYI, I looked and didn't find any other references to the implicit core "name" 
property accessed via {{SolrResourceLoader}}'s {{coreProperties}} or 
{{getCoreProperties()}}.

> Incorrect access core.properties in IndexSchema.java
> 
>
> Key: SOLR-5281
> URL: https://issues.apache.org/jira/browse/SOLR-5281
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.5
>Reporter: Jun Ohtani
>Assignee: Steve Rowe
>Priority: Minor
> Fix For: 5.0, 4.6
>
> Attachments: SOLR-5281.patch
>
>
> IndexSchema use core name for logging.
> But core name always output "[null] Schema..", the following.
> ---
>  "3814 [coreLoadExecutor-3-thread-1] INFO  org.apache.solr.schema.IndexSchema 
>  – Reading Solr Schema from schema.xml
> 3926 [coreLoadExecutor-3-thread-1] INFO  org.apache.solr.schema.IndexSchema  
> – [null] Schema name=example
> ---
> Maybe, property name pattern changed "name" to "solr.core.name" at SOLR-5162.
> --- IndexSchema.java
> ...
>   public static final String NAME = "name";
> ...
>   if (loader.getCoreProperties() != null) {
> sb.append(loader.getCoreProperties().getProperty(NAME));
>   } else {
> sb.append("null");
>   }

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

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

[jira] [Commented] (SOLR-5281) Incorrect access core.properties in IndexSchema.java

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-5281: IndexSchema log message was printing '[null]' instead of '[]' (merge trunk r1526972)

> Incorrect access core.properties in IndexSchema.java
> 
>
> Key: SOLR-5281
> URL: https://issues.apache.org/jira/browse/SOLR-5281
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.5
>Reporter: Jun Ohtani
>Priority: Minor
> Attachments: SOLR-5281.patch
>
>
> IndexSchema use core name for logging.
> But core name always output "[null] Schema..", the following.
> ---
>  "3814 [coreLoadExecutor-3-thread-1] INFO  org.apache.solr.schema.IndexSchema 
>  – Reading Solr Schema from schema.xml
> 3926 [coreLoadExecutor-3-thread-1] INFO  org.apache.solr.schema.IndexSchema  
> – [null] Schema name=example
> ---
> Maybe, property name pattern changed "name" to "solr.core.name" at SOLR-5162.
> --- IndexSchema.java
> ...
>   public static final String NAME = "name";
> ...
>   if (loader.getCoreProperties() != null) {
> sb.append(loader.getCoreProperties().getProperty(NAME));
>   } else {
> sb.append("null");
>   }

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

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

[jira] [Resolved] (SOLR-5281) Incorrect access core.properties in IndexSchema.java

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-5281.
--

   Resolution: Fixed
Fix Version/s: 4.6
   5.0
 Assignee: Steve Rowe

Committed to trunk and branch_4x.

Thanks Jun!

> Incorrect access core.properties in IndexSchema.java
> 
>
> Key: SOLR-5281
> URL: https://issues.apache.org/jira/browse/SOLR-5281
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.5
>Reporter: Jun Ohtani
>Assignee: Steve Rowe
>Priority: Minor
> Fix For: 5.0, 4.6
>
> Attachments: SOLR-5281.patch
>
>
> IndexSchema use core name for logging.
> But core name always output "[null] Schema..", the following.
> ---
>  "3814 [coreLoadExecutor-3-thread-1] INFO  org.apache.solr.schema.IndexSchema 
>  – Reading Solr Schema from schema.xml
> 3926 [coreLoadExecutor-3-thread-1] INFO  org.apache.solr.schema.IndexSchema  
> – [null] Schema name=example
> ---
> Maybe, property name pattern changed "name" to "solr.core.name" at SOLR-5162.
> --- IndexSchema.java
> ...
>   public static final String NAME = "name";
> ...
>   if (loader.getCoreProperties() != null) {
> sb.append(loader.getCoreProperties().getProperty(NAME));
>   } else {
> sb.append("null");
>   }

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

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

[jira] [Commented] (SOLR-5281) Incorrect access core.properties in IndexSchema.java

[ASF subversion and git services (JIRA)]

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

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

Commit 1526972 from [~steve_rowe] in branch 'dev/trunk'
[ https://svn.apache.org/r1526972 ]

SOLR-5281: IndexSchema log message was printing '[null]' instead of '[]'

> Incorrect access core.properties in IndexSchema.java
> 
>
> Key: SOLR-5281
> URL: https://issues.apache.org/jira/browse/SOLR-5281
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.5
>Reporter: Jun Ohtani
>Priority: Minor
> Attachments: SOLR-5281.patch
>
>
> IndexSchema use core name for logging.
> But core name always output "[null] Schema..", the following.
> ---
>  "3814 [coreLoadExecutor-3-thread-1] INFO  org.apache.solr.schema.IndexSchema 
>  – Reading Solr Schema from schema.xml
> 3926 [coreLoadExecutor-3-thread-1] INFO  org.apache.solr.schema.IndexSchema  
> – [null] Schema name=example
> ---
> Maybe, property name pattern changed "name" to "solr.core.name" at SOLR-5162.
> --- IndexSchema.java
> ...
>   public static final String NAME = "name";
> ...
>   if (loader.getCoreProperties() != null) {
> sb.append(loader.getCoreProperties().getProperty(NAME));
>   } else {
> sb.append("null");
>   }

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

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

[jira] [Commented] (SOLR-5281) Incorrect access core.properties in IndexSchema.java

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-5281:


This is the problem that I had noticed and was looking into further when I 
stumbled onto SOLR-5279.


> Incorrect access core.properties in IndexSchema.java
> 
>
> Key: SOLR-5281
> URL: https://issues.apache.org/jira/browse/SOLR-5281
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.5
>Reporter: Jun Ohtani
>Priority: Minor
> Attachments: SOLR-5281.patch
>
>
> IndexSchema use core name for logging.
> But core name always output "[null] Schema..", the following.
> ---
>  "3814 [coreLoadExecutor-3-thread-1] INFO  org.apache.solr.schema.IndexSchema 
>  – Reading Solr Schema from schema.xml
> 3926 [coreLoadExecutor-3-thread-1] INFO  org.apache.solr.schema.IndexSchema  
> – [null] Schema name=example
> ---
> Maybe, property name pattern changed "name" to "solr.core.name" at SOLR-5162.
> --- IndexSchema.java
> ...
>   public static final String NAME = "name";
> ...
>   if (loader.getCoreProperties() != null) {
> sb.append(loader.getCoreProperties().getProperty(NAME));
>   } else {
> sb.append("null");
>   }

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

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

[jira] [Updated] (SOLR-5281) Incorrect access core.properties in IndexSchema.java

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-5281:
-

Attachment: SOLR-5281.patch

Trivial patch against trunk.  I applied this to the lucene_solr_4_5 branch and 
the core name shows up in the log message instead of null.  Committing shortly.

> Incorrect access core.properties in IndexSchema.java
> 
>
> Key: SOLR-5281
> URL: https://issues.apache.org/jira/browse/SOLR-5281
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.5
>Reporter: Jun Ohtani
>Priority: Minor
> Attachments: SOLR-5281.patch
>
>
> IndexSchema use core name for logging.
> But core name always output "[null] Schema..", the following.
> ---
>  "3814 [coreLoadExecutor-3-thread-1] INFO  org.apache.solr.schema.IndexSchema 
>  – Reading Solr Schema from schema.xml
> 3926 [coreLoadExecutor-3-thread-1] INFO  org.apache.solr.schema.IndexSchema  
> – [null] Schema name=example
> ---
> Maybe, property name pattern changed "name" to "solr.core.name" at SOLR-5162.
> --- IndexSchema.java
> ...
>   public static final String NAME = "name";
> ...
>   if (loader.getCoreProperties() != null) {
> sb.append(loader.getCoreProperties().getProperty(NAME));
>   } else {
> sb.append("null");
>   }

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

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

[jira] [Commented] (SOLR-5162) Implicit core properties are no longer available

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-5162:
--

bq. Was it intentional that the "name" property disappear? See SOLR-5281

Answering my own question: Yes:
{code:java|title=CoreDescriptor.java line #213}
  /**
   * Create the properties object used by resource loaders, etc, for property
   * substitution.  The default solr properties are prefixed with 'solr.core.', 
so,
   * e.g., 'name' becomes 'solr.core.name'
   */
  protected void buildSubstitutableProperties() {
for (String propName : coreProperties.stringPropertyNames()) {
  String propValue = coreProperties.getProperty(propName);
  if (!isUserDefinedProperty(propName))
propName = "solr.core." + propName;
  substitutableProperties.setProperty(propName, propValue);
}
  }
{code}

> Implicit core properties are no longer available
> 
>
> Key: SOLR-5162
> URL: https://issues.apache.org/jira/browse/SOLR-5162
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.5
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Fix For: 4.5
>
> Attachments: SOLR-5162.patch, SOLR-5162.patch
>
>
> As noted by ~elyograg on IRC, implicit property substitution doesn't work any 
> more in 4.5.

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

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

[jira] [Commented] (SOLR-5232) SolrCloud should distribute updates via streaming rather than buffering.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-5232:
---

Hmm, lost in the noise for me because 205.66ms (that test's runtime for me) 
doesn't increase the total run time with tests.jvms=8.

I'll dig into it.

> SolrCloud should distribute updates via streaming rather than buffering.
> 
>
> Key: SOLR-5232
> URL: https://issues.apache.org/jira/browse/SOLR-5232
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 5.0, 4.6
>
> Attachments: SOLR-5232.patch, SOLR-5232.patch, SOLR-5232.patch, 
> SOLR-5232.patch
>
>
> The current approach was never the best for SolrCloud - it was designed for a 
> pre SolrCloud Solr - it also uses too many connections and threads - nailing 
> that down is likely wasted effort when we should really move away from 
> explicitly buffering docs and sending small batches per thread as we have 
> been doing.

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

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

[jira] [Commented] (SOLR-5162) Implicit core properties are no longer available

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-5162:
--

Was it intentional that the "name" property disappear?  See SOLR-5281

> Implicit core properties are no longer available
> 
>
> Key: SOLR-5162
> URL: https://issues.apache.org/jira/browse/SOLR-5162
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.5
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Fix For: 4.5
>
> Attachments: SOLR-5162.patch, SOLR-5162.patch
>
>
> As noted by ~elyograg on IRC, implicit property substitution doesn't work any 
> more in 4.5.

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

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

[jira] [Commented] (SOLR-5281) Incorrect access core.properties in IndexSchema.java

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-5281:
--

Debugging 4.5, at the point in {{IndexSchema.java}} that Jun gave in the 
description, loader.coreProperties has:

{noformat}
{
  solr.core.config=solrconfig.xml, 
  
absoluteInstDir=/Users/sarowe/svn/lucene/dev/branches/lucene_solr_4_5/solr/example/solr/collection1/,
 
  solr.core.schema=schema.xml, 
  solr.core.transient=false, 
  
solr.core.instanceDir=/Users/sarowe/svn/lucene/dev/branches/lucene_solr_4_5/solr/example/solr/collection1,
 
  solr.core.dataDir=data/, 
  solr.core.loadOnStartup=true, 
  solr.core.name=collection1
} 
{noformat}

So Jun's analysis appears to be correct: coreProperties no longer contains 
"name", but rather "solr.core.name".

> Incorrect access core.properties in IndexSchema.java
> 
>
> Key: SOLR-5281
> URL: https://issues.apache.org/jira/browse/SOLR-5281
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.5
>Reporter: Jun Ohtani
>Priority: Minor
>
> IndexSchema use core name for logging.
> But core name always output "[null] Schema..", the following.
> ---
>  "3814 [coreLoadExecutor-3-thread-1] INFO  org.apache.solr.schema.IndexSchema 
>  – Reading Solr Schema from schema.xml
> 3926 [coreLoadExecutor-3-thread-1] INFO  org.apache.solr.schema.IndexSchema  
> – [null] Schema name=example
> ---
> Maybe, property name pattern changed "name" to "solr.core.name" at SOLR-5162.
> --- IndexSchema.java
> ...
>   public static final String NAME = "name";
> ...
>   if (loader.getCoreProperties() != null) {
> sb.append(loader.getCoreProperties().getProperty(NAME));
>   } else {
> sb.append("null");
>   }

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

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

[jira] [Commented] (SOLR-5232) SolrCloud should distribute updates via streaming rather than buffering.

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-5232:
-

fyi, ShardSplitTest is *much* slower with this patch e.g. 

ant -Dtests.seed=8FEFBE4A48F65343 -Dtestcase=ShardSplitTest clean test-core

Without patch: Total time: 1 minute 48 seconds
With patch: Total time: 4 minutes 25 seconds

> SolrCloud should distribute updates via streaming rather than buffering.
> 
>
> Key: SOLR-5232
> URL: https://issues.apache.org/jira/browse/SOLR-5232
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 5.0, 4.6
>
> Attachments: SOLR-5232.patch, SOLR-5232.patch, SOLR-5232.patch, 
> SOLR-5232.patch
>
>
> The current approach was never the best for SolrCloud - it was designed for a 
> pre SolrCloud Solr - it also uses too many connections and threads - nailing 
> that down is likely wasted effort when we should really move away from 
> explicitly buffering docs and sending small batches per thread as we have 
> been doing.

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

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

[jira] [Commented] (SOLR-5281) Incorrect access core.properties in IndexSchema.java

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-5281:
--

I can confirm that this is a regression.  I ran the example in both 4.4 and 4.5:

4.4:

{noformat}
1995 [coreLoadExecutor-3-thread-1] INFO  org.apache.solr.schema.IndexSchema  – 
[collection1] Schema name=example
{noformat}

4.5:

{noformat}
1939 [coreLoadExecutor-3-thread-1] INFO  org.apache.solr.schema.IndexSchema  – 
[null] Schema name=example
{noformat}

> Incorrect access core.properties in IndexSchema.java
> 
>
> Key: SOLR-5281
> URL: https://issues.apache.org/jira/browse/SOLR-5281
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.5
>Reporter: Jun Ohtani
>Priority: Minor
>
> IndexSchema use core name for logging.
> But core name always output "[null] Schema..", the following.
> ---
>  "3814 [coreLoadExecutor-3-thread-1] INFO  org.apache.solr.schema.IndexSchema 
>  – Reading Solr Schema from schema.xml
> 3926 [coreLoadExecutor-3-thread-1] INFO  org.apache.solr.schema.IndexSchema  
> – [null] Schema name=example
> ---
> Maybe, property name pattern changed "name" to "solr.core.name" at SOLR-5162.
> --- IndexSchema.java
> ...
>   public static final String NAME = "name";
> ...
>   if (loader.getCoreProperties() != null) {
> sb.append(loader.getCoreProperties().getProperty(NAME));
>   } else {
> sb.append("null");
>   }

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

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

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

[Apache Jenkins Server]

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

No tests ran.

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



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

[jira] [Updated] (SOLR-5232) SolrCloud should distribute updates via streaming rather than buffering.

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-5232:
--

Attachment: SOLR-5232.patch

This patch takes care of the nocommits in the previous patch. I'll commit 
shortly.

> SolrCloud should distribute updates via streaming rather than buffering.
> 
>
> Key: SOLR-5232
> URL: https://issues.apache.org/jira/browse/SOLR-5232
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 5.0, 4.6
>
> Attachments: SOLR-5232.patch, SOLR-5232.patch, SOLR-5232.patch, 
> SOLR-5232.patch
>
>
> The current approach was never the best for SolrCloud - it was designed for a 
> pre SolrCloud Solr - it also uses too many connections and threads - nailing 
> that down is likely wasted effort when we should really move away from 
> explicitly buffering docs and sending small batches per thread as we have 
> been doing.

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

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

[jira] [Created] (SOLR-5283) Admin UI issues in IE7

[Erik Hatcher (JIRA)]

Erik Hatcher created SOLR-5283:
--

 Summary: Admin UI issues in IE7
 Key: SOLR-5283
 URL: https://issues.apache.org/jira/browse/SOLR-5283
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.4
 Environment: IE Version 7.0.5730.11 64-bit edition.
Reporter: Erik Hatcher
Priority: Minor


A customer of ours reported:

{code}
IE Version 7.0.5730.11 64-bit edition.

Result:
Left nav area displays;
Main area: spinning loading icon displaying the word Loading ...

Script errors on page:
Line: 8
Char: 3
Error: 'CSSStyleDeclaration' is undefined
Code: 0
URL: http://:/solr/js/lib/d3.js

Line: 17
Char: 5
Error: Unexpected call to method or property access.
Code: 0
URL : http://:/solr/js/require.js
{code}

I've tried replicating this in a Windows virtual machine, but only have IE10 
and have not seen this issue.

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

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

[jira] [Commented] (SOLR-5280) Json response doesn't take long field type well

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-5280:
--

After reproducing this in Chrome, I tried to create a quick junit test and 
couldn't get it to fail there.

So I tried Safari and it does NOT fail there, so it appears to be a browser 
problem.

Not sure there's anything we can do about it, but don't have time to pursue it 
now.

Checked the index and both the admin/schema browser and terms component show 
the correct value in the index, which I could infer from the Safari display too.


> Json response doesn't take long field type well
> ---
>
> Key: SOLR-5280
> URL: https://issues.apache.org/jira/browse/SOLR-5280
> Project: Solr
>  Issue Type: Bug
>  Components: Response Writers
>Affects Versions: 4.2
>Reporter: Liu Xiang
>
> In my index, one field is defined as solr.LongField.
> After index, use solr webUI to fetch the doc.
> by default, xml response is as following, which is correct:
> 20584018100338
> 20584018102563
> Then Change "wt" to json, response is:
> [ 
>   20584018100350,
>   20584018102560
> ]

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

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

[jira] [Updated] (SOLR-5232) SolrCloud should distribute updates via streaming rather than buffering.

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-5232:
--

Fix Version/s: (was: 4.5)
   4.6

> SolrCloud should distribute updates via streaming rather than buffering.
> 
>
> Key: SOLR-5232
> URL: https://issues.apache.org/jira/browse/SOLR-5232
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 5.0, 4.6
>
> Attachments: SOLR-5232.patch, SOLR-5232.patch, SOLR-5232.patch
>
>
> The current approach was never the best for SolrCloud - it was designed for a 
> pre SolrCloud Solr - it also uses too many connections and threads - nailing 
> that down is likely wasted effort when we should really move away from 
> explicitly buffering docs and sending small batches per thread as we have 
> been doing.

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

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

Re: Welcome back, Wolfgang Hoschek!

[Yonik Seeley]

Welcome back Wolfgang!

-Yonik
http://lucidworks.com


On Fri, Sep 27, 2013 at 12:58 AM, Wolfgang Hoschek
 wrote:
> Thanks to all! Looking forward to more contributions.
>
> Wolfgang.
>
> On Sep 26, 2013, at 3:21 AM, Uwe Schindler wrote:
>
>> Hi,
>>
>> I'm pleased to announce that after a long abstinence, Wolfgang Hoschek 
>> rejoined the Lucene/Solr committer team. He is working now at Cloudera and 
>> plans to help with the integration of Solr and Hadoop.
>> Wolfgang originally wrote the MemoryIndex, which is used by the classical 
>> Lucene highlighter and ElasticSearch's percolator module.
>>
>> Looking forward to new contributions.
>>
>> Welcome back & heavy committing! :-)
>> Uwe
>>
>> P.S.: Wolfgang, as soon as you have setup your subversion access, you should 
>> add yourself back to the committers list on the website as well.
>>
>> -
>> Uwe Schindler
>> uschind...@apache.org
>> Apache Lucene PMC Chair / Committer
>> Bremen, Germany
>> http://lucene.apache.org/
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

[jira] [Created] (SOLR-5282) "Committed" (last commit time) in dataimport status is updated even when the commit fail

[Etienne CHAMPETIER (JIRA)]

Etienne CHAMPETIER created SOLR-5282:


 Summary: "Committed" (last commit time) in dataimport status is 
updated even when the commit fail
 Key: SOLR-5282
 URL: https://issues.apache.org/jira/browse/SOLR-5282
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
 Environment: OpenJDK 64-Bit Server VM (19.0-b09)
Rhel 5 - 2.6.18-274.el5 
Reporter: Etienne CHAMPETIER


Commit failed because of faulty disk with:
23:53:46 SEVERE SolrWriter Exception while solr commit.
But the "Committed" field on the status 
(/solr//dataimport?command=status) page show:
2013-09-25 23:53:46


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

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

Re: Welcome back, Wolfgang Hoschek!

[Stefan Matheis]

Welcome back :)

On Friday, September 27, 2013 at 9:44 AM, Alan Woodward wrote:

> Welcome back!
> 
> Alan Woodward
> www.flax.co.uk (http://www.flax.co.uk)
> 
> 
> On 27 Sep 2013, at 05:58, Wolfgang Hoschek wrote:
> > Thanks to all! Looking forward to more contributions.
> > 
> > Wolfgang.
> > 
> > On Sep 26, 2013, at 3:21 AM, Uwe Schindler wrote:
> > 
> > > Hi,
> > > 
> > > I'm pleased to announce that after a long abstinence, Wolfgang Hoschek 
> > > rejoined the Lucene/Solr committer team. He is working now at Cloudera 
> > > and plans to help with the integration of Solr and Hadoop.
> > > Wolfgang originally wrote the MemoryIndex, which is used by the classical 
> > > Lucene highlighter and ElasticSearch's percolator module.
> > > 
> > > Looking forward to new contributions.
> > > 
> > > Welcome back & heavy committing! :-)
> > > Uwe
> > > 
> > > P.S.: Wolfgang, as soon as you have setup your subversion access, you 
> > > should add yourself back to the committers list on the website as well.
> > > 
> > > -
> > > Uwe Schindler
> > > uschind...@apache.org (mailto:uschind...@apache.org) 
> > > Apache Lucene PMC Chair / Committer
> > > Bremen, Germany
> > > http://lucene.apache.org/
> > > 
> > > 
> > > 
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> > > (mailto:dev-unsubscr...@lucene.apache.org)
> > > For additional commands, e-mail: dev-h...@lucene.apache.org 
> > > (mailto:dev-h...@lucene.apache.org)
> > > 
> > 
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> > (mailto:dev-unsubscr...@lucene.apache.org)
> > For additional commands, e-mail: dev-h...@lucene.apache.org 
> > (mailto:dev-h...@lucene.apache.org)
> > 
> 

[jira] [Created] (SOLR-5281) Incorrect access core.properties in IndexSchema.java

[Jun Ohtani (JIRA)]

Jun Ohtani created SOLR-5281:


 Summary: Incorrect access core.properties in IndexSchema.java
 Key: SOLR-5281
 URL: https://issues.apache.org/jira/browse/SOLR-5281
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.5
Reporter: Jun Ohtani
Priority: Minor


IndexSchema use core name for logging.
But core name always output "[null] Schema..", the following.

---
 "3814 [coreLoadExecutor-3-thread-1] INFO  org.apache.solr.schema.IndexSchema  
– Reading Solr Schema from schema.xml
3926 [coreLoadExecutor-3-thread-1] INFO  org.apache.solr.schema.IndexSchema  – 
[null] Schema name=example

---

Maybe, property name pattern changed "name" to "solr.core.name" at SOLR-5162.

--- IndexSchema.java
...
  public static final String NAME = "name";
...
  if (loader.getCoreProperties() != null) {
sb.append(loader.getCoreProperties().getProperty(NAME));
  } else {
sb.append("null");
  }



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

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

Re: Welcome back, Wolfgang Hoschek!

[Alan Woodward]

Welcome back!

Alan Woodward
www.flax.co.uk


On 27 Sep 2013, at 05:58, Wolfgang Hoschek wrote:

> Thanks to all! Looking forward to more contributions.
> 
> Wolfgang.
> 
> On Sep 26, 2013, at 3:21 AM, Uwe Schindler wrote:
> 
>> Hi,
>> 
>> I'm pleased to announce that after a long abstinence, Wolfgang Hoschek 
>> rejoined the Lucene/Solr committer team. He is working now at Cloudera and 
>> plans to help with the integration of Solr and Hadoop.
>> Wolfgang originally wrote the MemoryIndex, which is used by the classical 
>> Lucene highlighter and ElasticSearch's percolator module.
>> 
>> Looking forward to new contributions.
>> 
>> Welcome back & heavy committing! :-)
>> Uwe
>> 
>> P.S.: Wolfgang, as soon as you have setup your subversion access, you should 
>> add yourself back to the committers list on the website as well.
>> 
>> -
>> Uwe Schindler
>> uschind...@apache.org 
>> Apache Lucene PMC Chair / Committer
>> Bremen, Germany
>> http://lucene.apache.org/
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

Re: Welcome back, Wolfgang Hoschek!

[Han Jiang]

Welcome back Wolfgang!


On Fri, Sep 27, 2013 at 2:19 PM, Robert Muir  wrote:

> Welcome back!
>
> On Thu, Sep 26, 2013 at 6:21 AM, Uwe Schindler 
> wrote:
> > Hi,
> >
> > I'm pleased to announce that after a long abstinence, Wolfgang Hoschek
> rejoined the Lucene/Solr committer team. He is working now at Cloudera and
> plans to help with the integration of Solr and Hadoop.
> > Wolfgang originally wrote the MemoryIndex, which is used by the
> classical Lucene highlighter and ElasticSearch's percolator module.
> >
> > Looking forward to new contributions.
> >
> > Welcome back & heavy committing! :-)
> > Uwe
> >
> > P.S.: Wolfgang, as soon as you have setup your subversion access, you
> should add yourself back to the committers list on the website as well.
> >
> > -
> > Uwe Schindler
> > uschind...@apache.org
> > Apache Lucene PMC Chair / Committer
> > Bremen, Germany
> > http://lucene.apache.org/
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>


-- 
Han Jiang

Team of Search Engine and Web Mining,
School of Electronic Engineering and Computer Science,
Peking University, China