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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13684/
Java: 64bit/jdk1.8.0_51 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.client.solrj.impl.CloudSolrClientTest.test

Error Message:
There should be 3 documents because there should be two id=1 docs due to 
overwrite=false expected:<3> but was:<1>

Stack Trace:
java.lang.AssertionError: There should be 3 documents because there should be 
two id=1 docs due to overwrite=false expected:<3> but was:<1>
at 
__randomizedtesting.SeedInfo.seed([3AE0588390F5CF4:8BFA3A5297F3310C]: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.apache.solr.client.solrj.impl.CloudSolrClientTest.testOverwriteOption(CloudSolrClientTest.java:159)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.test(CloudSolrClientTest.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
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:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailur

[jira] [Commented] (SOLR-7854) Remove ZkStateReader.updateClusterState(false)

[ASF subversion and git services (JIRA)]

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

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

Commit 1693681 from sha...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1693681 ]

SOLR-7854: Remove unused ZkStateReader.updateClusterState(false) method

> Remove ZkStateReader.updateClusterState(false)
> --
>
> Key: SOLR-7854
> URL: https://issues.apache.org/jira/browse/SOLR-7854
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.2.1
>Reporter: Scott Blum
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
>  Labels: easyfix, newbie
> Attachments: SOLR-7854.patch
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> `updateClusterState(false)` as far as I can tell has zero callers.  It's 
> super pointless anyway, because `updateClusterState(true)` is being used 
> mostly from test code and in places where someone is trying to force a reload 
> from ZK (for whatever reason).  There's no point in asking for a deferred 
> update when ZkStateReader is already going to keep itself in sync anyway.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Assigned] (SOLR-7854) Remove ZkStateReader.updateClusterState(false)

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar reassigned SOLR-7854:
---

Assignee: Shalin Shekhar Mangar

> Remove ZkStateReader.updateClusterState(false)
> --
>
> Key: SOLR-7854
> URL: https://issues.apache.org/jira/browse/SOLR-7854
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.2.1
>Reporter: Scott Blum
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
>  Labels: easyfix, newbie
> Attachments: SOLR-7854.patch
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> `updateClusterState(false)` as far as I can tell has zero callers.  It's 
> super pointless anyway, because `updateClusterState(true)` is being used 
> mostly from test code and in places where someone is trying to force a reload 
> from ZK (for whatever reason).  There's no point in asking for a deferred 
> update when ZkStateReader is already going to keep itself in sync anyway.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Lucene / Solr and Topic Modeling?

[Mattmann, Chris A (3980)]

Hey Folks,

Does anyone know of a good ALv2 compatible approach to Lucene and
to topic modeling? I’m looking to not have to do it post-facto
e.g. with a specific library, but to actually perform topic modeling
like LDA (or something else) while building the index.

The topic modeling needs to be scalable and dynamic - e.g., if I
change a query on years, the topics should be updated accordingly.
Is this possible with Lucene?

I’ve found this:

https://github.com/stepthom/lucene-lda


But it seems like it stopped short of the calls to actual topic
modeling e.g., with MALLET, etc.

Thanks for any help here.

Cheers,
Chris

++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattm...@nasa.gov
WWW:  http://sunset.usc.edu/~mattmann/
++
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++




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

[jira] [Commented] (SOLR-7849) Secure Inter-node communication in a standard mechanism

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-7849:
--

bq. How will node B be able to lookup the public key from core admin API of 
node A if A requires B to also authenticate? Perhaps publish pub-key through ZK 
instead of core admin?

The public-key will be available at every node through a standard end-point e.g 
{{/admin/cores/key}} which will always be unprotected


bq.What should happen in multi-DC case; would cross cluster communication be 
treated as "internal"? 

That mechanism will have to be sorted out. Not a part of this ticket

e.g : node-A in DC1 cluster wants to lookup node-P in DC2 cluster. We will 
publish the zk address of DC2 cluster in ZK of DC1 cluster and vice versa. This 
way node-A will trust al nodes in DC2 cluster as well

bq.What would  be in case the action is initiated by 
Solr and not an external request?

It will be a standard string like {{'$'}} which means the node itself is the 
principal


> Secure Inter-node communication in a  standard mechanism
> 
>
> Key: SOLR-7849
> URL: https://issues.apache.org/jira/browse/SOLR-7849
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
>
> Relying on every Authentication plugin to secure the internode communication 
> is error prone. Solr can standardize the authentication so that only the 
> first request that comes from outside the cluster needs to be authenticated 
> by the authentication plugin
> The scheme to protect the communication will be as follows
> * Every Solr node creates a an RSA key pair 
> * The private key is kept private and the public key is made available 
> through a  core admin API
> * If authentication is enabled , every outgoing request will carry an extra 
> header {{ SolrAuth :  
> encrypt_with_pvt_key( ) }}
> * If authentication is enabled {{SolrDispatchFilter}} would look for this 
> header and see the nodename
> ** If the public key of the nodename is available in cache , make a request 
> to the node and fetch the public key
> ** If the public key has changed (because of a server restart) decryption 
> fails and the public keyis fetched again
> * If the decryption succeeds , the user-name is set to what the header has 
> encoded



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.lucene.TestMergeSchedulerExternal.testSubclassConcurrentMergeScheduler

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([7B063949A8B1F445:FC8784E4AC918E41]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.lucene.TestMergeSchedulerExternal.testSubclassConcurrentMergeScheduler(TestMergeSchedulerExternal.java:116)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
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:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
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:365)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 696 lines...]
   [junit4] Suite: org.apache.lucene.TestMergeSchedulerExternal
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestMergeSchedulerExternal 
-Dtests.method=testSubclassConcurrentMergeScheduler 
-Dtests.seed=7B063949A8B1F445 -Dtests.slow=true -Dtests.locale=ja_JP 
-Dtests.timezone=Australia/Perth -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] FAILURE 0.74s J1 | 
TestMergeSchedulerExternal.testSubclassConcurrentMergeScheduler <<<
   [junit4]> Throwable #1: java.lang.AssertionError
   [junit4]>at 
__randomizedtesting.SeedInfo.see

[jira] [Created] (SOLR-7855) OverseerCollectionProcessor: separate general task management from collection message handling

[Gregory Chanan (JIRA)]

Gregory Chanan created SOLR-7855:


 Summary: OverseerCollectionProcessor: separate general task 
management from collection message handling
 Key: SOLR-7855
 URL: https://issues.apache.org/jira/browse/SOLR-7855
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Reporter: Gregory Chanan
Assignee: Gregory Chanan


While working on SOLR-7789, I realized it would be easier if I split up the 
OverseerCollectionProcessor into two parts:

1) General handling of tasks (work queues, etc)
2) Processing a collection handler request

I haven't decided whether the ConfigSet should have its own processor, i.e. 
OverseerConfigSetProcessor or reuse at least the thread for the 
OverseerCollectionProcessor, but in either case this refactoring will be 
helpful.  That is, if the ConfigSet processing has its own processing, I can 
reuse the general handling of tasks part.  If the ConfigSet processing reuses 
the OverseerCollectionProcessing thread, I won't complicate the implementation 
with ConfigSet operations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7849) Secure Inter-node communication in a standard mechanism

[JIRA]

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

Jan Høydahl commented on SOLR-7849:
---

Interesting idea. How will node B be able to lookup the public key from core 
admin API of node A if A requires B to also authenticate? Perhaps publish 
pub-key through ZK instead of core admin?
What should happen in multi-DC case; would cross cluster communication be 
treated as "internal"? What would  be in case the 
action is initiated by Solr and not an external request?

> Secure Inter-node communication in a  standard mechanism
> 
>
> Key: SOLR-7849
> URL: https://issues.apache.org/jira/browse/SOLR-7849
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
>
> Relying on every Authentication plugin to secure the internode communication 
> is error prone. Solr can standardize the authentication so that only the 
> first request that comes from outside the cluster needs to be authenticated 
> by the authentication plugin
> The scheme to protect the communication will be as follows
> * Every Solr node creates a an RSA key pair 
> * The private key is kept private and the public key is made available 
> through a  core admin API
> * If authentication is enabled , every outgoing request will carry an extra 
> header {{ SolrAuth :  
> encrypt_with_pvt_key( ) }}
> * If authentication is enabled {{SolrDispatchFilter}} would look for this 
> header and see the nodename
> ** If the public key of the nodename is available in cache , make a request 
> to the node and fetch the public key
> ** If the public key has changed (because of a server restart) decryption 
> fails and the public keyis fetched again
> * If the decryption succeeds , the user-name is set to what the header has 
> encoded



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Understanding performance degradation in range queries between Solr 5.2.1 and 4.10.4

[Adrien Grand]

Hi Tomás,

I suspect this might be related to LUCENE-5938. We changed the default
rewrite method for multi-term queries to load documents into a sparse
bit set first first, and only upgrade to a dense bit set when we know
many documents match. When there are lots of terms to intersect, then
we end up spending significant cpu time to build the sparse bit set to
eventually upgrade to a dense bit set like before. This might be what
you are seeing.

You might see the issue less with the population field because it has
fewer unique values, so postings lists are longer and the DocIdSet
building logic can upgrade quicker to a dense bit set.

Mike noticed this slowness when working on BDK trees and we changed
this first phase to use a plain int[] array that we sort and
deduplicate instead of a more fancy sparse bit set (LUCENE-6645),
which seemed to make things faster. Would it be possible for you to
also check a 5.3 snapshot?




On Fri, Jul 31, 2015 at 10:51 PM, Tomás Fernández Löbbe
 wrote:
> Hi, I'm seeing some query performance degradation between 4.10.4 and 5.2.1.
> It doesn't happen with all the queries, but for queries like range queries
> on fields with many different values the average time in 5.2.1 is worse than
> in 4.10.4. Is anyone seeing something similar?
>
> Test Details:
> * Single thread running queries continuously. I run the test twice for each
> Solr version.
> * JMeter running on my laptop, Solr running on EC2, on an m3.xlarge instance
> with all the defaults but with 5G heap. Index in local disk (SSD)
> * Plain Solr releases, nothing custom. Single Solr core, not in SolrCloud
> mode, no distributed search.
> * "allCountries" geonames dataset (~8M small docs). No updates during the
> test. Index Size is around 1.1GB for Solr 5.2.1 and 1.3GB for Solr 4.10.4
> (fits entirely in RAM)
> * jdk1.8.0_45
>
> Queries: 3k boolean queries (generated with terms from the dataset) with
> range queries as filters on "tlongitude" and "tlatitude" fields with
> randomly generated bounds, e.g.
> q=name:foo OR name:bar&fq=tlongitude:[W TO X]&fq=tlatitude:[Y TO Z]
>
> Fields are:
> 
> 
> Field Type:
>  positionIncrementGap="0"/>
>
> In this case, Solr 4.10.4 was between 20% to 30% faster than 5.2.1 in
> average.
>
> http://snag.gy/2yPPM.jpg
>
> Doing only the boolean queries show no performance difference between 4.10
> and 5.2, same thing if I do filters on a string field instead of the range
> queries.
>
> When using "double" field type (precisionStep="0"), the difference was
> bigger:
>
> longitude/latitude fields:
> 
> 
>  positionIncrementGap="0"/>
>
> http://snag.gy/Vi5uk.jpg
> I understand this is not the best field type definition for range queries,
> I'm just trying to understand the difference between the two versions and
> why.
>
> Performance was OK when doing range queries on the "population" field
> (long), but that field doesn't have many different values, only 300k out of
> the 8.3M docs have the population field with a value different to 0. On the
> other hand, doing range queries on the _version_ field did show a graph
> similar to the previous one:
>
> 
>  positionIncrementGap="0"/>
>
> http://snag.gy/4tc7e.jpg
>
> Any idea what could be causing this? Is this expected after some known
> change?
>
> With Solr 4.10, a single CPU core remains high during the test (close to
> 100%), but with Solr 5.2, different cores go up and down in utilization
> continuously. That's probably because of the different Jetty version I
> suppose.
> GC pattern looks similar in both. For both Solr versions I'm using the
> settings that ship with Solr (in solr.in.sh) except for Xmx and Xms
>



-- 
Adrien

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

[jira] [Commented] (SOLR-7846) QTs with $variable does not work with query parameter substitution

[JIRA]

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

Jan Høydahl commented on SOLR-7846:
---

Perhaps what we need is a generic way to escape the ${} syntax in XML files. A 
simple \${} could work, but is perhaps dangerous because many places Windows 
file paths may contain sysprop expansion, e.g. C:\$\{dir\}\foo.

> QTs with $variable does not work with query parameter substitution
> --
>
> Key: SOLR-7846
> URL: https://issues.apache.org/jira/browse/SOLR-7846
> Project: Solr
>  Issue Type: Bug
>Reporter: Bill Bell
>
> http://yonik.com/solr-query-parameter-substitution/
> This is not working as part of QTs in solrconfig.xml due to XML System 
> Property Substitution getting confused in SOLR 5.2.1.
> Cannot load the core, since ${value} is being used for XML parameters for 
> system property substitution.
> https://wiki.apache.org/solr/SolrConfigXml#System_property_substitution
> Can we support both?
> PS127
> hosp_quality_spec_boost:${pspec}
> This does not work since it thinks it is a System Property.
> We can check System Property and if not defined assume it is in Query, or 
> have a new parameter? 
> {noformat}
> ${variable} - for System Properties
> ${{variable}} - for Query Parameters?
> {noformat}
> Thoughts?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-5147) Support child documents in DIH

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-5147:


[~r_harish] it should. 

> Support child documents in DIH
> --
>
> Key: SOLR-5147
> URL: https://issues.apache.org/jira/browse/SOLR-5147
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Vadim Kirilchuk
>Assignee: Noble Paul
> Fix For: 5.1, Trunk
>
> Attachments: SOLR-5147-5x.patch, SOLR-5147.patch, SOLR-5147.patch, 
> dih-oome-fix.patch
>
>
> DIH should be able to index hierarchical documents, i.e. it should be able to 
> work with SolrInputDocuments#addChildDocument.
> There was patch in SOLR-3076: 
> https://issues.apache.org/jira/secure/attachment/12576960/dih-3076.patch
> But it is not uptodate and far from being complete.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-7854) Remove ZkStateReader.updateClusterState(false)

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-7854:
-
Attachment: SOLR-7854.patch

Simple patch against trunk.
(Would like to backport also)

> Remove ZkStateReader.updateClusterState(false)
> --
>
> Key: SOLR-7854
> URL: https://issues.apache.org/jira/browse/SOLR-7854
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.2.1
>Reporter: Scott Blum
>Priority: Minor
>  Labels: easyfix, newbie
> Attachments: SOLR-7854.patch
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> `updateClusterState(false)` as far as I can tell has zero callers.  It's 
> super pointless anyway, because `updateClusterState(true)` is being used 
> mostly from test code and in places where someone is trying to force a reload 
> from ZK (for whatever reason).  There's no point in asking for a deferred 
> update when ZkStateReader is already going to keep itself in sync anyway.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (LUCENE-6704) GeoPointInBBox/Distance queries can throw OOME

[Nicholas Knize (JIRA)]

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

Nicholas Knize edited comment on LUCENE-6704 at 7/31/15 9:38 PM:
-

Updated patch includes the following:

* reduces number of ranges by up to 100x (for very large queries)
* adds unit test that causes an OOME on current trunk. This test is marked as 
NIGHTLY because it is a large query that can slow each beast iteration by a few 
seconds.
* moves 32 bit encoding changes to LUCENE-6710
* resets GeoPointDistanceQuery to final


was (Author: nknize):
Updated patch includes the following:

* reduces number of ranges by up to 100x (for very large queries)
* adds unit test that causes an OOME on current trunk. This test is marked as 
NIGHTLY because it is a large query that can slow each beast iteration by a few 
seconds.
* moves 32 bit encoding changes to LUCENE-6710

> GeoPointInBBox/Distance queries can throw OOME
> --
>
> Key: LUCENE-6704
> URL: https://issues.apache.org/jira/browse/LUCENE-6704
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Nicholas Knize
> Attachments: LUCENE-6704.patch, LUCENE-6704.patch
>
>
> After investigating LUCENE-6685 the performance issues and improvements 
> related to GeoPointInBBox/Distance queries could be categorized into two 
> separate issues:
>  
> 1. OOME caused by an unnecessary number of ranges computed for Point Distance 
> Queries (bug in the GeoPointTermEnum base class where the bounding box was 
> used for intersections instead of the point radius)
> 2. API improvements providing configurable detail parameters.
> This issue addresses 1.  LUCENE-6685 will further investigate the need for 2 
> (after working 1 and correcting for unnecessary range detail, it looks like 2 
> may not be needed) 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-6704) GeoPointInBBox/Distance queries can throw OOME

[Nicholas Knize (JIRA)]

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

Nicholas Knize updated LUCENE-6704:
---
Attachment: LUCENE-6704.patch

Updated patch includes the following:

* reduces number of ranges by up to 100x (for very large queries)
* adds unit test that causes an OOME on current trunk. This test is marked as 
NIGHTLY because it is a large query that can slow each beast iteration by a few 
seconds.
* moves 32 bit encoding changes to LUCENE-6710

> GeoPointInBBox/Distance queries can throw OOME
> --
>
> Key: LUCENE-6704
> URL: https://issues.apache.org/jira/browse/LUCENE-6704
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Nicholas Knize
> Attachments: LUCENE-6704.patch, LUCENE-6704.patch
>
>
> After investigating LUCENE-6685 the performance issues and improvements 
> related to GeoPointInBBox/Distance queries could be categorized into two 
> separate issues:
>  
> 1. OOME caused by an unnecessary number of ranges computed for Point Distance 
> Queries (bug in the GeoPointTermEnum base class where the bounding box was 
> used for intersections instead of the point radius)
> 2. API improvements providing configurable detail parameters.
> This issue addresses 1.  LUCENE-6685 will further investigate the need for 2 
> (after working 1 and correcting for unnecessary range detail, it looks like 2 
> may not be needed) 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6234) Scoring modes for query time join

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-6234:


Impl notes:

* toString() is a little bit odd, it looks like
{code}
  "debug": {
"rawquerystring": "{!join from=id to=manu_id_s score=max 
fromIndex=products}inc",
"querystring": "{!join from=id to=manu_id_s score=max 
fromIndex=products}inc",
"parsedquery": "OtherCoreJoinQuery(OtherCoreJoinQuery [fromIndex=products, 
fromCoreOpenTime=1438087133575 extends SameCoreJoinQuery [fromQuery=text:inc, 
fromField=id, toField=manu_id_s, scoreMode=Max]])",
"parsedquery_toString": "OtherCoreJoinQuery [fromIndex=products, 
fromCoreOpenTime=1438087133575 extends SameCoreJoinQuery [fromQuery=text:inc, 
fromField=id, toField=manu_id_s, scoreMode=Max]]",
"explain": {
{code}
Let me know if you need to change it.

* for cross core join: when you commit into {{fromIndex}} query cache entry 
equality is determined by coreOpenTime() which is obtained from 
{{System.currentTimeMillis()}} it might cause some issues on edge 
cases/plarforms (that's why it wasn't covered with test), but this approach was 
inherited from \{!join}. Raise an issue if it's significant to you. 


> Scoring modes for query time join 
> --
>
> Key: SOLR-6234
> URL: https://issues.apache.org/jira/browse/SOLR-6234
> Project: Solr
>  Issue Type: New Feature
>  Components: query parsers
>Affects Versions: 5.3
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>  Labels: features, patch, test
> Fix For: 5.3
>
> Attachments: SOLR-6234-javadocsfix.patch, 
> SOLR-6234-trunk-CHANGES-fix.patch, SOLR-6234.patch, SOLR-6234.patch, 
> SOLR-6234.patch, SOLR-6234.patch, SOLR-6234.patch, SOLR-6234.patch, 
> SOLR-6234.patch, otherHandler.patch
>
>
> it adds ability to call Lucene's JoinUtil by specifying local param, ie  
> \{!join score=...} It supports:
> - {{score=none|avg|max|total}} local param (passed as ScoreMode to JoinUtil)
> - -supports {{b=100}} param to pass {{Query.setBoost()}}- postponed till 
> SOLR-7814.
> - -{{multiVals=true|false}} is introduced- YAGNI, let me know otherwise. 
> - there is a test coverage for cross core join case. 
> - so far it joins string and multivalue string fields (Sorted, SortedSet, 
> Binary), but not Numerics DVs. follow-up LUCENE-5868  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-6647) Add GeoHash String Utilities to core GeoUtils

[Nicholas Knize (JIRA)]

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

Nicholas Knize updated LUCENE-6647:
---
Attachment: LUCENE-6647.patch

bq. can you open a new issue whose sole purpose is to cutover to full 32 bit 
precision for lat/lon?

LUCENE-6710 adds full 32 bit precision decoupling this issue from LUCENE-6704.

Patch attached to make GeoHashUtils bit precision independent. Unit test 
provided.

> Add GeoHash String Utilities to core GeoUtils
> -
>
> Key: LUCENE-6647
> URL: https://issues.apache.org/jira/browse/LUCENE-6647
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Nicholas Knize
> Attachments: LUCENE-6647.patch, LUCENE-6647.patch, LUCENE-6647.patch, 
> LUCENE-6647.patch
>
>
> GeoPointField uses morton encoding to efficiently pack lat/lon values into a 
> single long. GeoHashing effectively does the same thing but uses base 32 
> encoding to represent this long value as a "human readable" string.  Many 
> user applications already use the string representation of the hash. This 
> issue simply adds the base32 string representation of the already computed 
> morton code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-6710) GeoPointField should use full 64 bit encoding

[Nicholas Knize (JIRA)]

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

Nicholas Knize updated LUCENE-6710:
---
Attachment: LUCENE-6710.patch

Patch to use full 64 bit precision for morton encoding, unit test included.

> GeoPointField should use full 64 bit encoding
> -
>
> Key: LUCENE-6710
> URL: https://issues.apache.org/jira/browse/LUCENE-6710
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Nicholas Knize
> Attachments: LUCENE-6710.patch
>
>
> Current GeoPointField uses 31 bits for each lat and long, respectively.  This 
> causes a precision error for the maximum bounds for 2D mapping applications 
> (e.g., instead of maximum of 180, 90 the max value handled is 179.99, 
> 89.99).
> This issue improves precision for the full 2D map boundaries by using the 
> full 32 bit range for lat/lon values, resulting in a morton hash using the 
> full 64 bit range.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (LUCENE-6710) GeoPointField should use full 64 bit encoding

[Nicholas Knize (JIRA)]

Nicholas Knize created LUCENE-6710:
--

 Summary: GeoPointField should use full 64 bit encoding
 Key: LUCENE-6710
 URL: https://issues.apache.org/jira/browse/LUCENE-6710
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Nicholas Knize


Current GeoPointField uses 31 bits for each lat and long, respectively.  This 
causes a precision error for the maximum bounds for 2D mapping applications 
(e.g., instead of maximum of 180, 90 the max value handled is 179.99, 
89.99).

This issue improves precision for the full 2D map boundaries by using the full 
32 bit range for lat/lon values, resulting in a morton hash using the full 64 
bit range.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Understanding performance degradation in range queries between Solr 5.2.1 and 4.10.4

[Tomás Fernández Löbbe]

Hi, I'm seeing some query performance degradation between 4.10.4 and 5.2.1.
It doesn't happen with all the queries, but for queries like range queries
on fields with many different values the average time in 5.2.1 is worse
than in 4.10.4. Is anyone seeing something similar?

Test Details:
* Single thread running queries continuously. I run the test twice for each
Solr version.
* JMeter running on my laptop, Solr running on EC2, on an m3.xlarge
instance with all the defaults but with 5G heap. Index in local disk (SSD)
* Plain Solr releases, nothing custom. Single Solr core, not in SolrCloud
mode, no distributed search.
* "allCountries" geonames dataset (~8M small docs). No updates during the
test. Index Size is around 1.1GB for Solr 5.2.1 and 1.3GB for Solr 4.10.4
(fits entirely in RAM)
* jdk1.8.0_45

Queries: 3k boolean queries (generated with terms from the dataset) with
range queries as filters on "tlongitude" and "tlatitude" fields with
randomly generated bounds, e.g.
q=name:foo OR name:bar&fq=tlongitude:[W TO X]&fq=tlatitude:[Y TO Z]

Fields are:


Field Type:


In this case, Solr 4.10.4 was between 20% to 30% faster than 5.2.1 in
average.

http://snag.gy/2yPPM.jpg

Doing only the boolean queries show no performance difference between 4.10
and 5.2, same thing if I do filters on a string field instead of the range
queries.

When using "double" field type (precisionStep="0"), the difference was
bigger:

longitude/latitude fields:




http://snag.gy/Vi5uk.jpg
I understand this is not the best field type definition for range queries,
I'm just trying to understand the difference between the two versions and
why.

Performance was OK when doing range queries on the "population" field
(long), but that field doesn't have many different values, only 300k out of
the 8.3M docs have the population field with a value different to 0. On the
other hand, doing range queries on the _version_ field did show a graph
similar to the previous one:




http://snag.gy/4tc7e.jpg

Any idea what could be causing this? Is this expected after some known
change?

With Solr 4.10, a single CPU core remains high during the test (close to
100%), but with Solr 5.2, different cores go up and down in utilization
continuously. That's probably because of the different Jetty version I
suppose.
GC pattern looks similar in both. For both Solr versions I'm using the
settings that ship with Solr (in solr.in.sh) except for Xmx and Xms

[jira] [Commented] (SOLR-7850) Move user customization out of solr.in.* scripts

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-7850:


I've now used the install_solr_service script on my dev server.  Overall, I 
think it does a good job, and some of what I initially thought was strange (in 
particular the solr.in.* script), makes much more sense now.

[~thelabdude], I will collect my thoughts and try to present some coherent 
bikeshedding.  I don't expect everyone to agree with my ideas, but I do firmly 
believe that having the conversation is helpful.


> Move user customization out of solr.in.* scripts
> 
>
> Key: SOLR-7850
> URL: https://issues.apache.org/jira/browse/SOLR-7850
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.2.1
>Reporter: Shawn Heisey
>Priority: Minor
>
> I've seen a fair number of users customizing solr.in.* scripts to make 
> changes to their Solr installs.  I think the documentation suggests this, 
> though I haven't confirmed.
> One possible problem with this is that we might make changes in those scripts 
> which such a user would want in their setup, but if they replace the script 
> with the one in the new version, they will lose their customizations.
> I propose instead that we have the startup script look for and utilize a user 
> customization script, in a similar manner to linux init scripts that look for 
> /etc/default/packagename, but are able to function without it.  I'm not 
> entirely sure where the script should live or what it should be called.  One 
> idea is server/etc/userconfig.\{sh,cmd\} ... but I haven't put a lot of 
> thought into it yet.
> If the internal behavior of our scripts is largely replaced by a small java 
> app as detailed in SOLR-7043, then the same thing should apply there -- have 
> a config file for a user to specify settings, but work perfectly if that 
> config file is absent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-5022) PermGen exhausted test failures on Jenkins.

[ASF subversion and git services (JIRA)]

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

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

Commit 1693649 from [~thetaphi] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1693649 ]

SOLR-5022: Limit permgen settings to Hotspot/OpenJDK

> PermGen exhausted test failures on Jenkins.
> ---
>
> Key: SOLR-5022
> URL: https://issues.apache.org/jira/browse/SOLR-5022
> Project: Solr
>  Issue Type: Test
>  Components: Tests
>Reporter: Mark Miller
>Assignee: Uwe Schindler
>Priority: Critical
> Fix For: 5.3
>
> Attachments: SOLR-5022-permgen.patch, SOLR-5022-permgen.patch, 
> SOLR-5022-permgen.patch, SOLR-5022.patch, intern-count-win.txt
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: svn commit: r1693101 - in /lucene/dev/branches/branch_5x: ./ dev-tools/ lucene/ lucene/analysis/common/src/java/org/apache/lucene/analysis/miscellaneous/ lucene/analysis/common/src/java/org/apache

[Mikhail Khludnev]

Oh.. yet another one mess.
Would you mind to check
https://issues.apache.org/jira/secure/attachment/12748235/SOLR-6234-trunk-CHANGES-fix.patch
?

On Fri, Jul 31, 2015 at 9:00 PM, Chris Hostetter 
wrote:

>
> Mikhail: something doesn't make sense about the CHANGES.txt entry for this
> after the merge (I noticed doing a subsequent merge)
>
> On the 5x branch SOLR-6234 is in the "New Features" section of 5.3,
> but on trunk it's in "Other Changes" of 6.0.
>
>
>
> : Date: Tue, 28 Jul 2015 14:44:17 -
> : From: m...@apache.org
> : Reply-To: dev@lucene.apache.org
> : To: comm...@lucene.apache.org
> : Subject: svn commit: r1693101 - in /lucene/dev/branches/branch_5x: ./
> : dev-tools/ lucene/
> :
>  lucene/analysis/common/src/java/org/apache/lucene/analysis/miscellaneous/
> :
>  lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/
> :  lucene/analysis/common/...
> :
> : Author: mkhl
> : Date: Tue Jul 28 14:44:15 2015
> : New Revision: 1693101
> :
> : URL: http://svn.apache.org/r1693101
> : Log:
> : SOLR-6234: Scoring for query time join
> :
> : Added:
> :
>  
> lucene/dev/branches/branch_5x/solr/core/src/java/org/apache/solr/search/ScoreJoinQParserPlugin.java
> :   - copied unchanged from r1693092,
> lucene/dev/trunk/solr/core/src/java/org/apache/solr/search/join/ScoreJoinQParserPlugin.java
> :
>  
> lucene/dev/branches/branch_5x/solr/core/src/test-files/solr/collection1/conf/schema-docValuesJoin.xml
> :   - copied unchanged from r1693092,
> lucene/dev/trunk/solr/core/src/test-files/solr/collection1/conf/schema-docValuesJoin.xml
> :
>  
> lucene/dev/branches/branch_5x/solr/core/src/test/org/apache/solr/TestCrossCoreJoin.java
> :   - copied unchanged from r1693092,
> lucene/dev/trunk/solr/core/src/test/org/apache/solr/TestCrossCoreJoin.java
> :
>  
> lucene/dev/branches/branch_5x/solr/core/src/test/org/apache/solr/search/join/TestScoreJoinQPNoScore.java
> :   - copied unchanged from r1693092,
> lucene/dev/trunk/solr/core/src/test/org/apache/solr/search/join/TestScoreJoinQPNoScore.java
> :
>  
> lucene/dev/branches/branch_5x/solr/core/src/test/org/apache/solr/search/join/TestScoreJoinQPScore.java
> :   - copied unchanged from r1693092,
> lucene/dev/trunk/solr/core/src/test/org/apache/solr/search/join/TestScoreJoinQPScore.java
> : Modified:
> : lucene/dev/branches/branch_5x/   (props changed)
> : lucene/dev/branches/branch_5x/dev-tools/   (props changed)
> : lucene/dev/branches/branch_5x/lucene/   (props changed)
> : lucene/dev/branches/branch_5x/lucene/BUILD.txt   (props changed)
> : lucene/dev/branches/branch_5x/lucene/CHANGES.txt   (props changed)
> : lucene/dev/branches/branch_5x/lucene/JRE_VERSION_MIGRATION.txt
>  (props changed)
> : lucene/dev/branches/branch_5x/lucene/LICENSE.txt   (props changed)
> : lucene/dev/branches/branch_5x/lucene/MIGRATE.txt   (props changed)
> : lucene/dev/branches/branch_5x/lucene/NOTICE.txt   (props changed)
> : lucene/dev/branches/branch_5x/lucene/README.txt   (props changed)
> : lucene/dev/branches/branch_5x/lucene/SYSTEM_REQUIREMENTS.txt
>  (props changed)
> :
>  
> lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/miscellaneous/Lucene47WordDelimiterFilter.java
>  (props changed)
> :
>  
> lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/ASCIITLD.jflex-macro
>  (props changed)
> :
>  
> lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/SUPPLEMENTARY.jflex-macro
>  (props changed)
> :
>  
> lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/StandardTokenizerImpl40.java
>  (props changed)
> :
>  
> lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/StandardTokenizerImpl40.jflex
>  (props changed)
> :
>  
> lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/UAX29URLEmailTokenizerImpl40.java
>  (props changed)
> :
>  
> lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/UAX29URLEmailTokenizerImpl40.jflex
>  (props changed)
> :
>  
> lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/package.html
>  (props changed)
> :
>  
> lucene/dev/branches/branch_5x/lucene/analysis/common/src/test/org/apache/lucene/analysis/miscellaneous/TestLucene47WordDelimiterFilter.java
>  (props changed)
> : lucene/dev/branches/branch_5x/lucene/backward-codecs/   (props
> changed)
> : lucene/dev/branches/branch_5x/lucene/benchmark/   (props changed)
> : lucene/dev/branches/branch_5x/lucene/build.xml   (props changed)
> : lucene/dev/branches/branch_5x/lucene/classification/   (props
> changed)
> : lucene/dev/branches/branch_5x/lucene/classification/build.xml
>  (props changed)
> : luc

[jira] [Updated] (SOLR-6234) Scoring modes for query time join

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-6234:
---
Attachment: SOLR-6234-trunk-CHANGES-fix.patch

[~hossman_luc...@fucit.org] does it make sense?

> Scoring modes for query time join 
> --
>
> Key: SOLR-6234
> URL: https://issues.apache.org/jira/browse/SOLR-6234
> Project: Solr
>  Issue Type: New Feature
>  Components: query parsers
>Affects Versions: 5.3
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>  Labels: features, patch, test
> Fix For: 5.3
>
> Attachments: SOLR-6234-javadocsfix.patch, 
> SOLR-6234-trunk-CHANGES-fix.patch, SOLR-6234.patch, SOLR-6234.patch, 
> SOLR-6234.patch, SOLR-6234.patch, SOLR-6234.patch, SOLR-6234.patch, 
> SOLR-6234.patch, otherHandler.patch
>
>
> it adds ability to call Lucene's JoinUtil by specifying local param, ie  
> \{!join score=...} It supports:
> - {{score=none|avg|max|total}} local param (passed as ScoreMode to JoinUtil)
> - -supports {{b=100}} param to pass {{Query.setBoost()}}- postponed till 
> SOLR-7814.
> - -{{multiVals=true|false}} is introduced- YAGNI, let me know otherwise. 
> - there is a test coverage for cross core join case. 
> - so far it joins string and multivalue string fields (Sorted, SortedSet, 
> Binary), but not Numerics DVs. follow-up LUCENE-5868  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7766) support creation of a coreless collection

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-7766:
---

I think EMPTY is probably the right choice - I was just shooting from the hip 
with none.

> support creation of a coreless collection
> -
>
> Key: SOLR-7766
> URL: https://issues.apache.org/jira/browse/SOLR-7766
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-7766.patch
>
>
> By supplying a deliberately empty create node set (via 
> {{.../solr/admin/collections?action=CREATE&createNodeSet=&name=myCollection&...}})
>  the collection can be created in the usual manner but it will just not yet 
> contain any cores for any of its shards. Later on 
> {{.../solr/admin/collections?wt=json&action=ADDREPLICA&collection=myCollection&...}}
>  calls can create cores as and when and where required.
> github pull request with proposed changes to follow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-7766) support creation of a coreless collection

[Christine Poerschke (JIRA)]

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

Christine Poerschke edited comment on SOLR-7766 at 7/31/15 7:35 PM:


Alrighty, let's go for {{createNodeSet=someSpecialValue}} - i will have a look 
around (on Monday) to see if 'empty' vs. 'EMPTY' vs. 'NONE' there is a 
precedent already, so that for consistency the same could be used here? Thanks 
[~shalinmangar] and [~markrmil...@gmail.com] for your input!

PS: github pull request now updated (still has createNodeSet= though, will be 
updating both code and the newly added test case to use the special value).


was (Author: cpoerschke):
Alrightly, let's go for {{createNodeSet=someSpecialValue}} - i will have a look 
around (on Monday) to see if 'empty' vs. 'EMPTY' vs. 'NONE' there is a 
precedent already, so that for consistency the same could be used here? Thanks 
[~shalinmangar] and [~markrmil...@gmail.com] for your input!

PS: github pull request now updated (still has createNodeSet= though, will be 
updating both code and the newly added test case to use the special value).

> support creation of a coreless collection
> -
>
> Key: SOLR-7766
> URL: https://issues.apache.org/jira/browse/SOLR-7766
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-7766.patch
>
>
> By supplying a deliberately empty create node set (via 
> {{.../solr/admin/collections?action=CREATE&createNodeSet=&name=myCollection&...}})
>  the collection can be created in the usual manner but it will just not yet 
> contain any cores for any of its shards. Later on 
> {{.../solr/admin/collections?wt=json&action=ADDREPLICA&collection=myCollection&...}}
>  calls can create cores as and when and where required.
> github pull request with proposed changes to follow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-5756) A utility API to move collections from internal to external

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-5756:
-
Attachment: (was: SOLR-5756-vs-5.2.1.patch)

> A utility API to move collections from internal to external
> ---
>
> Key: SOLR-5756
> URL: https://issues.apache.org/jira/browse/SOLR-5756
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-5756-vs-5.2.1.patch
>
>
> SOLR-5473 allows creation of collection with state stored outside of 
> clusterstate.json. We would need an API to  move existing 'internal' 
> collections outside



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-5756) A utility API to move collections from internal to external

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-5756:
-
Attachment: SOLR-5756-vs-5.2.1.patch

I think the tests are actually passing now.

> A utility API to move collections from internal to external
> ---
>
> Key: SOLR-5756
> URL: https://issues.apache.org/jira/browse/SOLR-5756
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-5756-vs-5.2.1.patch
>
>
> SOLR-5473 allows creation of collection with state stored outside of 
> clusterstate.json. We would need an API to  move existing 'internal' 
> collections outside



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7766) support creation of a coreless collection

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-7766:
---

Alrightly, let's go for {{createNodeSet=someSpecialValue}} - i will have a look 
around (on Monday) to see if 'empty' vs. 'EMPTY' vs. 'NONE' there is a 
precedent already, so that for consistency the same could be used here? Thanks 
[~shalinmangar] and [~markrmil...@gmail.com] for your input!

PS: github pull request now updated (still has createNodeSet= though, will be 
updating both code and the newly added test case to use the special value).

> support creation of a coreless collection
> -
>
> Key: SOLR-7766
> URL: https://issues.apache.org/jira/browse/SOLR-7766
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-7766.patch
>
>
> By supplying a deliberately empty create node set (via 
> {{.../solr/admin/collections?action=CREATE&createNodeSet=&name=myCollection&...}})
>  the collection can be created in the usual manner but it will just not yet 
> contain any cores for any of its shards. Later on 
> {{.../solr/admin/collections?wt=json&action=ADDREPLICA&collection=myCollection&...}}
>  calls can create cores as and when and where required.
> github pull request with proposed changes to follow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7766) support creation of a coreless collection

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-7766:
---

Consensus reached.

> support creation of a coreless collection
> -
>
> Key: SOLR-7766
> URL: https://issues.apache.org/jira/browse/SOLR-7766
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-7766.patch
>
>
> By supplying a deliberately empty create node set (via 
> {{.../solr/admin/collections?action=CREATE&createNodeSet=&name=myCollection&...}})
>  the collection can be created in the usual manner but it will just not yet 
> contain any cores for any of its shards. Later on 
> {{.../solr/admin/collections?wt=json&action=ADDREPLICA&collection=myCollection&...}}
>  calls can create cores as and when and where required.
> github pull request with proposed changes to follow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7766) support creation of a coreless collection

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-7766:
-

bq. Would a special value e.g. createNodeSet=EMPTY be clearer?

Yeah, createNodeSet=EMPTY or createNodeSet=NONE would be much clearer than an 
empty parameter.

> support creation of a coreless collection
> -
>
> Key: SOLR-7766
> URL: https://issues.apache.org/jira/browse/SOLR-7766
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-7766.patch
>
>
> By supplying a deliberately empty create node set (via 
> {{.../solr/admin/collections?action=CREATE&createNodeSet=&name=myCollection&...}})
>  the collection can be created in the usual manner but it will just not yet 
> contain any cores for any of its shards. Later on 
> {{.../solr/admin/collections?wt=json&action=ADDREPLICA&collection=myCollection&...}}
>  calls can create cores as and when and where required.
> github pull request with proposed changes to follow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7766) support creation of a coreless collection

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-7766:
---

bq. createNodeSet=EMPTY be clearer?

lol - cross post with my edit. I would prefer that to abusing replicationFactor.

> support creation of a coreless collection
> -
>
> Key: SOLR-7766
> URL: https://issues.apache.org/jira/browse/SOLR-7766
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-7766.patch
>
>
> By supplying a deliberately empty create node set (via 
> {{.../solr/admin/collections?action=CREATE&createNodeSet=&name=myCollection&...}})
>  the collection can be created in the usual manner but it will just not yet 
> contain any cores for any of its shards. Later on 
> {{.../solr/admin/collections?wt=json&action=ADDREPLICA&collection=myCollection&...}}
>  calls can create cores as and when and where required.
> github pull request with proposed changes to follow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-7766) support creation of a coreless collection

[Mark Miller (JIRA)]

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

Mark Miller edited comment on SOLR-7766 at 7/31/15 7:23 PM:


bq. API seems very hacky to me.

What's the hack exactly?

* If the issue is really just an empty param (something I don't agree is a 
hack), you could simply have a special keyword of createNodeSet=none.


was (Author: markrmil...@gmail.com):
bq. API seems very hacky to me.

What's the hack exactly?

> support creation of a coreless collection
> -
>
> Key: SOLR-7766
> URL: https://issues.apache.org/jira/browse/SOLR-7766
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-7766.patch
>
>
> By supplying a deliberately empty create node set (via 
> {{.../solr/admin/collections?action=CREATE&createNodeSet=&name=myCollection&...}})
>  the collection can be created in the usual manner but it will just not yet 
> contain any cores for any of its shards. Later on 
> {{.../solr/admin/collections?wt=json&action=ADDREPLICA&collection=myCollection&...}}
>  calls can create cores as and when and where required.
> github pull request with proposed changes to follow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7766) support creation of a coreless collection

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-7766:
---

bq. API seems very hacky to me.

What's the hack exactly?

> support creation of a coreless collection
> -
>
> Key: SOLR-7766
> URL: https://issues.apache.org/jira/browse/SOLR-7766
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-7766.patch
>
>
> By supplying a deliberately empty create node set (via 
> {{.../solr/admin/collections?action=CREATE&createNodeSet=&name=myCollection&...}})
>  the collection can be created in the usual manner but it will just not yet 
> contain any cores for any of its shards. Later on 
> {{.../solr/admin/collections?wt=json&action=ADDREPLICA&collection=myCollection&...}}
>  calls can create cores as and when and where required.
> github pull request with proposed changes to follow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7766) support creation of a coreless collection

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-7766:
---

I agree re: the differentiation between {{createNodeSet}} missing and 
{{createNodeSet=}} present-and-empty is very subtle. Would a special value e.g. 
{{createNodeSet=EMPTY}} be clearer?

The way i read 
[OverseerCollectionProcessor.java|https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/cloud/OverseerCollectionProcessor.java]
 line 2233 currently an empty parameter would result in an error, right? [Draft 
Collections API 
docs|https://cwiki.apache.org/confluence/display/solr/Collections+API?src=search]
 list 'empty' as the default though (should it be 'blank box' as for 'async'?).

Will update github pull request against latest trunk (with createNodeSet=) 
shortly and definitely hold off on any commits until agreement on how to 
request coreless collection creation is reached.

> support creation of a coreless collection
> -
>
> Key: SOLR-7766
> URL: https://issues.apache.org/jira/browse/SOLR-7766
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-7766.patch
>
>
> By supplying a deliberately empty create node set (via 
> {{.../solr/admin/collections?action=CREATE&createNodeSet=&name=myCollection&...}})
>  the collection can be created in the usual manner but it will just not yet 
> contain any cores for any of its shards. Later on 
> {{.../solr/admin/collections?wt=json&action=ADDREPLICA&collection=myCollection&...}}
>  calls can create cores as and when and where required.
> github pull request with proposed changes to follow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-7766) support creation of a coreless collection

[Mark Miller (JIRA)]

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

Mark Miller edited comment on SOLR-7766 at 7/31/15 7:17 PM:


No, I know you can change it.

It simply doesn't make sense to me like I said. You are not asking for a target 
replication factor of 0. You are asking that no nodes get a core. Having an 
empty createNodeSet matches the intent much more than messing with replication 
factor.


was (Author: markrmil...@gmail.com):
No, I know you can change it.

It simply doesn't make sense to me like you I said. You are not asking for a 
target replication factor of 0. You are asking that no nodes get a core. Having 
an empty createNodeSet matches the intent much more than messing with 
replication factor.

> support creation of a coreless collection
> -
>
> Key: SOLR-7766
> URL: https://issues.apache.org/jira/browse/SOLR-7766
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-7766.patch
>
>
> By supplying a deliberately empty create node set (via 
> {{.../solr/admin/collections?action=CREATE&createNodeSet=&name=myCollection&...}})
>  the collection can be created in the usual manner but it will just not yet 
> contain any cores for any of its shards. Later on 
> {{.../solr/admin/collections?wt=json&action=ADDREPLICA&collection=myCollection&...}}
>  calls can create cores as and when and where required.
> github pull request with proposed changes to follow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-7819) ZkController.ensureReplicaInLeaderInitiatedRecovery does not respect retryOnConnLoss

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-7819:

Attachment: SOLR-7819.patch

This patch moves all LIR related activity inside the LIR thread. The LIR thread 
now publishes LIR state, publishes node state and then starts a recovery loop 
depending on whether LIR state was published successfully or if it failed 
because of session expiry or connection loss. The indexing thread only consults 
the local replica map to ensure that only 1 LIR thread is started for any given 
replica. This ensures that the indexing thread never needs to wait for ZK 
operations needed for LIR. All tests pass except for 
HttpPartitionTest.testLeaderInitiatedRecoveryCRUD whose assumptions about the 
LIR workflow are no longer correct.

Still running more tests.

> ZkController.ensureReplicaInLeaderInitiatedRecovery does not respect 
> retryOnConnLoss
> 
>
> Key: SOLR-7819
> URL: https://issues.apache.org/jira/browse/SOLR-7819
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.2, 5.2.1
>Reporter: Shalin Shekhar Mangar
>  Labels: Jepsen
> Fix For: 5.3, Trunk
>
> Attachments: SOLR-7819.patch, SOLR-7819.patch
>
>
> SOLR-7245 added a retryOnConnLoss parameter to 
> ZkController.ensureReplicaInLeaderInitiatedRecovery so that indexing threads 
> do not hang during a partition on ZK operations. However, some of those 
> changes were unintentionally reverted by SOLR-7336 in 5.2.
> I found this while running Jepsen tests on 5.2.1 where a hung update managed 
> to put a leader into a 'down' state (I'm still investigating and will open a 
> separate issue about this problem).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7766) support creation of a coreless collection

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-7766:
---

No, I know you can change it.

It simply doesn't make sense to me like you I said. You are not asking for a 
target replication factor of 0. You are asking that no nodes get a core. Having 
an empty createNodeSet matches the intent much more than messing with 
replication factor.

> support creation of a coreless collection
> -
>
> Key: SOLR-7766
> URL: https://issues.apache.org/jira/browse/SOLR-7766
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-7766.patch
>
>
> By supplying a deliberately empty create node set (via 
> {{.../solr/admin/collections?action=CREATE&createNodeSet=&name=myCollection&...}})
>  the collection can be created in the usual manner but it will just not yet 
> contain any cores for any of its shards. Later on 
> {{.../solr/admin/collections?wt=json&action=ADDREPLICA&collection=myCollection&...}}
>  calls can create cores as and when and where required.
> github pull request with proposed changes to follow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7766) support creation of a coreless collection

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-7766:
-

bq. replicationFactor can also be used as a target for things like 
autoAddReplicas. I think the empty createNodeSet makes a lot more sense.

You forget that we now have a modify collection API which lets you change the 
replication factor among other things. Specifying an empty parameter to change 
the behavior of an API seems very hacky to me. An empty parameter should either 
have no effect or it should result in an error.

> support creation of a coreless collection
> -
>
> Key: SOLR-7766
> URL: https://issues.apache.org/jira/browse/SOLR-7766
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-7766.patch
>
>
> By supplying a deliberately empty create node set (via 
> {{.../solr/admin/collections?action=CREATE&createNodeSet=&name=myCollection&...}})
>  the collection can be created in the usual manner but it will just not yet 
> contain any cores for any of its shards. Later on 
> {{.../solr/admin/collections?wt=json&action=ADDREPLICA&collection=myCollection&...}}
>  calls can create cores as and when and where required.
> github pull request with proposed changes to follow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7766) support creation of a coreless collection

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-7766:
---

replicationFactor can also be used as a target for things like autoAddReplicas. 
I think the empty createNodeSet makes a lot more sense.

> support creation of a coreless collection
> -
>
> Key: SOLR-7766
> URL: https://issues.apache.org/jira/browse/SOLR-7766
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-7766.patch
>
>
> By supplying a deliberately empty create node set (via 
> {{.../solr/admin/collections?action=CREATE&createNodeSet=&name=myCollection&...}})
>  the collection can be created in the usual manner but it will just not yet 
> contain any cores for any of its shards. Later on 
> {{.../solr/admin/collections?wt=json&action=ADDREPLICA&collection=myCollection&...}}
>  calls can create cores as and when and where required.
> github pull request with proposed changes to follow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7766) support creation of a coreless collection

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-7766:
-

How about replicationFactor=0 instead of an empty createNodeSet parameter?

> support creation of a coreless collection
> -
>
> Key: SOLR-7766
> URL: https://issues.apache.org/jira/browse/SOLR-7766
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-7766.patch
>
>
> By supplying a deliberately empty create node set (via 
> {{.../solr/admin/collections?action=CREATE&createNodeSet=&name=myCollection&...}})
>  the collection can be created in the usual manner but it will just not yet 
> contain any cores for any of its shards. Later on 
> {{.../solr/admin/collections?wt=json&action=ADDREPLICA&collection=myCollection&...}}
>  calls can create cores as and when and where required.
> github pull request with proposed changes to follow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7854) Remove ZkStateReader.updateClusterState(false)

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-7854:
---

updateClusterState(false) use to be used a lot to prevent silly rapid updates 
faster than was useful. Long ago, someone removed it's use but never cleaned it 
up fully.

> Remove ZkStateReader.updateClusterState(false)
> --
>
> Key: SOLR-7854
> URL: https://issues.apache.org/jira/browse/SOLR-7854
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.2.1
>Reporter: Scott Blum
>Priority: Minor
>  Labels: easyfix, newbie
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> `updateClusterState(false)` as far as I can tell has zero callers.  It's 
> super pointless anyway, because `updateClusterState(true)` is being used 
> mostly from test code and in places where someone is trying to force a reload 
> from ZK (for whatever reason).  There's no point in asking for a deferred 
> update when ZkStateReader is already going to keep itself in sync anyway.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-7854) Remove ZkStateReader.updateClusterState(false)

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-7854:
-
Description: 
`updateClusterState(false)` as far as I can tell has zero callers.  It's super 
pointless anyway, because `updateClusterState(true)` is being used mostly from 
test code and in places where someone is trying to force a reload from ZK (for 
whatever reason).  There's no point in asking for a deferred update when 
ZkStateReader is already going to keep itself in sync anyway.


  was:
`updateClusterState(false)` as I can tell has zero callers.  It's super 
pointless anyway, because `updateClusterState(true)` is being used mostly from 
test code and in places where someone is trying to force a reload from ZK (for 
whatever reason).  There's no point in asking for a deferred update when 
ZkStateReader is already going to keep itself in sync anyway.



> Remove ZkStateReader.updateClusterState(false)
> --
>
> Key: SOLR-7854
> URL: https://issues.apache.org/jira/browse/SOLR-7854
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.2.1
>Reporter: Scott Blum
>Priority: Minor
>  Labels: easyfix, newbie
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> `updateClusterState(false)` as far as I can tell has zero callers.  It's 
> super pointless anyway, because `updateClusterState(true)` is being used 
> mostly from test code and in places where someone is trying to force a reload 
> from ZK (for whatever reason).  There's no point in asking for a deferred 
> update when ZkStateReader is already going to keep itself in sync anyway.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-7854) Remove ZkStateReader.updateClusterState(false)

[Scott Blum (JIRA)]

Scott Blum created SOLR-7854:


 Summary: Remove ZkStateReader.updateClusterState(false)
 Key: SOLR-7854
 URL: https://issues.apache.org/jira/browse/SOLR-7854
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Affects Versions: 5.2.1
Reporter: Scott Blum
Priority: Minor


`updateClusterState(false)` as I can tell has zero callers.  It's super 
pointless anyway, because `updateClusterState(true)` is being used mostly from 
test code and in places where someone is trying to force a reload from ZK (for 
whatever reason).  There's no point in asking for a deferred update when 
ZkStateReader is already going to keep itself in sync anyway.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: cwiki.apache.org edit right for cpoerschke

[Steve Rowe]

Okay, I’ve added permissions for you, so you should now be able to edit. - Steve

> On Jul 31, 2015, at 2:00 PM, Christine Poerschke (BLOOMBERG/ LONDON) 
>  wrote:
> 
> Hi Steve,
> 
> oops, apologies, my mistake, created myself a Confluence account now.
> 
> Thanks,
> Christine
> 
> - Original Message -
> From: sar...@gmail.com
> To: Christine Poerschke (BLOOMBERG/ LONDON), dev@lucene.apache.org
> At: Jul 31 2015 18:47:42
> 
> Hi Christine,
> 
> I would have added you when I added Mikhail, but autocomplete doesn’t turn up 
> anything when trying to add permission for you.  Do you have a Confluence 
> account?  If not, go here and make one: 
>  and then let us know what 
> it is.  If you already have a Confluence account, what is it?
> 
> Steve
> www.lucidworks.com
> 
>> On Jul 31, 2015, at 1:30 PM, Christine Poerschke (BLOOMBERG/ LONDON) 
>>  wrote:
>> 
>> Hi,
>> 
>> Could i be added also please? This would initially just be for updating 
>> https://cwiki.apache.org/confluence/display/solr/Collections+API?src=search 
>> w.r.t. https://issues.apache.org/jira/i#browse/SOLR-7766 when that is 
>> committed (hopefully early next week).
>> 
>> Thanks,
>> Christine
>> 
>> From: dev@lucene.apache.org At: Jul 30 2015 20:43:12
>> To: dev@lucene.apache.org
>> Subject: Re:cwiki.a.org edit right for mkhludnev
>> Hello,
>> Would you let mkhludnev (not mkhl) to edit 
>> https://cwiki.apache.org/confluence/display/solr/Apache+Solr+Reference+Guide 
>> ? 
>> Thanks!
>> 
>> -- 
>> Sincerely yours
>> Mikhail Khludnev
>> Principal Engineer,
>> Grid Dynamics
>> 
>> 
> 
> 


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

[jira] [Updated] (SOLR-5756) A utility API to move collections from internal to external

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-5756:
-
Attachment: (was: SOLR-5756-vs-5.2.1.patch)

> A utility API to move collections from internal to external
> ---
>
> Key: SOLR-5756
> URL: https://issues.apache.org/jira/browse/SOLR-5756
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-5756-vs-5.2.1.patch
>
>
> SOLR-5473 allows creation of collection with state stored outside of 
> clusterstate.json. We would need an API to  move existing 'internal' 
> collections outside



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-5756) A utility API to move collections from internal to external

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-5756:
-
Attachment: SOLR-5756-vs-5.2.1.patch

(more bugfixes... will tests pass?)

> A utility API to move collections from internal to external
> ---
>
> Key: SOLR-5756
> URL: https://issues.apache.org/jira/browse/SOLR-5756
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-5756-vs-5.2.1.patch
>
>
> SOLR-5473 allows creation of collection with state stored outside of 
> clusterstate.json. We would need an API to  move existing 'internal' 
> collections outside



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_51) - Build # 5088 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5088/
Java: 32bit/jdk1.8.0_51 -client -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.lucene.store.TestNativeFSLockFactory.testStressLocks

Error Message:
Captured an uncaught exception in thread: Thread[id=1702, name=Thread-1267, 
state=RUNNABLE, group=TGRP-TestNativeFSLockFactory]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=1702, name=Thread-1267, state=RUNNABLE, 
group=TGRP-TestNativeFSLockFactory]
at 
__randomizedtesting.SeedInfo.seed([732AB104B012668E:2D1BFFF9ACBEAEE8]:0)
Caused by: java.lang.AssertionError: hit unexpected NoSuchFileException: 
file=_o.cfs
at __randomizedtesting.SeedInfo.seed([732AB104B012668E]:0)
at 
org.apache.lucene.index.IndexFileDeleter.deleteFile(IndexFileDeleter.java:750)
at 
org.apache.lucene.index.IndexFileDeleter.deletePendingFiles(IndexFileDeleter.java:528)
at 
org.apache.lucene.index.IndexFileDeleter.decRef(IndexFileDeleter.java:636)
at 
org.apache.lucene.index.IndexFileDeleter.close(IndexFileDeleter.java:470)
at 
org.apache.lucene.index.IndexWriter.rollbackInternal(IndexWriter.java:2080)
at org.apache.lucene.index.IndexWriter.shutdown(IndexWriter.java:1067)
at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1109)
at 
org.apache.lucene.store.BaseLockFactoryTestCase$WriterThread.run(BaseLockFactoryTestCase.java:221)




Build Log:
[...truncated 1685 lines...]
   [junit4] Suite: org.apache.lucene.store.TestNativeFSLockFactory
   [junit4]   2> jul 31, 2015 10:32:17 PM 
com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
 uncaughtException
   [junit4]   2> WARNING: Uncaught exception in thread: 
Thread[Thread-1267,5,TGRP-TestNativeFSLockFactory]
   [junit4]   2> java.lang.AssertionError: hit unexpected NoSuchFileException: 
file=_o.cfs
   [junit4]   2>at 
__randomizedtesting.SeedInfo.seed([732AB104B012668E]:0)
   [junit4]   2>at 
org.apache.lucene.index.IndexFileDeleter.deleteFile(IndexFileDeleter.java:750)
   [junit4]   2>at 
org.apache.lucene.index.IndexFileDeleter.deletePendingFiles(IndexFileDeleter.java:528)
   [junit4]   2>at 
org.apache.lucene.index.IndexFileDeleter.decRef(IndexFileDeleter.java:636)
   [junit4]   2>at 
org.apache.lucene.index.IndexFileDeleter.close(IndexFileDeleter.java:470)
   [junit4]   2>at 
org.apache.lucene.index.IndexWriter.rollbackInternal(IndexWriter.java:2080)
   [junit4]   2>at 
org.apache.lucene.index.IndexWriter.shutdown(IndexWriter.java:1067)
   [junit4]   2>at 
org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1109)
   [junit4]   2>at 
org.apache.lucene.store.BaseLockFactoryTestCase$WriterThread.run(BaseLockFactoryTestCase.java:221)
   [junit4]   2> 
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestNativeFSLockFactory -Dtests.method=testStressLocks 
-Dtests.seed=732AB104B012668E -Dtests.slow=true -Dtests.locale=sr_ME_#Latn 
-Dtests.timezone=Asia/Tehran -Dtests.asserts=true -Dtests.file.encoding=Cp1252
   [junit4] ERROR   2.18s J1 | TestNativeFSLockFactory.testStressLocks <<<
   [junit4]> Throwable #1: 
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=1702, name=Thread-1267, state=RUNNABLE, 
group=TGRP-TestNativeFSLockFactory]
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([732AB104B012668E:2D1BFFF9ACBEAEE8]:0)
   [junit4]> Caused by: java.lang.AssertionError: hit unexpected 
NoSuchFileException: file=_o.cfs
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([732AB104B012668E]:0)
   [junit4]>at 
org.apache.lucene.index.IndexFileDeleter.deleteFile(IndexFileDeleter.java:750)
   [junit4]>at 
org.apache.lucene.index.IndexFileDeleter.deletePendingFiles(IndexFileDeleter.java:528)
   [junit4]>at 
org.apache.lucene.index.IndexFileDeleter.decRef(IndexFileDeleter.java:636)
   [junit4]>at 
org.apache.lucene.index.IndexFileDeleter.close(IndexFileDeleter.java:470)
   [junit4]>at 
org.apache.lucene.index.IndexWriter.rollbackInternal(IndexWriter.java:2080)
   [junit4]>at 
org.apache.lucene.index.IndexWriter.shutdown(IndexWriter.java:1067)
   [junit4]>at 
org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1109)
   [junit4]>at 
org.apache.lucene.store.BaseLockFactoryTestCase$WriterThread.run(BaseLockFactoryTestCase.java:221)
   [junit4] IGNOR/A 0.01s J1 | TestNativeFSLockFactory.testDeleteLockFile
   [junit4]> Assumption #1: test requires the ability to delete a locked 
file(throwable: java.io.IOException: cannot delete file: test.lock, a virus 
scanner has it open)
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene53): 
{content=FSTOrd50}, docValues:{}, sim=DefaultSimilarity, loca

Re: cwiki.apache.org edit right for cpoerschke

[Christine Poerschke (BLOOMBERG/ LONDON)]

Hi Steve,

oops, apologies, my mistake, created myself a Confluence account now.

Thanks,
Christine

- Original Message -
From: sar...@gmail.com
To: Christine Poerschke (BLOOMBERG/ LONDON), dev@lucene.apache.org
At: Jul 31 2015 18:47:42

Hi Christine,

I would have added you when I added Mikhail, but autocomplete doesn’t turn up 
anything when trying to add permission for you.  Do you have a Confluence 
account?  If not, go here and make one: 
 and then let us know what 
it is.  If you already have a Confluence account, what is it?

Steve
www.lucidworks.com

> On Jul 31, 2015, at 1:30 PM, Christine Poerschke (BLOOMBERG/ LONDON) 
>  wrote:
> 
> Hi,
> 
> Could i be added also please? This would initially just be for updating 
> https://cwiki.apache.org/confluence/display/solr/Collections+API?src=search 
> w.r.t. https://issues.apache.org/jira/i#browse/SOLR-7766 when that is 
> committed (hopefully early next week).
> 
> Thanks,
> Christine
> 
> From: dev@lucene.apache.org At: Jul 30 2015 20:43:12
> To: dev@lucene.apache.org
> Subject: Re:cwiki.a.org edit right for mkhludnev
> Hello,
> Would you let mkhludnev (not mkhl) to edit 
> https://cwiki.apache.org/confluence/display/solr/Apache+Solr+Reference+Guide 
> ? 
> Thanks!
> 
> -- 
> Sincerely yours
> Mikhail Khludnev
> Principal Engineer,
> Grid Dynamics
> 
> 



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

Re: svn commit: r1693101 - in /lucene/dev/branches/branch_5x: ./ dev-tools/ lucene/ lucene/analysis/common/src/java/org/apache/lucene/analysis/miscellaneous/ lucene/analysis/common/src/java/org/apache

[Chris Hostetter]

Mikhail: something doesn't make sense about the CHANGES.txt entry for this 
after the merge (I noticed doing a subsequent merge)

On the 5x branch SOLR-6234 is in the "New Features" section of 5.3,
but on trunk it's in "Other Changes" of 6.0.



: Date: Tue, 28 Jul 2015 14:44:17 -
: From: m...@apache.org
: Reply-To: dev@lucene.apache.org
: To: comm...@lucene.apache.org
: Subject: svn commit: r1693101 - in /lucene/dev/branches/branch_5x: ./
: dev-tools/ lucene/
: lucene/analysis/common/src/java/org/apache/lucene/analysis/miscellaneous/
: lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/
:  lucene/analysis/common/...
: 
: Author: mkhl
: Date: Tue Jul 28 14:44:15 2015
: New Revision: 1693101
: 
: URL: http://svn.apache.org/r1693101
: Log:
: SOLR-6234: Scoring for query time join
: 
: Added:
: 
lucene/dev/branches/branch_5x/solr/core/src/java/org/apache/solr/search/ScoreJoinQParserPlugin.java
:   - copied unchanged from r1693092, 
lucene/dev/trunk/solr/core/src/java/org/apache/solr/search/join/ScoreJoinQParserPlugin.java
: 
lucene/dev/branches/branch_5x/solr/core/src/test-files/solr/collection1/conf/schema-docValuesJoin.xml
:   - copied unchanged from r1693092, 
lucene/dev/trunk/solr/core/src/test-files/solr/collection1/conf/schema-docValuesJoin.xml
: 
lucene/dev/branches/branch_5x/solr/core/src/test/org/apache/solr/TestCrossCoreJoin.java
:   - copied unchanged from r1693092, 
lucene/dev/trunk/solr/core/src/test/org/apache/solr/TestCrossCoreJoin.java
: 
lucene/dev/branches/branch_5x/solr/core/src/test/org/apache/solr/search/join/TestScoreJoinQPNoScore.java
:   - copied unchanged from r1693092, 
lucene/dev/trunk/solr/core/src/test/org/apache/solr/search/join/TestScoreJoinQPNoScore.java
: 
lucene/dev/branches/branch_5x/solr/core/src/test/org/apache/solr/search/join/TestScoreJoinQPScore.java
:   - copied unchanged from r1693092, 
lucene/dev/trunk/solr/core/src/test/org/apache/solr/search/join/TestScoreJoinQPScore.java
: Modified:
: lucene/dev/branches/branch_5x/   (props changed)
: lucene/dev/branches/branch_5x/dev-tools/   (props changed)
: lucene/dev/branches/branch_5x/lucene/   (props changed)
: lucene/dev/branches/branch_5x/lucene/BUILD.txt   (props changed)
: lucene/dev/branches/branch_5x/lucene/CHANGES.txt   (props changed)
: lucene/dev/branches/branch_5x/lucene/JRE_VERSION_MIGRATION.txt   (props 
changed)
: lucene/dev/branches/branch_5x/lucene/LICENSE.txt   (props changed)
: lucene/dev/branches/branch_5x/lucene/MIGRATE.txt   (props changed)
: lucene/dev/branches/branch_5x/lucene/NOTICE.txt   (props changed)
: lucene/dev/branches/branch_5x/lucene/README.txt   (props changed)
: lucene/dev/branches/branch_5x/lucene/SYSTEM_REQUIREMENTS.txt   (props 
changed)
: 
lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/miscellaneous/Lucene47WordDelimiterFilter.java
   (props changed)
: 
lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/ASCIITLD.jflex-macro
   (props changed)
: 
lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/SUPPLEMENTARY.jflex-macro
   (props changed)
: 
lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/StandardTokenizerImpl40.java
   (props changed)
: 
lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/StandardTokenizerImpl40.jflex
   (props changed)
: 
lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/UAX29URLEmailTokenizerImpl40.java
   (props changed)
: 
lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/UAX29URLEmailTokenizerImpl40.jflex
   (props changed)
: 
lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/package.html
   (props changed)
: 
lucene/dev/branches/branch_5x/lucene/analysis/common/src/test/org/apache/lucene/analysis/miscellaneous/TestLucene47WordDelimiterFilter.java
   (props changed)
: lucene/dev/branches/branch_5x/lucene/backward-codecs/   (props changed)
: lucene/dev/branches/branch_5x/lucene/benchmark/   (props changed)
: lucene/dev/branches/branch_5x/lucene/build.xml   (props changed)
: lucene/dev/branches/branch_5x/lucene/classification/   (props changed)
: lucene/dev/branches/branch_5x/lucene/classification/build.xml   (props 
changed)
: lucene/dev/branches/branch_5x/lucene/classification/ivy.xml   (props 
changed)
: lucene/dev/branches/branch_5x/lucene/classification/src/   (props changed)
: lucene/dev/branches/branch_5x/lucene/codecs/   (props changed)
: lucene/dev/branches/branch_5x/lucene/common-build.xml   (props changed)
: lucene/dev/branches/branch_5x/lucene

Re: cwiki.apache.org edit right for cpoerschke

[Steve Rowe]

Hi Christine,

I would have added you when I added Mikhail, but autocomplete doesn’t turn up 
anything when trying to add permission for you.  Do you have a Confluence 
account?  If not, go here and make one: 
 and then let us know what 
it is.  If you already have a Confluence account, what is it?

Steve
www.lucidworks.com

> On Jul 31, 2015, at 1:30 PM, Christine Poerschke (BLOOMBERG/ LONDON) 
>  wrote:
> 
> Hi,
> 
> Could i be added also please? This would initially just be for updating 
> https://cwiki.apache.org/confluence/display/solr/Collections+API?src=search 
> w.r.t. https://issues.apache.org/jira/i#browse/SOLR-7766 when that is 
> committed (hopefully early next week).
> 
> Thanks,
> Christine
> 
> From: dev@lucene.apache.org At: Jul 30 2015 20:43:12
> To: dev@lucene.apache.org
> Subject: Re:cwiki.a.org edit right for mkhludnev
> Hello,
> Would you let mkhludnev (not mkhl) to edit 
> https://cwiki.apache.org/confluence/display/solr/Apache+Solr+Reference+Guide 
> ? 
> Thanks!
> 
> -- 
> Sincerely yours
> Mikhail Khludnev
> Principal Engineer,
> Grid Dynamics
> 
> 


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

cwiki.apache.org edit right for cpoerschke

[Christine Poerschke (BLOOMBERG/ LONDON)]

Hi,

Could i be added also please? This would initially just be for updating 
https://cwiki.apache.org/confluence/display/solr/Collections+API?src=search 
w.r.t. https://issues.apache.org/jira/i#browse/SOLR-7766 when that is committed 
(hopefully early next week).

Thanks,
Christine

From: dev@lucene.apache.org At: Jul 30 2015 20:43:12
To: dev@lucene.apache.org
Subject: Re:cwiki.a.org edit right for mkhludnev

Hello,
Would you let mkhludnev (not mkhl) to edit 
https://cwiki.apache.org/confluence/display/solr/Apache+Solr+Reference+Guide ? 
Thanks!

-- 
Sincerely yours
Mikhail Khludnev
Principal Engineer,
Grid Dynamics

[jira] [Updated] (SOLR-5756) A utility API to move collections from internal to external

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-5756:
-
Attachment: (was: SOLR-5756-vs-5.2.1.patch)

> A utility API to move collections from internal to external
> ---
>
> Key: SOLR-5756
> URL: https://issues.apache.org/jira/browse/SOLR-5756
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-5756-vs-5.2.1.patch
>
>
> SOLR-5473 allows creation of collection with state stored outside of 
> clusterstate.json. We would need an API to  move existing 'internal' 
> collections outside



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7766) support creation of a coreless collection

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-7766:
---

Rebasing patch against latest trunk (to include SOLR-7823 changes), existing 
patch fails {{async=...}} tests.

> support creation of a coreless collection
> -
>
> Key: SOLR-7766
> URL: https://issues.apache.org/jira/browse/SOLR-7766
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-7766.patch
>
>
> By supplying a deliberately empty create node set (via 
> {{.../solr/admin/collections?action=CREATE&createNodeSet=&name=myCollection&...}})
>  the collection can be created in the usual manner but it will just not yet 
> contain any cores for any of its shards. Later on 
> {{.../solr/admin/collections?wt=json&action=ADDREPLICA&collection=myCollection&...}}
>  calls can create cores as and when and where required.
> github pull request with proposed changes to follow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Assigned] (SOLR-7766) support creation of a coreless collection

[Christine Poerschke (JIRA)]

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

Christine Poerschke reassigned SOLR-7766:
-

Assignee: Christine Poerschke  (was: Ramkumar Aiyengar)

> support creation of a coreless collection
> -
>
> Key: SOLR-7766
> URL: https://issues.apache.org/jira/browse/SOLR-7766
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-7766.patch
>
>
> By supplying a deliberately empty create node set (via 
> {{.../solr/admin/collections?action=CREATE&createNodeSet=&name=myCollection&...}})
>  the collection can be created in the usual manner but it will just not yet 
> contain any cores for any of its shards. Later on 
> {{.../solr/admin/collections?wt=json&action=ADDREPLICA&collection=myCollection&...}}
>  calls can create cores as and when and where required.
> github pull request with proposed changes to follow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-5756) A utility API to move collections from internal to external

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-5756:
-
Attachment: SOLR-5756-vs-5.2.1.patch

(couple of comments and fixed one thing)

> A utility API to move collections from internal to external
> ---
>
> Key: SOLR-5756
> URL: https://issues.apache.org/jira/browse/SOLR-5756
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-5756-vs-5.2.1.patch, SOLR-5756-vs-5.2.1.patch
>
>
> SOLR-5473 allows creation of collection with state stored outside of 
> clusterstate.json. We would need an API to  move existing 'internal' 
> collections outside



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6234) Scoring modes for query time join

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-6234:
-

[~mkhludnev]. First, thanks so much for proactively updating the Ref Guide with 
your changes.  

I hope you don't mind too much, but I modified your text in a few ways:

* The online version of the Ref Guide is always for the upcoming release of 
Solr, and as such we don't spend a lot of time describing how features used to 
work. While I understand that causes some confusion from time-to-time, a major 
problem with the old Solr Wiki was the attempt to maintain documentation for 
older versions of Solr along with the changes along the way. Personally, I find 
no harm mentioning when a feature was introduced, but at that point our 
convention is to remove documentation for the old behavior (unless, of course, 
the section is describing how to migrate to the new behavior).
* With this general guideline, on the Uploading Data with Index Handlers page I 
flipped the emphasis to note the need to use the score parameter when deleting 
with the Join QP to avoid the error, and omitted the reference to 5.3 because 
the guide is for 5.3 already, and the section we're pointing to says the param 
was introduced in 5.3.
* I re-worded the text a bit to provide more context for a less-expert user.
* Standardized phrasings - i.e., "plain Solr" is usually referred to as 
"standalone Solr".

> Scoring modes for query time join 
> --
>
> Key: SOLR-6234
> URL: https://issues.apache.org/jira/browse/SOLR-6234
> Project: Solr
>  Issue Type: New Feature
>  Components: query parsers
>Affects Versions: 5.3
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>  Labels: features, patch, test
> Fix For: 5.3
>
> Attachments: SOLR-6234-javadocsfix.patch, SOLR-6234.patch, 
> SOLR-6234.patch, SOLR-6234.patch, SOLR-6234.patch, SOLR-6234.patch, 
> SOLR-6234.patch, SOLR-6234.patch, otherHandler.patch
>
>
> it adds ability to call Lucene's JoinUtil by specifying local param, ie  
> \{!join score=...} It supports:
> - {{score=none|avg|max|total}} local param (passed as ScoreMode to JoinUtil)
> - -supports {{b=100}} param to pass {{Query.setBoost()}}- postponed till 
> SOLR-7814.
> - -{{multiVals=true|false}} is introduced- YAGNI, let me know otherwise. 
> - there is a test coverage for cross core join case. 
> - so far it joins string and multivalue string fields (Sorted, SortedSet, 
> Binary), but not Numerics DVs. follow-up LUCENE-5868  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-6234) Scoring modes for query time join

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev resolved SOLR-6234.

Resolution: Fixed

> Scoring modes for query time join 
> --
>
> Key: SOLR-6234
> URL: https://issues.apache.org/jira/browse/SOLR-6234
> Project: Solr
>  Issue Type: New Feature
>  Components: query parsers
>Affects Versions: 5.3
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>  Labels: features, patch, test
> Fix For: 5.3
>
> Attachments: SOLR-6234-javadocsfix.patch, SOLR-6234.patch, 
> SOLR-6234.patch, SOLR-6234.patch, SOLR-6234.patch, SOLR-6234.patch, 
> SOLR-6234.patch, SOLR-6234.patch, otherHandler.patch
>
>
> it adds ability to call Lucene's JoinUtil by specifying local param, ie  
> \{!join score=...} It supports:
> - {{score=none|avg|max|total}} local param (passed as ScoreMode to JoinUtil)
> - -supports {{b=100}} param to pass {{Query.setBoost()}}- postponed till 
> SOLR-7814.
> - -{{multiVals=true|false}} is introduced- YAGNI, let me know otherwise. 
> - there is a test coverage for cross core join case. 
> - so far it joins string and multivalue string fields (Sorted, SortedSet, 
> Binary), but not Numerics DVs. follow-up LUCENE-5868  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Closed] (SOLR-5662) {!parent} parser with scoreMode

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev closed SOLR-5662.
--
Resolution: Duplicate

address it at SOLR-5882

> {!parent} parser with scoreMode
> ---
>
> Key: SOLR-5662
> URL: https://issues.apache.org/jira/browse/SOLR-5662
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 4.5, 4.6
>Reporter: Moritz Munte
>Priority: Minor
>
> ToParentBlockJoinQuery has support for different score modes, but {!parent} 
> parser has "None" mode hardcoded without an option to change it.
> It would be usefull if there is a parameter to change the score mode or set a 
> reasonable default.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-5756) A utility API to move collections from internal to external

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-5756:
-
Attachment: SOLR-5756-vs-5.2.1.patch

Initial stab at something working, based on 5.2.1.  Haven't run through test 
suite yet.

> A utility API to move collections from internal to external
> ---
>
> Key: SOLR-5756
> URL: https://issues.apache.org/jira/browse/SOLR-5756
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-5756-vs-5.2.1.patch
>
>
> SOLR-5473 allows creation of collection with state stored outside of 
> clusterstate.json. We would need an API to  move existing 'internal' 
> collections outside



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5868) JoinUtil support for NUMERIC docValues fields

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on LUCENE-5868:
--

[~mschipperheyn] what's your usecase? why you can't use SORTED? do you need to 
join cross cores? Have you had a look at OrdinalMap join?

> JoinUtil support for NUMERIC docValues fields 
> --
>
> Key: LUCENE-5868
> URL: https://issues.apache.org/jira/browse/LUCENE-5868
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Minor
>
> while polishing SOLR-6234 I found that JoinUtil can't join int dv fields at 
> least. 
> I plan to provide test/patch. It might be important, because Solr's join can 
> do that. Please vote if you care! 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-2522) add syntax for selecting the min or max of a multivalued field in value source functions

[Hoss Man (JIRA)]

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

Hoss Man resolved SOLR-2522.

   Resolution: Fixed
Fix Version/s: Trunk
   5.3

> add syntax for selecting the min or max of a multivalued field in value 
> source functions
> 
>
> Key: SOLR-2522
> URL: https://issues.apache.org/jira/browse/SOLR-2522
> Project: Solr
>  Issue Type: Improvement
>Reporter: Bill Bell
>Assignee: Hoss Man
> Fix For: 5.3, Trunk
>
> Attachments: SOLR-2522.patch, SOLR-2522.patch, SOLR-2522.patch
>
>
> Initial request...
> bq. Switch max() and min() functions to work on multiValued fields so we can 
> do sort=min(fieldname) asc and the sort would work on multiValued fields...
> ...this specific syntax has been spun off into SOLR-7853, but the underlying 
> functionality s being implemented here using a new optional second argument 
> to the {{field()}} function: {{field(multivalued_field_name,min)}} and 
> {{field(multivalued_field_name,max)}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-2522) add syntax for selecting the min or max of a multivalued field in value source functions

[ASF subversion and git services (JIRA)]

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

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

Commit 1693628 from hoss...@apache.org in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1693628 ]

SOLR-2522: new two argument option for the existing field() function; picks the 
min/max value of a docValues field to use as a ValueSource: 
"field(field_name,min)" and "field(field_name,max)" (merge r1693625)

> add syntax for selecting the min or max of a multivalued field in value 
> source functions
> 
>
> Key: SOLR-2522
> URL: https://issues.apache.org/jira/browse/SOLR-2522
> Project: Solr
>  Issue Type: Improvement
>Reporter: Bill Bell
>Assignee: Hoss Man
> Attachments: SOLR-2522.patch, SOLR-2522.patch, SOLR-2522.patch
>
>
> Initial request...
> bq. Switch max() and min() functions to work on multiValued fields so we can 
> do sort=min(fieldname) asc and the sort would work on multiValued fields...
> ...this specific syntax has been spun off into SOLR-7853, but the underlying 
> functionality s being implemented here using a new optional second argument 
> to the {{field()}} function: {{field(multivalued_field_name,min)}} and 
> {{field(multivalued_field_name,max)}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7823) TestMiniSolrCloudCluster.testCollectionCreateSearchDelete async collection-creation (sometimes)

[ASF subversion and git services (JIRA)]

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

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

Commit 1693627 from [~cpoerschke] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1693627 ]

SOLR-7823: TestMiniSolrCloudCluster.testCollectionCreateSearchDelete async 
collection-creation (sometimes)

> TestMiniSolrCloudCluster.testCollectionCreateSearchDelete async 
> collection-creation (sometimes)
> ---
>
> Key: SOLR-7823
> URL: https://issues.apache.org/jira/browse/SOLR-7823
> Project: Solr
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
>
> github pull request with proposed changes to follow



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: [JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2564 - Failure!

[Shalin Shekhar Mangar]

Can we please disable these CDCR tests? Looks like no one is actively
trying to fix them.

On Fri, Jul 31, 2015 at 9:49 PM, Policeman Jenkins Server
 wrote:
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2564/
> Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC
>
> 1 tests failed.
> FAILED:  org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTests
>
> Error Message:
> Timeout while trying to assert update logs @ collection=source_collection
>
> Stack Trace:
> java.lang.AssertionError: Timeout while trying to assert update logs @ 
> collection=source_collection
> at 
> __randomizedtesting.SeedInfo.seed([404A5D9C92A7051A:482A28B09DA92D11]:0)
> at 
> org.apache.solr.cloud.CdcrReplicationDistributedZkTest.assertNumberOfTlogFiles(CdcrReplicationDistributedZkTest.java:644)
> at 
> org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTestUpdateLogSynchronisation(CdcrReplicationDistributedZkTest.java:384)
> at 
> org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTests(CdcrReplicationDistributedZkTest.java:50)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
> at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966)
> at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941)
> at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
> at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
> at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
> 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:365)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
> 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 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.j

[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk1.9.0-ea-b60) - Build # 13677 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13677/
Java: 32bit/jdk1.9.0-ea-b60 -server -XX:+UseSerialGC 
-Djava.locale.providers=JRE,SPI

1 tests failed.
FAILED:  org.apache.solr.cloud.ShardSplitTest.test

Error Message:
Timeout occured while waiting response from server at: 
http://127.0.0.1:53429/yvwji

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:53429/yvwji
at 
__randomizedtesting.SeedInfo.seed([3B456047290870EC:B3115F9D87F41D14]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:572)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
at 
org.apache.solr.cloud.ShardSplitTest.splitShard(ShardSplitTest.java:490)
at 
org.apache.solr.cloud.ShardSplitTest.incompleteOrOverlappingCustomRangeTest(ShardSplitTest.java:111)
at org.apache.solr.cloud.ShardSplitTest.test(ShardSplitTest.java:76)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:502)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
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:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.a

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2564/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTests

Error Message:
Timeout while trying to assert update logs @ collection=source_collection

Stack Trace:
java.lang.AssertionError: Timeout while trying to assert update logs @ 
collection=source_collection
at 
__randomizedtesting.SeedInfo.seed([404A5D9C92A7051A:482A28B09DA92D11]:0)
at 
org.apache.solr.cloud.CdcrReplicationDistributedZkTest.assertNumberOfTlogFiles(CdcrReplicationDistributedZkTest.java:644)
at 
org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTestUpdateLogSynchronisation(CdcrReplicationDistributedZkTest.java:384)
at 
org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTests(CdcrReplicationDistributedZkTest.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
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:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
 

[jira] [Commented] (SOLR-2522) add syntax for selecting the min or max of a multivalued field in value source functions

[ASF subversion and git services (JIRA)]

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

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

Commit 1693625 from hoss...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1693625 ]

SOLR-2522: new two argument option for the existing field() function; picks the 
min/max value of a docValues field to use as a ValueSource: 
"field(field_name,min)" and "field(field_name,max)"

> add syntax for selecting the min or max of a multivalued field in value 
> source functions
> 
>
> Key: SOLR-2522
> URL: https://issues.apache.org/jira/browse/SOLR-2522
> Project: Solr
>  Issue Type: Improvement
>Reporter: Bill Bell
>Assignee: Hoss Man
> Attachments: SOLR-2522.patch, SOLR-2522.patch, SOLR-2522.patch
>
>
> Initial request...
> bq. Switch max() and min() functions to work on multiValued fields so we can 
> do sort=min(fieldname) asc and the sort would work on multiValued fields...
> ...this specific syntax has been spun off into SOLR-7853, but the underlying 
> functionality s being implemented here using a new optional second argument 
> to the {{field()}} function: {{field(multivalued_field_name,min)}} and 
> {{field(multivalued_field_name,max)}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-5868) JoinUtil support for NUMERIC docValues fields

[marc schipperheyn (JIRA)]

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

marc schipperheyn commented on LUCENE-5868:
---

I'd vote for it. 

> JoinUtil support for NUMERIC docValues fields 
> --
>
> Key: LUCENE-5868
> URL: https://issues.apache.org/jira/browse/LUCENE-5868
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Minor
>
> while polishing SOLR-6234 I found that JoinUtil can't join int dv fields at 
> least. 
> I plan to provide test/patch. It might be important, because Solr's join can 
> do that. Please vote if you care! 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7823) TestMiniSolrCloudCluster.testCollectionCreateSearchDelete async collection-creation (sometimes)

[ASF subversion and git services (JIRA)]

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

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

Commit 1693616 from [~cpoerschke] in branch 'dev/trunk'
[ https://svn.apache.org/r1693616 ]

SOLR-7823: TestMiniSolrCloudCluster.testCollectionCreateSearchDelete async 
collection-creation (sometimes)

> TestMiniSolrCloudCluster.testCollectionCreateSearchDelete async 
> collection-creation (sometimes)
> ---
>
> Key: SOLR-7823
> URL: https://issues.apache.org/jira/browse/SOLR-7823
> Project: Solr
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
>
> github pull request with proposed changes to follow



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_51) - Build # 5087 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5087/
Java: 32bit/jdk1.8.0_51 -server -XX:+UseG1GC

3 tests failed.
FAILED:  org.apache.solr.client.solrj.impl.CloudSolrClientTest.test

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([CDF0CB945A41E5FF:45A4F44EF4BD8807]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.allTests(CloudSolrClientTest.java:257)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.test(CloudSolrClientTest.java:114)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
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:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stateme

[jira] [Resolved] (SOLR-5022) PermGen exhausted test failures on Jenkins.

[Uwe Schindler (JIRA)]

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

Uwe Schindler resolved SOLR-5022.
-
Resolution: Fixed

> PermGen exhausted test failures on Jenkins.
> ---
>
> Key: SOLR-5022
> URL: https://issues.apache.org/jira/browse/SOLR-5022
> Project: Solr
>  Issue Type: Test
>  Components: Tests
>Reporter: Mark Miller
>Assignee: Uwe Schindler
>Priority: Critical
> Fix For: 5.3
>
> Attachments: SOLR-5022-permgen.patch, SOLR-5022-permgen.patch, 
> SOLR-5022-permgen.patch, SOLR-5022.patch, intern-count-win.txt
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-5022) PermGen exhausted test failures on Jenkins.

[ASF subversion and git services (JIRA)]

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

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

Commit 1693560 from [~thetaphi] in branch 'dev/trunk'
[ https://svn.apache.org/r1693560 ]

SOLR-5022: Merged revision(s) 1693559 from lucene/dev/branches/branch_5x: 
cleanup outdated Java 7 stuff

> PermGen exhausted test failures on Jenkins.
> ---
>
> Key: SOLR-5022
> URL: https://issues.apache.org/jira/browse/SOLR-5022
> Project: Solr
>  Issue Type: Test
>  Components: Tests
>Reporter: Mark Miller
>Assignee: Uwe Schindler
>Priority: Critical
> Fix For: 5.3
>
> Attachments: SOLR-5022-permgen.patch, SOLR-5022-permgen.patch, 
> SOLR-5022-permgen.patch, SOLR-5022.patch, intern-count-win.txt
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-5022) PermGen exhausted test failures on Jenkins.

[ASF subversion and git services (JIRA)]

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

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

Commit 1693559 from [~thetaphi] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1693559 ]

SOLR-5022: On Java 7 raise permgen for running tests

> PermGen exhausted test failures on Jenkins.
> ---
>
> Key: SOLR-5022
> URL: https://issues.apache.org/jira/browse/SOLR-5022
> Project: Solr
>  Issue Type: Test
>  Components: Tests
>Reporter: Mark Miller
>Assignee: Uwe Schindler
>Priority: Critical
> Fix For: 5.3
>
> Attachments: SOLR-5022-permgen.patch, SOLR-5022-permgen.patch, 
> SOLR-5022-permgen.patch, SOLR-5022.patch, intern-count-win.txt
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-5022) PermGen exhausted test failures on Jenkins.

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated SOLR-5022:

Attachment: SOLR-5022-permgen.patch

Patch for branch_5x.

I will commit this now.

> PermGen exhausted test failures on Jenkins.
> ---
>
> Key: SOLR-5022
> URL: https://issues.apache.org/jira/browse/SOLR-5022
> Project: Solr
>  Issue Type: Test
>  Components: Tests
>Reporter: Mark Miller
>Assignee: Uwe Schindler
>Priority: Critical
> Fix For: 5.3
>
> Attachments: SOLR-5022-permgen.patch, SOLR-5022-permgen.patch, 
> SOLR-5022-permgen.patch, SOLR-5022.patch, intern-count-win.txt
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.8.0_51) - Build # 13493 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13493/
Java: 32bit/jdk1.8.0_51 -server -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.cloud.DeleteShardTest.test

Error Message:
Timeout occured while waiting response from server at: https://127.0.0.1:38217

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: https://127.0.0.1:38217
at 
__randomizedtesting.SeedInfo.seed([16ACA470EE580FE1:9EF89BAA40A46219]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:572)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
at 
org.apache.solr.cloud.DeleteShardTest.deleteShard(DeleteShardTest.java:122)
at org.apache.solr.cloud.DeleteShardTest.test(DeleteShardTest.java:64)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
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:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(Te

[jira] [Resolved] (LUCENE-6621) two unused variables in analysis/stempel/src/java/org/egothor/stemmer/Compile.java

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved LUCENE-6621.
-
Resolution: Fixed

Thanks Rishabh!

> two unused variables in 
> analysis/stempel/src/java/org/egothor/stemmer/Compile.java
> --
>
> Key: LUCENE-6621
> URL: https://issues.apache.org/jira/browse/LUCENE-6621
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Affects Versions: Trunk
>Reporter: Rishabh Patel
>Assignee: Christine Poerschke
>Priority: Trivial
> Fix For: 5.3, Trunk
>
>
> {code:title=Compile.java|borderStyle=solid}
> public static void main(java.lang.String[] args) throws Exception {
> ...
>   for (int i = 1; i < args.length; i++) {
>   // System.out.println("[" + args[i] + "]");
>   Diff diff = new Diff();
>   int stems = 0;
>   int words = 0;
> ...
> {code}
> In the file {{Compile.java}}, the variables {{stems}} and {{words}} are 
> unused.
> Although {{words}} gets incremented further in the file, it does not get 
> referenced or used elsewhere.
> {{stems}} is neither incremented nor used elsewhere in the project.
> Are these variables redundant?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6620) Ignored statement

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on LUCENE-6620:
-

{{Compile.java}} is in {{lucene/analysis/stempel/src/java/org/egothor/stemmer}} 
directory.

currently the code does this:
{code}
args[0].toUpperCase(Locale.ROOT);
...
multi = args[0].charAt(qq) == 'M';
{code}

was something like this intended perhaps?
{code}
... = args[0].toUpperCase(Locale.ROOT);
{code}

> Ignored statement
> -
>
> Key: LUCENE-6620
> URL: https://issues.apache.org/jira/browse/LUCENE-6620
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Affects Versions: Trunk
>Reporter: Rishabh Patel
>Priority: Trivial
>
> {code:title=Compile.java|borderStyle=solid}
> public static void main(java.lang.String[] args) throws Exception {
> ...
>   args[0].toUpperCase(Locale.ROOT);
> ...
> }
> {code}
> In the file {{Compile.java}}, the argument string does not get capitalized.
> Is this statement redundant?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Assigned] (SOLR-7823) TestMiniSolrCloudCluster.testCollectionCreateSearchDelete async collection-creation (sometimes)

[Christine Poerschke (JIRA)]

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

Christine Poerschke reassigned SOLR-7823:
-

Assignee: Christine Poerschke

> TestMiniSolrCloudCluster.testCollectionCreateSearchDelete async 
> collection-creation (sometimes)
> ---
>
> Key: SOLR-7823
> URL: https://issues.apache.org/jira/browse/SOLR-7823
> Project: Solr
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
>
> github pull request with proposed changes to follow



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-5.x-Windows (32bit/jdk1.8.0_51) - Build # 4958 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4958/
Java: 32bit/jdk1.8.0_51 -client -XX:+UseSerialGC

1 tests failed.
FAILED:  
org.apache.solr.handler.dataimport.TestContentStreamDataSource.testCommitWithin

Error Message:
expected:<0> but was:<2>

Stack Trace:
java.lang.AssertionError: expected:<0> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([DF65E081378DC1C5:65B78FF9B4A32FD0]: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.solr.handler.dataimport.TestContentStreamDataSource.testCommitWithin(TestContentStreamDataSource.java:97)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
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:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
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:365)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 14988 lines...]
   [junit4] Suite: 
org.apache.solr.handler.dataimport

[jira] [Commented] (LUCENE-6647) Add GeoHash String Utilities to core GeoUtils

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6647:


bq. This fixes the issue where the max lat/lon was not decoding to the correct 
precision leading to the failure posted above.

Hmm can you open a new issue whose sole purpose is to cutover to full 32 bit 
precision for lat/lon?  LUCENE-6704 is about avoiding OOME (or is the full 32 
precision necessary to avoid OOME?) ... then we can decouple these issues?  
It's hard enough keeping track of all the in-flight patches without some 
depending on others...

> Add GeoHash String Utilities to core GeoUtils
> -
>
> Key: LUCENE-6647
> URL: https://issues.apache.org/jira/browse/LUCENE-6647
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Nicholas Knize
> Attachments: LUCENE-6647.patch, LUCENE-6647.patch, LUCENE-6647.patch
>
>
> GeoPointField uses morton encoding to efficiently pack lat/lon values into a 
> single long. GeoHashing effectively does the same thing but uses base 32 
> encoding to represent this long value as a "human readable" string.  Many 
> user applications already use the string representation of the hash. This 
> issue simply adds the base32 string representation of the already computed 
> morton code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

RE: Strange comment in CdcrReplicationHandlerTest.java

[Ramkumar R. Aiyengar]

Ah okay, my bad then..
On 29 Jul 2015 21:28, "Uwe Schindler"  wrote:

> RAT would only fail if the license header is missing completely. I don't
> think it checks for "copyright notices".
>
> If there is no license header, we should check our RAT config! What does
> it list as license for that file?
>
> Uwe
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
> > -Original Message-
> > From: Erick Erickson [mailto:erickerick...@gmail.com]
> > Sent: Wednesday, July 29, 2015 7:36 PM
> > To: dev@lucene.apache.org
> > Subject: Re: Strange comment in CdcrReplicationHandlerTest.java
> >
> > Yeah, I wondered that myself.
> >
> > On Wed, Jul 29, 2015 at 1:35 PM, Ramkumar R. Aiyengar
> >  wrote:
> > > Hmm.. I would have expected rat to fail this in precommit actually..
> > >
> > > On 29 Jul 2015 18:01, "Timothy Potter"  wrote:
> > >>
> > >> Why is this in the code?
> > >>
> > >> /**
> > >>  * Copyright (c) 2015 Renaud Delbru. All Rights Reserved.
> > >>  */
> > >> package org.apache.solr.cloud;
> > >>
> > >> -
> > >> 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] [Commented] (LUCENE-6697) Use 1D KD tree for alternative to postings based numeric range filters

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6697:


bq. it's easy to estimate up front how many hits we'll have, so I can call grow 
up front

This gives a nice speedup: ~5.2 sec down to ~4.7 sec for the "225 bbox lats 
around London" benchmark.

> Use 1D KD tree for alternative to postings based numeric range filters
> --
>
> Key: LUCENE-6697
> URL: https://issues.apache.org/jira/browse/LUCENE-6697
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Attachments: LUCENE-6697.patch, LUCENE-6697.patch, LUCENE-6697.patch
>
>
> Today Lucene uses postings to index a numeric value at multiple
> precision levels for fast range searching.  It's somewhat costly: each
> numeric value is indexed with multiple terms (4 terms by default)
> ... I think a dedicated 1D BKD tree should be more compact and perform
> better.
> It should also easily generalize beyond 64 bits to arbitrary byte[],
> e.g. for LUCENE-5596, but I haven't explored that here.
> A 1D BKD tree just sorts all values, and then indexes adjacent leaf
> blocks of size 512-1024 (by default) values per block, and their
> docIDs, into a fully balanced binary tree.  Building the range filter
> is then just a recursive walk through this tree.
> It's the same structure we use for 2D lat/lon BKD tree, just with 1D
> instead.  I implemented it as a DocValuesFormat that also writes the
> numeric tree on the side.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6697) Use 1D KD tree for alternative to postings based numeric range filters

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6697:


bq. I also changed search-time to an iterative impl (vs recursive before)

Actually once nice benefit of this is it's easy to estimate up front how many 
hits we'll have, so I can call {{grow}} up front.  I'll add that and commit 
soon...

> Use 1D KD tree for alternative to postings based numeric range filters
> --
>
> Key: LUCENE-6697
> URL: https://issues.apache.org/jira/browse/LUCENE-6697
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Attachments: LUCENE-6697.patch, LUCENE-6697.patch, LUCENE-6697.patch
>
>
> Today Lucene uses postings to index a numeric value at multiple
> precision levels for fast range searching.  It's somewhat costly: each
> numeric value is indexed with multiple terms (4 terms by default)
> ... I think a dedicated 1D BKD tree should be more compact and perform
> better.
> It should also easily generalize beyond 64 bits to arbitrary byte[],
> e.g. for LUCENE-5596, but I haven't explored that here.
> A 1D BKD tree just sorts all values, and then indexes adjacent leaf
> blocks of size 512-1024 (by default) values per block, and their
> docIDs, into a fully balanced binary tree.  Building the range filter
> is then just a recursive walk through this tree.
> It's the same structure we use for 2D lat/lon BKD tree, just with 1D
> instead.  I implemented it as a DocValuesFormat that also writes the
> numeric tree on the side.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6629) Random 7200 seconds build timeouts / infinite loops in Lucene tests?

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6629:


Woops, you're right [~dawid.weiss]!  It also stalls for me ... so this is just 
SimpleText being slow (as expected).

> Random 7200 seconds build timeouts / infinite loops in Lucene tests?
> 
>
> Key: LUCENE-6629
> URL: https://issues.apache.org/jira/browse/LUCENE-6629
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
> Attachments: 54457_consoleText.txt
>
>
> I'm not sure what's going on here, but every so often a Jenkins run will fail 
> with a build timeout (7200 seconds) with stack traces that do not look like 
> deadlock.  They never reproduce for me.
> We really need to improve test infra here, so that each HEARTBEAT we also got 
> 1) full thread stacks and 2) total CPU usage of the process as reported by 
> the ManagementBean APIs ... this would shed more light on whether the JVM is 
> somehow hung vs our bug (infinite loop).  But infinite loop seems most likely 
> ... the stacks always seem to be somewhere "spooky".
> We should try to gather recent Jenkins runs where this is happening, here, to 
> see if there are patterns / we can get to the root cause.
> Anyway, this happened to me on my old beast box, which runs the "nightly ant 
> test times" graphs: 
> http://people.apache.org/~mikemccand/lucenebench/antcleantest.html
> The 2015/06/27 data point is missing because it failed with this timeout:
> {noformat}
>[junit4] Suite: org.apache.lucene.search.TestDocValuesRewriteMethod
>[junit4]   2> ??? 28, 2015 7:01:29 ? 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$2 evaluate
>[junit4]   2> WARNING: Suite execution timed out: 
> org.apache.lucene.search.TestDocValuesRewriteMethod
>[junit4]   2>1) Thread[id=1, name=main, state=WAITING, group=main]
>[junit4]   2> at java.lang.Object.wait(Native Method)
>[junit4]   2> at java.lang.Thread.join(Thread.java:1245)
>[junit4]   2> at java.lang.Thread.join(Thread.java:1319)
>[junit4]   2> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:578)
>[junit4]   2> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.run(RandomizedRunner.java:444)
>[junit4]   2> at 
> com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:199)
>[junit4]   2> at 
> com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:310)
>[junit4]   2> at 
> com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:12)
>[junit4]   2>2) Thread[id=213, 
> name=TEST-TestDocValuesRewriteMethod.testRegexps-seed#[C2DDF486BB909D8], 
> state=RUNNABLE, group=TGRP-TestDocValuesRewriteMethod]
>[junit4]   2> at 
> org.apache.lucene.util.automaton.Operations.getLiveStates(Operations.java:900)
>[junit4]   2> at 
> org.apache.lucene.util.automaton.Operations.hasDeadStates(Operations.java:389)
>[junit4]   2> at 
> org.apache.lucene.util.automaton.Automata.makeString(Automata.java:517)
>[junit4]   2> at 
> org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:579)
>[junit4]   2> at 
> org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:617)
>[junit4]   2> at 
> org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:519)
>[junit4]   2> at 
> org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:617)
>[junit4]   2> at 
> org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:510)
>[junit4]   2> at 
> org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:495)
>[junit4]   2> at 
> org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:466)
>[junit4]   2> at 
> org.apache.lucene.search.RegexpQuery.(RegexpQuery.java:109)
>[junit4]   2> at 
> org.apache.lucene.search.RegexpQuery.(RegexpQuery.java:79)
>[junit4]   2> at 
> org.apache.lucene.search.TestDocValuesRewriteMethod.assertSame(TestDocValuesRewriteMethod.java:117)
>[junit4]   2> at 
> org.apache.lucene.search.TestDocValuesRewriteMethod.testRegexps(TestDocValuesRewriteMethod.java:109)
>[junit4]   2> at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]   2> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]   2> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]   2> at java.lang.reflect.Method.invoke(Method

[jira] [Commented] (LUCENE-6629) Random 7200 seconds build timeouts / infinite loops in Lucene tests?

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-6629:
-

To me it looks like it's just churning a lot of data and using simple text 
codec? I tried running on of the repros locally and it also stalls.

> Random 7200 seconds build timeouts / infinite loops in Lucene tests?
> 
>
> Key: LUCENE-6629
> URL: https://issues.apache.org/jira/browse/LUCENE-6629
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
> Attachments: 54457_consoleText.txt
>
>
> I'm not sure what's going on here, but every so often a Jenkins run will fail 
> with a build timeout (7200 seconds) with stack traces that do not look like 
> deadlock.  They never reproduce for me.
> We really need to improve test infra here, so that each HEARTBEAT we also got 
> 1) full thread stacks and 2) total CPU usage of the process as reported by 
> the ManagementBean APIs ... this would shed more light on whether the JVM is 
> somehow hung vs our bug (infinite loop).  But infinite loop seems most likely 
> ... the stacks always seem to be somewhere "spooky".
> We should try to gather recent Jenkins runs where this is happening, here, to 
> see if there are patterns / we can get to the root cause.
> Anyway, this happened to me on my old beast box, which runs the "nightly ant 
> test times" graphs: 
> http://people.apache.org/~mikemccand/lucenebench/antcleantest.html
> The 2015/06/27 data point is missing because it failed with this timeout:
> {noformat}
>[junit4] Suite: org.apache.lucene.search.TestDocValuesRewriteMethod
>[junit4]   2> ??? 28, 2015 7:01:29 ? 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$2 evaluate
>[junit4]   2> WARNING: Suite execution timed out: 
> org.apache.lucene.search.TestDocValuesRewriteMethod
>[junit4]   2>1) Thread[id=1, name=main, state=WAITING, group=main]
>[junit4]   2> at java.lang.Object.wait(Native Method)
>[junit4]   2> at java.lang.Thread.join(Thread.java:1245)
>[junit4]   2> at java.lang.Thread.join(Thread.java:1319)
>[junit4]   2> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:578)
>[junit4]   2> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.run(RandomizedRunner.java:444)
>[junit4]   2> at 
> com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:199)
>[junit4]   2> at 
> com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:310)
>[junit4]   2> at 
> com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:12)
>[junit4]   2>2) Thread[id=213, 
> name=TEST-TestDocValuesRewriteMethod.testRegexps-seed#[C2DDF486BB909D8], 
> state=RUNNABLE, group=TGRP-TestDocValuesRewriteMethod]
>[junit4]   2> at 
> org.apache.lucene.util.automaton.Operations.getLiveStates(Operations.java:900)
>[junit4]   2> at 
> org.apache.lucene.util.automaton.Operations.hasDeadStates(Operations.java:389)
>[junit4]   2> at 
> org.apache.lucene.util.automaton.Automata.makeString(Automata.java:517)
>[junit4]   2> at 
> org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:579)
>[junit4]   2> at 
> org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:617)
>[junit4]   2> at 
> org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:519)
>[junit4]   2> at 
> org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:617)
>[junit4]   2> at 
> org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:510)
>[junit4]   2> at 
> org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:495)
>[junit4]   2> at 
> org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:466)
>[junit4]   2> at 
> org.apache.lucene.search.RegexpQuery.(RegexpQuery.java:109)
>[junit4]   2> at 
> org.apache.lucene.search.RegexpQuery.(RegexpQuery.java:79)
>[junit4]   2> at 
> org.apache.lucene.search.TestDocValuesRewriteMethod.assertSame(TestDocValuesRewriteMethod.java:117)
>[junit4]   2> at 
> org.apache.lucene.search.TestDocValuesRewriteMethod.testRegexps(TestDocValuesRewriteMethod.java:109)
>[junit4]   2> at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]   2> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]   2> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]   2> at java.lang.reflect.Method.

[jira] [Commented] (LUCENE-6664) Replace SynonymFilter with SynonymGraphFilter

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6664:


Thinking about this more, I think it's sort of silly to only expose the "always 
flattened synonym filter" because that's really no better than today: you still 
can't search multi-token synonyms correctly, and there are small differences in 
how the graph corruption happens.

So I'd like to go back to the 2nd patch, where both filters are public.  I'll 
mark them experimental...

> Replace SynonymFilter with SynonymGraphFilter
> -
>
> Key: LUCENE-6664
> URL: https://issues.apache.org/jira/browse/LUCENE-6664
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.3, Trunk
>
> Attachments: LUCENE-6664.patch, LUCENE-6664.patch, LUCENE-6664.patch, 
> usa.png, usa_flat.png
>
>
> Spinoff from LUCENE-6582.
> I created a new SynonymGraphFilter (to replace the current buggy
> SynonymFilter), that produces correct graphs (does no "graph
> flattening" itself).  I think this makes it simpler.
> This means you must add the FlattenGraphFilter yourself, if you are
> applying synonyms during indexing.
> Index-time syn expansion is a necessarily "lossy" graph transformation
> when multi-token (input or output) synonyms are applied, because the
> index does not store {{posLength}}, so there will always be phrase
> queries that should match but do not, and then phrase queries that
> should not match but do.
> http://blog.mikemccandless.com/2012/04/lucenes-tokenstreams-are-actually.html
> goes into detail about this.
> However, with this new SynonymGraphFilter, if instead you do synonym
> expansion at query time (and don't do the flattening), and you use
> TermAutomatonQuery (future: somehow integrated into a query parser),
> or maybe just "enumerate all paths and make union of PhraseQuery", you
> should get 100% correct matches (not sure about "proper" scoring
> though...).
> This new syn filter still cannot consume an arbitrary graph.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6648) AnalyzingInfixLookupFactory always highlights suggestions

[Arcadius Ahouansou (JIRA)]

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

Arcadius Ahouansou commented on SOLR-6648:
--

Would be nice if highlight was a query-time parameter where clients could 
choose whether they want it or not.

> AnalyzingInfixLookupFactory always highlights suggestions
> -
>
> Key: SOLR-6648
> URL: https://issues.apache.org/jira/browse/SOLR-6648
> Project: Solr
>  Issue Type: Sub-task
>Affects Versions: 4.9, 4.9.1, 4.10, 4.10.1
>Reporter: Varun Thacker
>Assignee: Tomás Fernández Löbbe
>  Labels: suggester
> Fix For: 5.1, Trunk
>
> Attachments: SOLR-6648-v4.10.3.patch, SOLR-6648.patch
>
>
> When using AnalyzingInfixLookupFactory suggestions always return with the 
> match term as highlighted and 'allTermsRequired' is always set to true.
> We should be able to configure those.
> Steps to reproduce - 
> schema additions
> {code}
> 
> 
>   mySuggester
>   AnalyzingInfixLookupFactory
>   DocumentDictionaryFactory 
>   suggestField
>   weight
>   textSuggest
> 
>   
>   
> 
>   true
>   10
> 
> 
>   suggest
> 
>   
> {code}
> solrconfig changes -
> {code}
>  positionIncrementGap="100">
>
>   
>   
>   
>
>   
> stored="true"/>
> {code}
> Add 3 documents - 
> {code}
> curl http://localhost:8983/solr/update/json?commit=true -H 
> 'Content-type:application/json' -d '
> [ {"id" : "1", "suggestField" : "bass fishing"}, {"id" : "2", "suggestField" 
> : "sea bass"}, {"id" : "3", "suggestField" : "sea bass fishing"} ]
> '
> {code}
> Query -
> {code}
> http://localhost:8983/solr/collection1/suggest?suggest.build=true&suggest.dictionary=mySuggester&q=bass&wt=json&indent=on
> {code}
> Response 
> {code}
> {
>   "responseHeader":{
> "status":0,
> "QTime":25},
>   "command":"build",
>   "suggest":{"mySuggester":{
>   "bass":{
> "numFound":3,
> "suggestions":[{
> "term":"bass fishing",
> "weight":0,
> "payload":""},
>   {
> "term":"sea bass",
> "weight":0,
> "payload":""},
>   {
> "term":"sea bass fishing",
> "weight":0,
> "payload":""}]
> {code}
> The problem is in SolrSuggester Line 200 where we say lookup.lookup()
> This constructor does not take allTermsRequired and doHighlight since it's 
> only tuneable to AnalyzingInfixSuggester and not the other lookup 
> implementations.
> If different Lookup implementations have different params as their 
> constructors, these sort of issues will always keep happening. Maybe we 
> should not keep it generic and do instanceof checks and set params 
> accordingly?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-5756) A utility API to move collections from internal to external

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-5756:
-

[~dragonsinth] - I am 'shalin' on irc

> A utility API to move collections from internal to external
> ---
>
> Key: SOLR-5756
> URL: https://issues.apache.org/jira/browse/SOLR-5756
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Noble Paul
>
> SOLR-5473 allows creation of collection with state stored outside of 
> clusterstate.json. We would need an API to  move existing 'internal' 
> collections outside



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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