[jira] [Updated] (SOLR-8619) A new replica should not become leader when all current replicas are down as it leads to data loss

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-8619:
---
Priority: Blocker  (was: Major)

> A new replica should not become leader when all current replicas are down as 
> it leads to data loss
> --
>
> Key: SOLR-8619
> URL: https://issues.apache.org/jira/browse/SOLR-8619
> Project: Solr
>  Issue Type: Bug
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Blocker
> Fix For: 5.5
>
>
> Here's what I'm talking about:
> * Start a 2 node solrcloud cluster
> * Create a 1 shard/1 replica collection
> * Add documents
> * Shut down the node that has the only active shard
> * ADDREPLICA for the shard/collection, so Solr would attempt to add a new 
> replica on the other node
> * Solr waits for a while before this replica becomes an active leader.
> * Index a few new docs
> * Bring up the old node
> * The replica comes up, with it's old index and then syncs to only contain 
> the docs from the new leader.
> All old documents are lost in this case
> Here are a few things that might work here:
> 1. Reject an ADDREPLICA call if all current replicas for the shard are down. 
> Considering the new replica can not sync from anyone, it doesn't make sense 
> for this replica to even come up
> 2. The replica shouldn't become active/leader unless either it was the last 
> known leader or active before it went into recovering state
> unless there are no other replicas in the clusterstate.
> This might very well be related to SOLR-8173 but we should add a check to 
> ADDREPLICA as well.



--
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: Lucene/Solr 6.0.0 release

[Anshum Gupta]

Thanks Mike for volunteering!

I wanted to get SOLR-8619 in for 5.5.0, I'll mark that as a blocker as it
can potentially cause data loss. I'm currently working on that.

I also have a bunch of Solr related stuff I wanted to commit before moving
on the 6.0 path so back-compat wouldn't be a problem, but we can always
have another deprecation release before 6.0 if needed, specially once we
have the git based release process ironed out.

I am not saying we WILL have another 5.x release, just a thought. It all
depends on the release timeline for 6.0 :)


On Tue, Feb 9, 2016 at 11:56 AM, Michael McCandless <
luc...@mikemccandless.com> wrote:

> Thanks Christine, I'll wait for SOLR-8621 before cutting the branch.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Tue, Feb 9, 2016 at 2:46 PM, Christine Poerschke (BLOOMBERG/
> LONDON)  wrote:
> > +1 for 5.5.0 release.
> >
> > Am about to mark SOLR-8621 as a blocker, it's basically 'done' (with
> collaboration and help from Shai) but a signature change for
> MergePolicyFactory will be needed to support SOLR-5730 (which ideally would
> also be included in 5.5.0 and which hopefully can be wrapped up this week
> also, patch update to follow later today).
> >
> > Sorry for not speaking up about these two tickets earlier, I had
> optimistically thought that they would be done-and-dusted by 'mid this
> week' but it didn't quite turn out like that ...
> >
> > Christine
> >
> > - Original Message -
> > From: dev@lucene.apache.org
> > To: dev@lucene.apache.org
> > At: Feb  5 2016 10:17:40
> >
> > Thanks Nick and Anshum, I'll volunteer to be RM.  If there are blocker
> > 5.5 issues, please mark them as such in Jira, thanks!
> >
> > I don't think we are rushing here ... it was a little under a month
> > ago when I had thought "in or week or two" let's cut the 6.x branch ;)
> >
> > I see 5.5 release as just getting all the (stable) backported features
> > out to the world before we release 6.0.0.
> >
> > I'll aim to cut the 5.5 branch mid next week...
> >
> > Mike McCandless
> >
> > http://blog.mikemccandless.com
> >
> >
> > On Thu, Feb 4, 2016 at 1:04 PM, Anshum Gupta 
> wrote:
> >> I have a few things I'd like to get in. I hope to get those in by next
> week.
> >>
> >> I think the 5.5 release is an important one for us as the cleanup in 6.0
> >> depends on it. We shouldn't rush it.
> >>
> >> On Thu, Feb 4, 2016 at 9:42 AM, Nicholas Knize 
> wrote:
> >>>
> >>> +1 for 5.5.0 release. I have 2 issues I'd like to get in for 5.5:
> >>> LUCENE-6930 and LUCENE-6997 which changes GeoPoint encoding (boosting
> >>> performance), and graduates these features from sandbox. They should be
> >>> ready by Monday (or sooner).
> >>>
> >>> On Thu, Feb 4, 2016 at 11:00 AM, Michael McCandless
> >>>  wrote:
> 
>  I think we are in good shape now for 6.0.0?
> 
>  git cutover is done and seems to be going well except for how we name
>  branches
> 
>  Dimensional values are renamed to point values, the API is cleaned up
>  a bit, and you can now search for == (not just ranges), and
>  StoredDocument is removed.
> 
>  We should first do a 5.5.0 release to get all the goodness back-ported
>  5.x features out, and also smoke-test our first git-based release.
>  Does anyone want to volunteer as RM?
> 
>  Mike McCandless
> 
>  http://blog.mikemccandless.com
> 
>  On Fri, Jan 8, 2016 at 8:24 PM, Mark Miller 
>  wrote:
>  > On Fri, Jan 8, 2016 at 2:52 PM Michael McCandless
>  >  wrote:
>  >>
>  >> I agree it would be nice to have cutover to git by then: are we
> ready
>  >> to open an INFRA issue to do the hard cutover?  Or do we still have
>  >> things to do on our end?  (Thank you Dawid and Mark and Paul and
> Uwe
>  >> and everyone else for pushing hard on this front!).
>  >
>  >
>  > We are fairly close - just one last thing to come to consensus on.
>  > Remains
>  > to be seen how fast INFRA reacts for us though.
>  >
>  > There will also probably be a bit to do as we work through the first
>  > release, in terms of release scripts, docs, etc. I think most of it
>  > should
>  > be fairly light weight changes though.
>  >
>  > - Mark
>  > --
>  > - Mark
>  > about.me/markrmiller
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>  For additional commands, e-mail: dev-h...@lucene.apache.org
> 
> >>>
> >>
> >>
> >>
> >> --
> >> Anshum Gupta
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
> >
>
> 

Re: Jira version tag for master branch

[Michael McCandless]

>From what I understand, "trunk" should go away and be renamed to
"master".  Can a Solr dev do this for existing Solr issues?

When I cut the 6.0 branch (after 5.5 release seems close to done),
I'll rename all "master" issues to 6.0 and new (master) issues are
then 7.0.

Mike McCandless

http://blog.mikemccandless.com

On Tue, Feb 9, 2016 at 9:49 AM, Jan Høydahl  wrote:
> Could you do the same to Solr’s JIRA?
>
> We now both have both a “master” and “6.0” version. Which of them should we
> tag “trunk” issues with?
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> 3. feb. 2016 kl. 21.26 skrev Ryan Ernst :
>
> FYI, I just renamed the "Trunk" version to "master", to match what we have
> now with git. Since it was just a rename, it appears all the existing issues
> that used Trunk as a fix version are already updated.
>
>

-
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 (64bit/jdk1.7.0_80) - Build # 15524 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/15524/
Java: 64bit/jdk1.7.0_80 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.lucene.index.TestSortingMergePolicy.testForceMergeNotNeeded

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([30EFF0123D69EF45:2CCC8808A6360450]:0)
at 
org.apache.lucene.index.BaseMergePolicyTestCase$1.merge(BaseMergePolicyTestCase.java:43)
at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1931)
at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1764)
at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1721)
at 
org.apache.lucene.index.BaseMergePolicyTestCase.testForceMergeNotNeeded(BaseMergePolicyTestCase.java:62)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 7690 lines...]
   [junit4] Suite: org.apache.lucene.index.TestSortingMergePolicy
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestSortingMergePolicy -Dtests.method=testForceMergeNotNeeded 
-Dtests.seed=30EFF0123D69EF45 -Dtests.multiplier=3 -Dtests.slow=true 
-Dtests.locale=ms-MY -Dtests.timezone=America/Vancouver -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] FAILURE 0.78s J1 | 

[jira] [Updated] (SOLR-8621) solrconfig.xml: deprecate/replace with

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-8621:
--
Priority: Blocker  (was: Major)

> solrconfig.xml: deprecate/replace  with 
> -
>
> Key: SOLR-8621
> URL: https://issues.apache.org/jira/browse/SOLR-8621
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Blocker
> Fix For: 5.5, master
>
> Attachments: SOLR-8621.patch, explicit-merge-auto-set.patch
>
>
> * end-user benefits:*
> * Lucene's UpgradeIndexMergePolicy can be configured in Solr
> * (with SOLR-5730) Lucene's SortingMergePolicy can be configured in Solr
> * customisability: arbitrary merge policies including wrapping/nested merge 
> policies can be created and configured
> *(proposed) roadmap:*
> * solr 5.5 introduces  support
> * solr 5.5(\?) deprecates (but maintains)  support
> * solr 6.0(\?) removes  support 
> +work-in-progress summary:+
>  * main code changes have been committed to master and branch_5x
>  * {color:red}further small code change required:{color} MergePolicyFactory 
> constructor or MergePolicyFactory.getMergePolicy method to take IndexSchema 
> argument (e.g. for use by SortingMergePolicyFactory being added under related 
> SOLR-5730)
>  * Solr Reference Guide changes (directly in Confluence?)
>  * changes to remaining solrconfig.xml
>  ** solr/core/src/test-files/solr/collection1/conf - Christine
>  ** solr/contrib
>  ** solr/example
> +open question:+
>  * Do we want to error if luceneMatchVersion >= 5.5 and deprecated 
> mergePolicy/mergeFactor/maxMergeDocs are used? See [~hossman]'s comment on 
> Feb 1st. The code as-is permits mergePolicy irrespective of 
> luceneMatchVersion, I think.



--
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-8621) solrconfig.xml: deprecate/replace with

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-8621:
--
Labels:   (was: blocker)

> solrconfig.xml: deprecate/replace  with 
> -
>
> Key: SOLR-8621
> URL: https://issues.apache.org/jira/browse/SOLR-8621
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Blocker
> Fix For: 5.5, master
>
> Attachments: SOLR-8621.patch, explicit-merge-auto-set.patch
>
>
> * end-user benefits:*
> * Lucene's UpgradeIndexMergePolicy can be configured in Solr
> * (with SOLR-5730) Lucene's SortingMergePolicy can be configured in Solr
> * customisability: arbitrary merge policies including wrapping/nested merge 
> policies can be created and configured
> *(proposed) roadmap:*
> * solr 5.5 introduces  support
> * solr 5.5(\?) deprecates (but maintains)  support
> * solr 6.0(\?) removes  support 
> +work-in-progress summary:+
>  * main code changes have been committed to master and branch_5x
>  * {color:red}further small code change required:{color} MergePolicyFactory 
> constructor or MergePolicyFactory.getMergePolicy method to take IndexSchema 
> argument (e.g. for use by SortingMergePolicyFactory being added under related 
> SOLR-5730)
>  * Solr Reference Guide changes (directly in Confluence?)
>  * changes to remaining solrconfig.xml
>  ** solr/core/src/test-files/solr/collection1/conf - Christine
>  ** solr/contrib
>  ** solr/example
> +open question:+
>  * Do we want to error if luceneMatchVersion >= 5.5 and deprecated 
> mergePolicy/mergeFactor/maxMergeDocs are used? See [~hossman]'s comment on 
> Feb 1st. The code as-is permits mergePolicy irrespective of 
> luceneMatchVersion, I think.



--
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: Lucene/Solr 6.0.0 release

[Michael McCandless]

Thanks Christine, I'll wait for SOLR-8621 before cutting the branch.

Mike McCandless

http://blog.mikemccandless.com


On Tue, Feb 9, 2016 at 2:46 PM, Christine Poerschke (BLOOMBERG/
LONDON)  wrote:
> +1 for 5.5.0 release.
>
> Am about to mark SOLR-8621 as a blocker, it's basically 'done' (with 
> collaboration and help from Shai) but a signature change for 
> MergePolicyFactory will be needed to support SOLR-5730 (which ideally would 
> also be included in 5.5.0 and which hopefully can be wrapped up this week 
> also, patch update to follow later today).
>
> Sorry for not speaking up about these two tickets earlier, I had 
> optimistically thought that they would be done-and-dusted by 'mid this week' 
> but it didn't quite turn out like that ...
>
> Christine
>
> - Original Message -
> From: dev@lucene.apache.org
> To: dev@lucene.apache.org
> At: Feb  5 2016 10:17:40
>
> Thanks Nick and Anshum, I'll volunteer to be RM.  If there are blocker
> 5.5 issues, please mark them as such in Jira, thanks!
>
> I don't think we are rushing here ... it was a little under a month
> ago when I had thought "in or week or two" let's cut the 6.x branch ;)
>
> I see 5.5 release as just getting all the (stable) backported features
> out to the world before we release 6.0.0.
>
> I'll aim to cut the 5.5 branch mid next week...
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Thu, Feb 4, 2016 at 1:04 PM, Anshum Gupta  wrote:
>> I have a few things I'd like to get in. I hope to get those in by next week.
>>
>> I think the 5.5 release is an important one for us as the cleanup in 6.0
>> depends on it. We shouldn't rush it.
>>
>> On Thu, Feb 4, 2016 at 9:42 AM, Nicholas Knize  wrote:
>>>
>>> +1 for 5.5.0 release. I have 2 issues I'd like to get in for 5.5:
>>> LUCENE-6930 and LUCENE-6997 which changes GeoPoint encoding (boosting
>>> performance), and graduates these features from sandbox. They should be
>>> ready by Monday (or sooner).
>>>
>>> On Thu, Feb 4, 2016 at 11:00 AM, Michael McCandless
>>>  wrote:

 I think we are in good shape now for 6.0.0?

 git cutover is done and seems to be going well except for how we name
 branches

 Dimensional values are renamed to point values, the API is cleaned up
 a bit, and you can now search for == (not just ranges), and
 StoredDocument is removed.

 We should first do a 5.5.0 release to get all the goodness back-ported
 5.x features out, and also smoke-test our first git-based release.
 Does anyone want to volunteer as RM?

 Mike McCandless

 http://blog.mikemccandless.com

 On Fri, Jan 8, 2016 at 8:24 PM, Mark Miller 
 wrote:
 > On Fri, Jan 8, 2016 at 2:52 PM Michael McCandless
 >  wrote:
 >>
 >> I agree it would be nice to have cutover to git by then: are we ready
 >> to open an INFRA issue to do the hard cutover?  Or do we still have
 >> things to do on our end?  (Thank you Dawid and Mark and Paul and Uwe
 >> and everyone else for pushing hard on this front!).
 >
 >
 > We are fairly close - just one last thing to come to consensus on.
 > Remains
 > to be seen how fast INFRA reacts for us though.
 >
 > There will also probably be a bit to do as we work through the first
 > release, in terms of release scripts, docs, etc. I think most of it
 > should
 > be fairly light weight changes though.
 >
 > - Mark
 > --
 > - Mark
 > about.me/markrmiller

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

>>>
>>
>>
>>
>> --
>> Anshum Gupta
>
> -
> 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-6997) Graduate GeoUtils and postings based GeoPointField from sandbox...

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-6997:
--

Nick, I have one parting thought before this gets cemented into 5.5.  The 
package structure you've introduced here is:
* org.apache.lucene.spatial.document  (only public class is GeoPointField)
* org.apache.lucene.spatial.search (lots of classes)

If the only spatial indexing approach that were to exist were this one, then 
this is just fine.  But there are in fact other approaches, and we are bound to 
come up with more.  (BTW this is partly the motivation of the SpatialStrategy 
abstraction)  With each approach, the Queries can only be used with a 
particular Field implementation.  Imagine adding Geo3DPoint to your package 
structure above, and the Query side as well.  It starts to become confusing for 
people to navigate and know what goes with what.  I would certainly be 
confused; it all sounds so similar.  Instead, I suggest a 
{{org.apache.lucene.spatial.geopoint}} package to put all the classes 
associated with this indexing approach.  Perhaps you then feel it's useful to 
add a {{document}} and {{search}} sub-package; I don't but I leave that 
consideration to you.  What do you think?

> Graduate GeoUtils and postings based GeoPointField from sandbox...
> --
>
> Key: LUCENE-6997
> URL: https://issues.apache.org/jira/browse/LUCENE-6997
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
> Fix For: 5.5, trunk
>
> Attachments: LUCENE-6997.patch, LUCENE-6997.patch
>
>
> {{GeoPointField}} is a lightweight dependency-free postings based geo field 
> currently in sandbox. It has evolved into a very fast lightweight geo option 
> that heavily leverages the optimized performance of the postings structure. 
> It was originally intended to graduate to core but this does not seem 
> appropriate given the variety of "built on postings" term encoding options 
> (e.g., see LUCENE-6930).  
> Additionally, the {{Geo*Utils}} classes are dependency free lightweight 
> relational approximation utilities used by both {{GeoPointField}} and the BKD 
> based {{LatLonField}} and can also be applied to benefit the lucene-spatial 
> module.
> These classes have been evolving and baking for some time and are at a 
> maturity level qualifying for promotion from sandbox. This will allow support 
> for experimental encoding methods with (minimal) backwards compatibility - 
> something sandbox does not allow.
> Since GeoPoint classes are dependency free, all GeoPointField and support and 
> utility classes currently in sandbox would be promoted to the spatial3d 
> package. (possibly a separate issue to rename spatial3d to spatialcore or 
> spatiallite?) Such that for basic lightweight Geo support one would only need 
> a handful of lucene jars. By simply adding the lucene-spatial module and its 
> dependency jars users can obtain more advanced geospatial support (heatmap 
> facets, full shape relations, etc).



--
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-8649) Fail fast on wrong ZK chroot

[Steve Molloy (JIRA)]

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

Steve Molloy commented on SOLR-8649:


Another issue about launching Solr without a chroot to inexisting zNode. 
Attached patch adds a parameter to automatically create the zNode if required.

> Fail fast on wrong ZK chroot
> 
>
> Key: SOLR-8649
> URL: https://issues.apache.org/jira/browse/SOLR-8649
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
> Fix For: 5.5, Trunk
>
>
> A typical scenario is when a user sets up ZK with a chroot /solr, runs Solr 
> and then restarts Solr without specifying the chroot. In the default 
> legacyCloud mode, Solr will happily start and create all ZK nodes as well as 
> collections found on the local cores.
> I've been bit many times by this and so have more than a few Solr users. In a 
> private discussion, Hoss gave the following idea:
> * We add a command to bin/solr to "prepare" ZooKeeper that accepts the zk 
> host string
> * The command creates the chroot if it does not exist
> * Touches /my-chroot/solr.key file
> * Writes the complete zk host in the solr.in.sh or solr.in.cmd file
> Once we do this, Solr will complain and fail fast if the solr.key file is not 
> found in the given chroot. We could also write a fixed string in the 
> /my-chroot instead of creating a /my-chroot/solr.key file.
> We can do these things automatically when using embedded ZooKeeper.



--
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-8647) Already open IndexSearcher sees different DVs as commits are happening

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-8647:
---
Attachment: SOLR-8647-tests.patch

[~erickerickson] pinged me and pointed out that the test doesn't work due to 
problems with the schema file I added. Updating the patch so that this can be 
reproduced.

> Already open IndexSearcher sees different DVs as commits are happening
> --
>
> Key: SOLR-8647
> URL: https://issues.apache.org/jira/browse/SOLR-8647
> Project: Solr
>  Issue Type: Bug
>Reporter: Ishan Chattopadhyaya
> Attachments: SOLR-8647-tests.patch, TestIndexSearcherStability.java, 
> TestIndexSearcherStability.java, TestIndexSearcherStability.java, schema16.xml
>
>
> While working on SOLR-5944, I ran into an issue whereby an already open 
> IndexSearcher sees different views of the DVs as updates/commits are 
> happening in different threads. This is resulting in inconsistency of DV 
> values for the already open main searcher.
> When logging out the searcher, I can see that the searcher instance is same, 
> but the dvgen and fieldinfogen values are changing for an existing searcher.



--
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-8621) solrconfig.xml: deprecate/replace with

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-8621:
--
Fix Version/s: Trunk
   5.5

> solrconfig.xml: deprecate/replace  with 
> -
>
> Key: SOLR-8621
> URL: https://issues.apache.org/jira/browse/SOLR-8621
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Fix For: 5.5, Trunk
>
> Attachments: SOLR-8621.patch, explicit-merge-auto-set.patch
>
>
> * end-user benefits:*
> * Lucene's UpgradeIndexMergePolicy can be configured in Solr
> * (with SOLR-5730) Lucene's SortingMergePolicy can be configured in Solr
> * customisability: arbitrary merge policies including wrapping/nested merge 
> policies can be created and configured
> *(proposed) roadmap:*
> * solr 5.5 introduces  support
> * solr 5.5(\?) deprecates (but maintains)  support
> * solr 6.0(\?) removes  support 
> +work-in-progress summary:+
>  * main code changes have been committed to master and branch_5x
>  * {color:red}further small code change required:{color} MergePolicyFactory 
> constructor or MergePolicyFactory.getMergePolicy method to take IndexSchema 
> argument (e.g. for use by SortingMergePolicyFactory being added under related 
> SOLR-5730)
>  * Solr Reference Guide changes (directly in Confluence?)
>  * changes to remaining solrconfig.xml
>  ** solr/core/src/test-files/solr/collection1/conf - Christine
>  ** solr/contrib
>  ** solr/example
> +open question:+
>  * Do we want to error if luceneMatchVersion >= 5.5 and deprecated 
> mergePolicy/mergeFactor/maxMergeDocs are used? See [~hossman]'s comment on 
> Feb 1st. The code as-is permits mergePolicy irrespective of 
> luceneMatchVersion, I think.



--
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: Lucene/Solr 6.0.0 release

[Christine Poerschke (BLOOMBERG/ LONDON)]

+1 for 5.5.0 release.

Am about to mark SOLR-8621 as a blocker, it's basically 'done' (with 
collaboration and help from Shai) but a signature change for MergePolicyFactory 
will be needed to support SOLR-5730 (which ideally would also be included in 
5.5.0 and which hopefully can be wrapped up this week also, patch update to 
follow later today).

Sorry for not speaking up about these two tickets earlier, I had optimistically 
thought that they would be done-and-dusted by 'mid this week' but it didn't 
quite turn out like that ...

Christine

- Original Message -
From: dev@lucene.apache.org
To: dev@lucene.apache.org
At: Feb  5 2016 10:17:40

Thanks Nick and Anshum, I'll volunteer to be RM.  If there are blocker
5.5 issues, please mark them as such in Jira, thanks!

I don't think we are rushing here ... it was a little under a month
ago when I had thought "in or week or two" let's cut the 6.x branch ;)

I see 5.5 release as just getting all the (stable) backported features
out to the world before we release 6.0.0.

I'll aim to cut the 5.5 branch mid next week...

Mike McCandless

http://blog.mikemccandless.com


On Thu, Feb 4, 2016 at 1:04 PM, Anshum Gupta  wrote:
> I have a few things I'd like to get in. I hope to get those in by next week.
>
> I think the 5.5 release is an important one for us as the cleanup in 6.0
> depends on it. We shouldn't rush it.
>
> On Thu, Feb 4, 2016 at 9:42 AM, Nicholas Knize  wrote:
>>
>> +1 for 5.5.0 release. I have 2 issues I'd like to get in for 5.5:
>> LUCENE-6930 and LUCENE-6997 which changes GeoPoint encoding (boosting
>> performance), and graduates these features from sandbox. They should be
>> ready by Monday (or sooner).
>>
>> On Thu, Feb 4, 2016 at 11:00 AM, Michael McCandless
>>  wrote:
>>>
>>> I think we are in good shape now for 6.0.0?
>>>
>>> git cutover is done and seems to be going well except for how we name
>>> branches
>>>
>>> Dimensional values are renamed to point values, the API is cleaned up
>>> a bit, and you can now search for == (not just ranges), and
>>> StoredDocument is removed.
>>>
>>> We should first do a 5.5.0 release to get all the goodness back-ported
>>> 5.x features out, and also smoke-test our first git-based release.
>>> Does anyone want to volunteer as RM?
>>>
>>> Mike McCandless
>>>
>>> http://blog.mikemccandless.com
>>>
>>> On Fri, Jan 8, 2016 at 8:24 PM, Mark Miller 
>>> wrote:
>>> > On Fri, Jan 8, 2016 at 2:52 PM Michael McCandless
>>> >  wrote:
>>> >>
>>> >> I agree it would be nice to have cutover to git by then: are we ready
>>> >> to open an INFRA issue to do the hard cutover?  Or do we still have
>>> >> things to do on our end?  (Thank you Dawid and Mark and Paul and Uwe
>>> >> and everyone else for pushing hard on this front!).
>>> >
>>> >
>>> > We are fairly close - just one last thing to come to consensus on.
>>> > Remains
>>> > to be seen how fast INFRA reacts for us though.
>>> >
>>> > There will also probably be a bit to do as we work through the first
>>> > release, in terms of release scripts, docs, etc. I think most of it
>>> > should
>>> > be fairly light weight changes though.
>>> >
>>> > - Mark
>>> > --
>>> > - Mark
>>> > about.me/markrmiller
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>
>
>
>
> --
> Anshum Gupta

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

[jira] [Updated] (SOLR-5730) make Lucene's SortingMergePolicy and EarlyTerminatingSortingCollector configurable in Solr

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-5730:
--
Fix Version/s: master
   5.5

> make Lucene's SortingMergePolicy and EarlyTerminatingSortingCollector 
> configurable in Solr
> --
>
> Key: SOLR-5730
> URL: https://issues.apache.org/jira/browse/SOLR-5730
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
>  Labels: blocker
> Fix For: 5.5, master
>
> Attachments: SOLR-5730-part1of2.patch, SOLR-5730-part1of2.patch, 
> SOLR-5730-part2of2.patch, SOLR-5730-part2of2.patch
>
>
> *Example configuration (solrconfig.xml) - corresponding to latest attached 
> patch:*
> {noformat}
> 
>   timestamp desc
> 
> {noformat}
> *Example configuration (solrconfig.xml) - corresponding to current 
> (work-in-progress master-solr-8621) SOLR-8621 efforts:*
> {noformat}
> -
> +
> +  TieredMergePolicyFactory
> +  timestamp desc
> +
> {noformat}
> *Example use (EarlyTerminatingSortingCollector):*
> {noformat}
> =timestamp+desc=true
> {noformat}



--
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-5730) make Lucene's SortingMergePolicy and EarlyTerminatingSortingCollector configurable in Solr

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-5730:
--
Labels: blocker  (was: )

> make Lucene's SortingMergePolicy and EarlyTerminatingSortingCollector 
> configurable in Solr
> --
>
> Key: SOLR-5730
> URL: https://issues.apache.org/jira/browse/SOLR-5730
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
>  Labels: blocker
> Fix For: 5.5, master
>
> Attachments: SOLR-5730-part1of2.patch, SOLR-5730-part1of2.patch, 
> SOLR-5730-part2of2.patch, SOLR-5730-part2of2.patch
>
>
> *Example configuration (solrconfig.xml) - corresponding to latest attached 
> patch:*
> {noformat}
> 
>   timestamp desc
> 
> {noformat}
> *Example configuration (solrconfig.xml) - corresponding to current 
> (work-in-progress master-solr-8621) SOLR-8621 efforts:*
> {noformat}
> -
> +
> +  TieredMergePolicyFactory
> +  timestamp desc
> +
> {noformat}
> *Example use (EarlyTerminatingSortingCollector):*
> {noformat}
> =timestamp+desc=true
> {noformat}



--
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-8619) A new replica should not become leader when all current replicas are down as it leads to data loss

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-8619:
---
Fix Version/s: 5.5

> A new replica should not become leader when all current replicas are down as 
> it leads to data loss
> --
>
> Key: SOLR-8619
> URL: https://issues.apache.org/jira/browse/SOLR-8619
> Project: Solr
>  Issue Type: Bug
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Fix For: 5.5
>
>
> Here's what I'm talking about:
> * Start a 2 node solrcloud cluster
> * Create a 1 shard/1 replica collection
> * Add documents
> * Shut down the node that has the only active shard
> * ADDREPLICA for the shard/collection, so Solr would attempt to add a new 
> replica on the other node
> * Solr waits for a while before this replica becomes an active leader.
> * Index a few new docs
> * Bring up the old node
> * The replica comes up, with it's old index and then syncs to only contain 
> the docs from the new leader.
> All old documents are lost in this case
> Here are a few things that might work here:
> 1. Reject an ADDREPLICA call if all current replicas for the shard are down. 
> Considering the new replica can not sync from anyone, it doesn't make sense 
> for this replica to even come up
> 2. The replica shouldn't become active/leader unless either it was the last 
> known leader or active before it went into recovering state
> unless there are no other replicas in the clusterstate.
> This might very well be related to SOLR-8173 but we should add a check to 
> ADDREPLICA as well.



--
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-7019) explore two-phase iteration for GeoPoint query

[ASF subversion and git services (JIRA)]

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

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

Commit b92ccc01f6daa43a2afb464c9112d53cbba9cc00 in lucene-solr's branch 
refs/heads/branch_5x from nknize
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b92ccc0 ]

LUCENE-7019: add two-phase iteration to GeoPointTermQueryConstantScoreWrapper


> explore two-phase iteration for GeoPoint query
> --
>
> Key: LUCENE-7019
> URL: https://issues.apache.org/jira/browse/LUCENE-7019
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial
>Reporter: Robert Muir
> Fix For: 5.5, master
>
> Attachments: LUCENE-7019.patch, LUCENE-7019.patch
>
>
> This query today uses an approximation+confirm approach, but it all happens 
> when you call scorer(), in a termsEnum loop.
> This causes several problems (even after 
> https://issues.apache.org/jira/browse/LUCENE-7018) because it can do too much 
> work, if queries have multiple values since the doc can be "confirmed" more 
> than once.
> I think it would be better to delay this confirmation as much as possible, so 
> that other parts of the query (e.g. other filters, conjunctions, etc) can 
> eliminate checks as well.



--
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-8621) solrconfig.xml: deprecate/replace with

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-8621:
---

[~shaie] - thanks for pushing changes to master and branch_5x.

bq. ... I think we can now remove support for  in master? ...

Could I suggest leaving support in master until 5.5 is released? Perhaps 
'remove  support' should be a separate JIRA even? Two main 
motivations for keeping the deprecated mergePolicy around for a little longer: 
(a) I'd like to do a little more work on the tests to ensure we didn't 
inadvertently break anything as part of the change. (b) If any little changes 
are needed then it might be easier to commit-to-master-and-then-merge-to-5.5 if 
master still has the deprecated mergePolicy support. How does that sound?

bq. We also need to modify the ref guide .. do we do that via JIRA too? Let me 
know how you want to proceed, not sure if you've already started to work on any 
of these.

Good question, not sure how ref guide changes are normally handled. No, I 
haven't started to work on the ref guide things as yet.

bq. BTW, I'll delete the remote tracking branch or this feature. We can create 
a new one if needed. Have you pushed anything more to it?

Let me check, I think there might have been some test-related stuff and draft 
solr/CHANGES.txt examples.


> solrconfig.xml: deprecate/replace  with 
> -
>
> Key: SOLR-8621
> URL: https://issues.apache.org/jira/browse/SOLR-8621
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Attachments: SOLR-8621.patch, explicit-merge-auto-set.patch
>
>
> * end-user benefits:*
> * Lucene's UpgradeIndexMergePolicy can be configured in Solr
> * (with SOLR-5730) Lucene's SortingMergePolicy can be configured in Solr
> * customisability: arbitrary merge policies including wrapping/nested merge 
> policies can be created and configured
> *(proposed) roadmap:*
> * solr 5.5 introduces  support
> * solr 5.5(\?) deprecates (but maintains)  support
> * solr 6.0(\?) removes  support 
> +work-in-progress git branch:+ 
> [master-solr-8621|https://github.com/apache/lucene-solr/tree/master-solr-8621]



--
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-8621) solrconfig.xml: deprecate/replace with

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-8621:
---

[~elyograg] - It's the master-solr-8621 i.e. working branch 
https://git1-us-west.apache.org/repos/asf?p=lucene-solr.git;a=commitdiff;h=8ec2c844
 that you refer to I think?

bq. ... maxMergeAtOnce and segmentsPerTier value of 42 ...

My intention was to communicate that users with an existing {{}} 
or {{}} setting likely need to add an equivalent element to the 
{{}} element. Using 42 as an example value was clearly 
distracting, I will use ?? instead then.

bq. ... maxMergeAtOnce ... maxMergeAtOnceExplicit ...

Interesting point about the alignment or otherwise of these values. Yes, that 
sounds worthy of its own LUCENE issue.

> solrconfig.xml: deprecate/replace  with 
> -
>
> Key: SOLR-8621
> URL: https://issues.apache.org/jira/browse/SOLR-8621
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Attachments: SOLR-8621.patch, explicit-merge-auto-set.patch
>
>
> * end-user benefits:*
> * Lucene's UpgradeIndexMergePolicy can be configured in Solr
> * (with SOLR-5730) Lucene's SortingMergePolicy can be configured in Solr
> * customisability: arbitrary merge policies including wrapping/nested merge 
> policies can be created and configured
> *(proposed) roadmap:*
> * solr 5.5 introduces  support
> * solr 5.5(\?) deprecates (but maintains)  support
> * solr 6.0(\?) removes  support 
> +work-in-progress git branch:+ 
> [master-solr-8621|https://github.com/apache/lucene-solr/tree/master-solr-8621]



--
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-EA] Lucene-Solr-trunk-Linux (32bit/jdk-9-ea+104) - Build # 15822 - Still Failing!

[Uwe Schindler]

LOL. If compact string wouldn't have been disabled, I would say: Compact String 
comprumpted(TM) the version :-)

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


> -Original Message-
> From: Robert Muir [mailto:rcm...@gmail.com]
> Sent: Tuesday, February 09, 2016 4:00 AM
> To: dev@lucene.apache.org
> Subject: Re: [JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk-9-ea+104) -
> Build # 15822 - Still Failing!
> 
> best jvm crash ever.
> 
> On Mon, Feb 8, 2016 at 9:54 PM, Policeman Jenkins Server
>  wrote:
> >[junit4] >>> JVM J2 emitted unexpected output (verbatim) 
> >[junit4] #
> >[junit4] # A fatal error has been detected by the Java Runtime
> Environment:
> >[junit4] #
> >[junit4] #  SIGSEGV (0xb) at pc=0x89c03155, pid=14255, tid=14333
> >[junit4] #
> >[junit4] # JRE version: ˆ„K÷ +¡àø+¡à  (9.0+104) (build )
> >[junit4] # Java VM: Java HotSpot(TM) Server VM (9-ea+104-2016-02-03-
> 214936.javare.4385.nc, mixed mode, tiered, concurrent mark sweep gc,
> linux-x86)
> >[junit4] # Problematic frame:
> >[junit4] # C  0x89c03155
> >[junit4] #
> >[junit4] # No core dump will be written. Core dumps have been disabled.
> To enable core dumping, try "ulimit -c unlimited" before starting Java again
> >[junit4] #
> >[junit4] # An error report file with more information is saved as:
> >[junit4] # /home/jenkins/workspace/Lucene-Solr-trunk-
> Linux/lucene/build/codecs/test/J2/hs_err_pid14255.log
> >[junit4] [thread 15849 also had an error]
> >[junit4] [thread 14331 also had an error]
> >[junit4] [thread 14332 also had an error]
> >[junit4]
> >[junit4] [error occurred during error reporting , id 0xb]
> >[junit4]
> >[junit4] #
> >[junit4] # If you would like to submit a bug report, please visit:
> >[junit4] #   http://bugreport.java.com/bugreport/crash.jsp
> >[junit4] #
> >[junit4] <<< JVM J2: EOF 
> >
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org


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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/15520/
Java: 32bit/jdk1.8.0_72 -server -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.core.TestNRTOpen.testSharedCores

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

Stack Trace:
java.lang.AssertionError: expected:<3> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([7C7BFEA4A5A2D7C0:9A78B4EB2D54FACF]: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.core.TestNRTOpen.testSharedCores(TestNRTOpen.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:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 12083 lines...]
   [junit4] Suite: org.apache.solr.core.TestNRTOpen
   [junit4]   2> Creating dataDir: 

[jira] [Commented] (SOLR-8621) solrconfig.xml: deprecate/replace with

[ASF subversion and git services (JIRA)]

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

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

Commit 360376095446db236c1708af18b95dd13c605634 in lucene-solr's branch 
refs/heads/master from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3603760 ]

SOLR-8621: solr/CHANGES.txt 'Upgrading from 5.4' section now also mentions 
 and  deprecation, also useCompoundFile 
attribute/element.


> solrconfig.xml: deprecate/replace  with 
> -
>
> Key: SOLR-8621
> URL: https://issues.apache.org/jira/browse/SOLR-8621
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Attachments: SOLR-8621.patch, explicit-merge-auto-set.patch
>
>
> * end-user benefits:*
> * Lucene's UpgradeIndexMergePolicy can be configured in Solr
> * (with SOLR-5730) Lucene's SortingMergePolicy can be configured in Solr
> * customisability: arbitrary merge policies including wrapping/nested merge 
> policies can be created and configured
> *(proposed) roadmap:*
> * solr 5.5 introduces  support
> * solr 5.5(\?) deprecates (but maintains)  support
> * solr 6.0(\?) removes  support 
> +work-in-progress git branch:+ 
> [master-solr-8621|https://github.com/apache/lucene-solr/tree/master-solr-8621]



--
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-8621) solrconfig.xml: deprecate/replace with

[ASF subversion and git services (JIRA)]

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

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

Commit b052a8f93776ed7fef3c47764650566cfd9a358f in lucene-solr's branch 
refs/heads/branch_5x from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b052a8f ]

SOLR-8621: solr/CHANGES.txt 'Upgrading from 5.4' section now also mentions 
 and  deprecation, also useCompoundFile 
attribute/element.


> solrconfig.xml: deprecate/replace  with 
> -
>
> Key: SOLR-8621
> URL: https://issues.apache.org/jira/browse/SOLR-8621
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Attachments: SOLR-8621.patch, explicit-merge-auto-set.patch
>
>
> * end-user benefits:*
> * Lucene's UpgradeIndexMergePolicy can be configured in Solr
> * (with SOLR-5730) Lucene's SortingMergePolicy can be configured in Solr
> * customisability: arbitrary merge policies including wrapping/nested merge 
> policies can be created and configured
> *(proposed) roadmap:*
> * solr 5.5 introduces  support
> * solr 5.5(\?) deprecates (but maintains)  support
> * solr 6.0(\?) removes  support 
> +work-in-progress git branch:+ 
> [master-solr-8621|https://github.com/apache/lucene-solr/tree/master-solr-8621]



--
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-8663) Multiple searchers open for a single core causing memory issues

[Dhritiman Das (JIRA)]

Dhritiman Das created SOLR-8663:
---

 Summary: Multiple searchers open for a single core causing memory 
issues
 Key: SOLR-8663
 URL: https://issues.apache.org/jira/browse/SOLR-8663
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.6
Reporter: Dhritiman Das


For a single core, we are having multiple searchers open. Although the current 
searcher points to the latest searcher opened, some old searchers are not 
getting cleaned up , they are holding their cache and ultimately causing memory 
issues. 

Possibly for cores which are taking a lot of time to warmup their cache the 
replication interval is overlapping with warmup time taken for the last 
searcher open during last replication.

However any idea why sometimes old searchers are not getting freed ?
Ex. Searchers from couple of days back are still seen in Solr console.
ip:port/solr/admin.html#//plugins/core
Is there any known bug around this for Solr 4.6 ?

p.s.: we have custom code extending some Solr components at many places. What I 
am trying to understand also is what is the best place to start debugging this ?



--
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-MacOSX (64bit/jdk1.8.0) - Build # 3021 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/3021/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC

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

Error Message:
Expected 2 of 3 replicas to be active but only found 1; 
[core_node3:{"core":"c8n_1x3_lf_shard1_replica3","base_url":"http://127.0.0.1:50052/j_ra","node_name":"127.0.0.1:50052_j_ra","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf)={   "replicationFactor":"3",   
"shards":{"shard1":{   "range":"8000-7fff",   "state":"active", 
  "replicas":{ "core_node1":{   
"core":"c8n_1x3_lf_shard1_replica1",   
"base_url":"http://127.0.0.1:50045/j_ra;,   
"node_name":"127.0.0.1:50045_j_ra",   "state":"down"}, 
"core_node2":{   "state":"down",   
"base_url":"http://127.0.0.1:50067/j_ra;,   
"core":"c8n_1x3_lf_shard1_replica2",   
"node_name":"127.0.0.1:50067_j_ra"}, "core_node3":{   
"core":"c8n_1x3_lf_shard1_replica3",   
"base_url":"http://127.0.0.1:50052/j_ra;,   
"node_name":"127.0.0.1:50052_j_ra",   "state":"active",   
"leader":"true",   "router":{"name":"compositeId"},   
"maxShardsPerNode":"1",   "autoAddReplicas":"false"}

Stack Trace:
java.lang.AssertionError: Expected 2 of 3 replicas to be active but only found 
1; 
[core_node3:{"core":"c8n_1x3_lf_shard1_replica3","base_url":"http://127.0.0.1:50052/j_ra","node_name":"127.0.0.1:50052_j_ra","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf)={
  "replicationFactor":"3",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "core":"c8n_1x3_lf_shard1_replica1",
  "base_url":"http://127.0.0.1:50045/j_ra;,
  "node_name":"127.0.0.1:50045_j_ra",
  "state":"down"},
"core_node2":{
  "state":"down",
  "base_url":"http://127.0.0.1:50067/j_ra;,
  "core":"c8n_1x3_lf_shard1_replica2",
  "node_name":"127.0.0.1:50067_j_ra"},
"core_node3":{
  "core":"c8n_1x3_lf_shard1_replica3",
  "base_url":"http://127.0.0.1:50052/j_ra;,
  "node_name":"127.0.0.1:50052_j_ra",
  "state":"active",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false"}
at 
__randomizedtesting.SeedInfo.seed([8CCFF33F59C43842:49BCCE5F73855BA]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:170)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:55)
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:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:964)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:939)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 

[jira] [Commented] (SOLR-8664) Export Score

[Akiel (JIRA)]

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

Akiel commented on SOLR-8664:
-

I created this issue in response to Joel Bernstein answer in the solr-user 
mailing group. Below is a copy of my original question and Joel's answer to 
help give some context:

Exporting scores would be a great feature to have. I don't believe it will
add too much complexity to export and sort by score. The main consideration
has been memory consumption for every large export sets. The export feature
powers SQL queries that are unlimited in Solr 6. So adding scores to export
would support queries like:

select id, title, score from tableX where a = '(a query)'

Where currently you can only do this:

select id, title, score from tableX where a = '(a query)' limit 1000

Can you create a jira for this and link it to SOLR-8125.

Joel Bernstein

> Hi,
>
> I would like to issue a query and get the ID and Score for each matching
> document. There may be lots of results so I wanted to use the export
> handler, but unfortunately the current version of Solr doesn't seem to
> export the Score - I read the comments on
> https://issues.apache.org/jira/browse/SOLR-5244 (Exporting Full Sorted
> Result Sets) but am not sure what happened with the idea of exporting the
> Score. Does anybody know of an existing or future version where this can
> be done?
>
> I compared exporting 100,000 IDs via the export handler with getting
> 100,000 ID,Score pairs using the cursor mark - exporting 100,000 IDs was
> an order of magnitude faster on my laptop. Does anybody know of a faster
> way to retrieve the ID,Score pairs for a query on a SolrScloud deployment
> and/or have an idea on the possible performance characteristics of
> exporting ID, Score (without ranking) if it was to be implemented?
>
> Cheers
>
> Akiel

> Export Score
> 
>
> Key: SOLR-8664
> URL: https://issues.apache.org/jira/browse/SOLR-8664
> Project: Solr
>  Issue Type: Improvement
>  Components: Server
>Affects Versions: 6.0
>Reporter: Akiel
>
> Would be great if we can export the score as well as the ID from a 
> (SolrCloud) Stream. 



--
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-5438) add near-real-time replication

[Michael McCandless (JIRA)]

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

Michael McCandless updated LUCENE-5438:
---
Fix Version/s: 6.0

> add near-real-time replication
> --
>
> Key: LUCENE-5438
> URL: https://issues.apache.org/jira/browse/LUCENE-5438
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/replicator
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 6.0
>
> Attachments: LUCENE-5438.patch, LUCENE-5438.patch, LUCENE-5438.patch
>
>
> Lucene's replication module makes it easy to incrementally sync index
> changes from a master index to any number of replicas, and it
> handles/abstracts all the underlying complexity of holding a
> time-expiring snapshot, finding which files need copying, syncing more
> than one index (e.g., taxo + index), etc.
> But today you must first commit on the master, and then again the
> replica's copied files are fsync'd, because the code operates on
> commit points.  But this isn't "technically" necessary, and it mixes
> up durability and fast turnaround time.
> Long ago we added near-real-time readers to Lucene, for the same
> reason: you shouldn't have to commit just to see the new index
> changes.
> I think we should do the same for replication: allow the new segments
> to be copied out to replica(s), and new NRT readers to be opened, to
> fully decouple committing from visibility.  This way apps can then
> separately choose when to replicate (for freshness), and when to
> commit (for durability).
> I think for some apps this could be a compelling alternative to the
> "re-index all documents on each shard" approach that Solr Cloud /
> ElasticSearch implement today, and it may also mean that the
> transaction log can remain external to / above the cluster.



--
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-5438) add near-real-time replication

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-5438:


I got back to this issue and have been pushing changes here:

  
https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=shortlog;h=refs/heads/jira/lucene-5438-nrt-replication

Net/net I think it's in pretty good shape ... I'd like to add this for
6.0 as an experimental feature, as an alternative to document based
replication.

I think there are complex tradeoffs between the two approaches to
distributing Lucene, but I think it's important users at least have
a choice.

With this change, multiple nodes (primary and replicas) have
essentially the same transactional semantics that a single Lucene
IndexWriter + NRT readers offers.  You have known point-in-time views
that are the consistent (long version) across nodes, you can commit
any node (primary or replica), rollback etc.  When things crash, on
restart they are back to the last commit, etc.

The test cases are quite evil: they spawn sub-process JVMs, and
communicate over a naive (thread-per-connection) TCP protocol to copy
files, index documents, search, etc.  And they randomly crash (thank
you {{TestIndexWriterOnJRECrash}}!), commit, close, flip bits during
file copy, simulate slow networks, etc.

I'll make an applyable patch from the current branch and post here.


> add near-real-time replication
> --
>
> Key: LUCENE-5438
> URL: https://issues.apache.org/jira/browse/LUCENE-5438
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/replicator
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 6.0
>
> Attachments: LUCENE-5438.patch, LUCENE-5438.patch, LUCENE-5438.patch
>
>
> Lucene's replication module makes it easy to incrementally sync index
> changes from a master index to any number of replicas, and it
> handles/abstracts all the underlying complexity of holding a
> time-expiring snapshot, finding which files need copying, syncing more
> than one index (e.g., taxo + index), etc.
> But today you must first commit on the master, and then again the
> replica's copied files are fsync'd, because the code operates on
> commit points.  But this isn't "technically" necessary, and it mixes
> up durability and fast turnaround time.
> Long ago we added near-real-time readers to Lucene, for the same
> reason: you shouldn't have to commit just to see the new index
> changes.
> I think we should do the same for replication: allow the new segments
> to be copied out to replica(s), and new NRT readers to be opened, to
> fully decouple committing from visibility.  This way apps can then
> separately choose when to replicate (for freshness), and when to
> commit (for durability).
> I think for some apps this could be a compelling alternative to the
> "re-index all documents on each shard" approach that Solr Cloud /
> ElasticSearch implement today, and it may also mean that the
> transaction log can remain external to / above the cluster.



--
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-6989) Implement MMapDirectory unmapping for coming Java 9 changes

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated LUCENE-6989:
--
Attachment: LUCENE-6989.patch

Updated patch:
- Builds a single MethodHandle for unmapping logic
- Adds missing assume in TestMmapDir

> Implement MMapDirectory unmapping for coming Java 9 changes
> ---
>
> Key: LUCENE-6989
> URL: https://issues.apache.org/jira/browse/LUCENE-6989
> Project: Lucene - Core
>  Issue Type: Task
>  Components: core/store
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
> Attachments: LUCENE-6989.patch, LUCENE-6989.patch, LUCENE-6989.patch
>
>
> Originally, the sun.misc.Cleaner interface was declared as "critical API" in 
> [JEP 260|http://openjdk.java.net/jeps/260 ]
> Unfortunately the decission was changed in favor of a oficially supported 
> {{java.lang.ref.Cleaner}} API. A side effect of this change is to move all 
> existing {{sun.misc.Cleaner}} APIs into a non-exported package. This causes 
> our forceful unmapping to no longer work, because we can get the cleaner 
> instance via reflection, but trying to invoke it will throw one of the new 
> Jigsaw RuntimeException because it is completely inaccessible. This will make 
> our forceful unmapping fail. There are also no changes in Garbage collector, 
> the problem still exists.
> For more information see this [mailing list 
> thread|http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/thread.html#38243].
> This commit will likely be done, making our unmapping efforts no longer 
> working. Alan Bateman is aware of this issue and will open a new issue at 
> OpenJDK to allow forceful unmapping without using the now private 
> sun.misc.Cleaner. The idea is to let the internal class sun.misc.Cleaner 
> implement the Runable interface, so we can simply cast to runable and call 
> the run() method to unmap. The code would then work. This will lead to minor 
> changes in our unmapper in MMapDirectory: An instanceof check and casting if 
> possible.
> I opened this issue to keep track and implement the changes as soon as 
> possible, so people will have working unmapping when java 9 comes out. 
> Current Lucene versions will no longer work with Java 9.



--
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-8664) Export Score

[Akiel (JIRA)]

Akiel created SOLR-8664:
---

 Summary: Export Score
 Key: SOLR-8664
 URL: https://issues.apache.org/jira/browse/SOLR-8664
 Project: Solr
  Issue Type: Improvement
  Components: Server
Affects Versions: 6.0
Reporter: Akiel


Would be great if we can export the score as well as the ID from a (SolrCloud) 
Stream. 



--
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-8648) Support selective clearing up of stored async collection API responses

[Anshum Gupta (JIRA)]

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

Anshum Gupta resolved SOLR-8648.

Resolution: Fixed

> Support selective clearing up of stored async collection API responses
> --
>
> Key: SOLR-8648
> URL: https://issues.apache.org/jira/browse/SOLR-8648
> Project: Solr
>  Issue Type: New Feature
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Fix For: 5.5, Trunk
>
> Attachments: SOLR-8648.patch, SOLR-8648.patch, SOLR-8648.patch, 
> SOLR-8648.patch
>
>
> The only way to clear up stored collection API responses right now is by 
> sending in '-1' as the request id in the REQUESTSTATUS call. It makes a lot 
> of sense to support selective deletion of stored responses so the ids could 
> be reused.



--
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-6997) Graduate GeoUtils and postings based GeoPointField from sandbox...

[Nicholas Knize (JIRA)]

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

Nicholas Knize updated LUCENE-6997:
---
Fix Version/s: (was: 5.5)
   6.0

> Graduate GeoUtils and postings based GeoPointField from sandbox...
> --
>
> Key: LUCENE-6997
> URL: https://issues.apache.org/jira/browse/LUCENE-6997
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial
>Reporter: Nicholas Knize
> Fix For: 5.5, trunk
>
> Attachments: LUCENE-6997.patch, LUCENE-6997.patch
>
>
> {{GeoPointField}} is a lightweight dependency-free postings based geo field 
> currently in sandbox. It has evolved into a very fast lightweight geo option 
> that heavily leverages the optimized performance of the postings structure. 
> It was originally intended to graduate to core but this does not seem 
> appropriate given the variety of "built on postings" term encoding options 
> (e.g., see LUCENE-6930).  
> Additionally, the {{Geo*Utils}} classes are dependency free lightweight 
> relational approximation utilities used by both {{GeoPointField}} and the BKD 
> based {{LatLonField}} and can also be applied to benefit the lucene-spatial 
> module.
> These classes have been evolving and baking for some time and are at a 
> maturity level qualifying for promotion from sandbox. This will allow support 
> for experimental encoding methods with (minimal) backwards compatibility - 
> something sandbox does not allow.
> Since GeoPoint classes are dependency free, all GeoPointField and support and 
> utility classes currently in sandbox would be promoted to the spatial3d 
> package. (possibly a separate issue to rename spatial3d to spatialcore or 
> spatiallite?) Such that for basic lightweight Geo support one would only need 
> a handful of lucene jars. By simply adding the lucene-spatial module and its 
> dependency jars users can obtain more advanced geospatial support (heatmap 
> facets, full shape relations, etc).



--
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-6997) Graduate GeoUtils and postings based GeoPointField from sandbox...

[Nicholas Knize (JIRA)]

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

Nicholas Knize updated LUCENE-6997:
---
Labels:   (was: blocker)

> Graduate GeoUtils and postings based GeoPointField from sandbox...
> --
>
> Key: LUCENE-6997
> URL: https://issues.apache.org/jira/browse/LUCENE-6997
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial
>Reporter: Nicholas Knize
> Fix For: 5.5, trunk
>
> Attachments: LUCENE-6997.patch, LUCENE-6997.patch
>
>
> {{GeoPointField}} is a lightweight dependency-free postings based geo field 
> currently in sandbox. It has evolved into a very fast lightweight geo option 
> that heavily leverages the optimized performance of the postings structure. 
> It was originally intended to graduate to core but this does not seem 
> appropriate given the variety of "built on postings" term encoding options 
> (e.g., see LUCENE-6930).  
> Additionally, the {{Geo*Utils}} classes are dependency free lightweight 
> relational approximation utilities used by both {{GeoPointField}} and the BKD 
> based {{LatLonField}} and can also be applied to benefit the lucene-spatial 
> module.
> These classes have been evolving and baking for some time and are at a 
> maturity level qualifying for promotion from sandbox. This will allow support 
> for experimental encoding methods with (minimal) backwards compatibility - 
> something sandbox does not allow.
> Since GeoPoint classes are dependency free, all GeoPointField and support and 
> utility classes currently in sandbox would be promoted to the spatial3d 
> package. (possibly a separate issue to rename spatial3d to spatialcore or 
> spatiallite?) Such that for basic lightweight Geo support one would only need 
> a handful of lucene jars. By simply adding the lucene-spatial module and its 
> dependency jars users can obtain more advanced geospatial support (heatmap 
> facets, full shape relations, etc).



--
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-6997) Graduate GeoUtils and postings based GeoPointField from sandbox...

[Nicholas Knize (JIRA)]

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

Nicholas Knize updated LUCENE-6997:
---
Fix Version/s: (was: 6.0)
   5.5

> Graduate GeoUtils and postings based GeoPointField from sandbox...
> --
>
> Key: LUCENE-6997
> URL: https://issues.apache.org/jira/browse/LUCENE-6997
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial
>Reporter: Nicholas Knize
> Fix For: 5.5, trunk
>
> Attachments: LUCENE-6997.patch, LUCENE-6997.patch
>
>
> {{GeoPointField}} is a lightweight dependency-free postings based geo field 
> currently in sandbox. It has evolved into a very fast lightweight geo option 
> that heavily leverages the optimized performance of the postings structure. 
> It was originally intended to graduate to core but this does not seem 
> appropriate given the variety of "built on postings" term encoding options 
> (e.g., see LUCENE-6930).  
> Additionally, the {{Geo*Utils}} classes are dependency free lightweight 
> relational approximation utilities used by both {{GeoPointField}} and the BKD 
> based {{LatLonField}} and can also be applied to benefit the lucene-spatial 
> module.
> These classes have been evolving and baking for some time and are at a 
> maturity level qualifying for promotion from sandbox. This will allow support 
> for experimental encoding methods with (minimal) backwards compatibility - 
> something sandbox does not allow.
> Since GeoPoint classes are dependency free, all GeoPointField and support and 
> utility classes currently in sandbox would be promoted to the spatial3d 
> package. (possibly a separate issue to rename spatial3d to spatialcore or 
> spatiallite?) Such that for basic lightweight Geo support one would only need 
> a handful of lucene jars. By simply adding the lucene-spatial module and its 
> dependency jars users can obtain more advanced geospatial support (heatmap 
> facets, full shape relations, etc).



--
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-6997) Graduate GeoUtils and postings based GeoPointField from sandbox...

[Nicholas Knize (JIRA)]

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

Nicholas Knize updated LUCENE-6997:
---
Labels: blocker  (was: )

> Graduate GeoUtils and postings based GeoPointField from sandbox...
> --
>
> Key: LUCENE-6997
> URL: https://issues.apache.org/jira/browse/LUCENE-6997
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial
>Reporter: Nicholas Knize
> Fix For: 5.5, trunk
>
> Attachments: LUCENE-6997.patch, LUCENE-6997.patch
>
>
> {{GeoPointField}} is a lightweight dependency-free postings based geo field 
> currently in sandbox. It has evolved into a very fast lightweight geo option 
> that heavily leverages the optimized performance of the postings structure. 
> It was originally intended to graduate to core but this does not seem 
> appropriate given the variety of "built on postings" term encoding options 
> (e.g., see LUCENE-6930).  
> Additionally, the {{Geo*Utils}} classes are dependency free lightweight 
> relational approximation utilities used by both {{GeoPointField}} and the BKD 
> based {{LatLonField}} and can also be applied to benefit the lucene-spatial 
> module.
> These classes have been evolving and baking for some time and are at a 
> maturity level qualifying for promotion from sandbox. This will allow support 
> for experimental encoding methods with (minimal) backwards compatibility - 
> something sandbox does not allow.
> Since GeoPoint classes are dependency free, all GeoPointField and support and 
> utility classes currently in sandbox would be promoted to the spatial3d 
> package. (possibly a separate issue to rename spatial3d to spatialcore or 
> spatiallite?) Such that for basic lightweight Geo support one would only need 
> a handful of lucene jars. By simply adding the lucene-spatial module and its 
> dependency jars users can obtain more advanced geospatial support (heatmap 
> facets, full shape relations, etc).



--
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-8648) Support selective clearing up of stored async collection API responses

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-8648:
---
Fix Version/s: Trunk
   5.5

> Support selective clearing up of stored async collection API responses
> --
>
> Key: SOLR-8648
> URL: https://issues.apache.org/jira/browse/SOLR-8648
> Project: Solr
>  Issue Type: New Feature
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Fix For: 5.5, Trunk
>
> Attachments: SOLR-8648.patch, SOLR-8648.patch, SOLR-8648.patch, 
> SOLR-8648.patch
>
>
> The only way to clear up stored collection API responses right now is by 
> sending in '-1' as the request id in the REQUESTSTATUS call. It makes a lot 
> of sense to support selective deletion of stored responses so the ids could 
> be reused.



--
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-7447) Separate Aggregations from ValueSources

[Yonik Seeley (JIRA)]

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

Yonik Seeley updated SOLR-7447:
---
Component/s: (was: faceting)
 Facet Module

> Separate Aggregations from ValueSources
> ---
>
> Key: SOLR-7447
> URL: https://issues.apache.org/jira/browse/SOLR-7447
> Project: Solr
>  Issue Type: Sub-task
>  Components: Facet Module
>Affects Versions: 5.1
>Reporter: Yonik Seeley
> Fix For: 5.2
>
>
> AggValueSource acts as the base class for all metric-type aggregations (like 
> sum, unique, percentile, etc).  It should prob not inherit from ValueSource 
> as it does now.



--
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.7.0_80) - Build # 15522 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/15522/
Java: 32bit/jdk1.7.0_80 -server -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.core.TestNRTOpen.testSharedCores

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

Stack Trace:
java.lang.AssertionError: expected:<3> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([6444A7AFAD933FD3:8247EDE0256512DC]: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.core.TestNRTOpen.testSharedCores(TestNRTOpen.java:116)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11226 lines...]
   [junit4] Suite: org.apache.solr.core.TestNRTOpen
   [junit4]   2> Creating dataDir: 

[jira] [Resolved] (SOLR-8663) Multiple searchers open for a single core causing memory issues

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-8663.
--
Resolution: Invalid

First, please discuss this kind of thing on the user's list and/or the dev list 
before raising a JIRA, we try to keep JIRAs for code changes. You'll get more 
responses faster there.

This is almost certainly a problem in your custom code where you're not 
properly closing searchers. Indeed, when you keep a searcher open it chews up 
memory.

As for the warmup, warming a bunch of searchers at once usually means you're 
opening them too rapidly and is an anti-pattern.

Closing this until we have an indication that this is a Solr issue rather than 
a custom code issue.

> Multiple searchers open for a single core causing memory issues
> ---
>
> Key: SOLR-8663
> URL: https://issues.apache.org/jira/browse/SOLR-8663
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.6
>Reporter: Dhritiman Das
>
> For a single core, we are having multiple searchers open. Although the 
> current searcher points to the latest searcher opened, some old searchers are 
> not getting cleaned up , they are holding their cache and ultimately causing 
> memory issues. 
> Possibly for cores which are taking a lot of time to warmup their cache the 
> replication interval is overlapping with warmup time taken for the last 
> searcher open during last replication.
> However any idea why sometimes old searchers are not getting freed ?
> Ex. Searchers from couple of days back are still seen in Solr console.
> ip:port/solr/admin.html#//plugins/core
> Is there any known bug around this for Solr 4.6 ?
> p.s.: we have custom code extending some Solr components at many places. What 
> I am trying to understand also is what is the best place to start debugging 
> this ?



--
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-8416) The collections create API should return after all replicas are active.

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-8416:
--
Attachment: SOLR-8416.patch

Another patch, I think this is almost read. I punted for now on making it not 
wait for specific failures, there are some annoying complications around error 
reporting atm, but I made some other improvements.

> The collections create API should return after all replicas are active. 
> 
>
> Key: SOLR-8416
> URL: https://issues.apache.org/jira/browse/SOLR-8416
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Michael Sun
>Assignee: Mark Miller
> Attachments: SOLR-8416.patch, SOLR-8416.patch, SOLR-8416.patch, 
> SOLR-8416.patch, SOLR-8416.patch, SOLR-8416.patch
>
>
> Currently the collection creation API returns once all cores are created. In 
> large cluster the cores may not be alive for some period of time after cores 
> are created. For any thing requested during that period, Solr appears 
> unstable and can return failure. Therefore it's better  the collection 
> creation API waits for all cores to become alive and returns after that.



--
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-7019) explore two-phase iteration for GeoPoint query

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7019:


+1


> explore two-phase iteration for GeoPoint query
> --
>
> Key: LUCENE-7019
> URL: https://issues.apache.org/jira/browse/LUCENE-7019
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-7019.patch, LUCENE-7019.patch
>
>
> This query today uses an approximation+confirm approach, but it all happens 
> when you call scorer(), in a termsEnum loop.
> This causes several problems (even after 
> https://issues.apache.org/jira/browse/LUCENE-7018) because it can do too much 
> work, if queries have multiple values since the doc can be "confirmed" more 
> than once.
> I think it would be better to delay this confirmation as much as possible, so 
> that other parts of the query (e.g. other filters, conjunctions, etc) can 
> eliminate checks as well.



--
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-8416) The collections create API should return after all replicas are active.

[Mark Miller (JIRA)]

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

Mark Miller edited comment on SOLR-8416 at 2/9/16 2:39 PM:
---

Another patch, I think this is almost ready. I punted for now on making it not 
wait for specific failures (there are some annoying complications around error 
reporting atm), but I made some other improvements.


was (Author: markrmil...@gmail.com):
Another patch, I think this is almost read. I punted for now on making it not 
wait for specific failures, there are some annoying complications around error 
reporting atm, but I made some other improvements.

> The collections create API should return after all replicas are active. 
> 
>
> Key: SOLR-8416
> URL: https://issues.apache.org/jira/browse/SOLR-8416
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Michael Sun
>Assignee: Mark Miller
> Attachments: SOLR-8416.patch, SOLR-8416.patch, SOLR-8416.patch, 
> SOLR-8416.patch, SOLR-8416.patch, SOLR-8416.patch
>
>
> Currently the collection creation API returns once all cores are created. In 
> large cluster the cores may not be alive for some period of time after cores 
> are created. For any thing requested during that period, Solr appears 
> unstable and can return failure. Therefore it's better  the collection 
> creation API waits for all cores to become alive and returns after that.



--
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_72) - Build # 5476 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/5476/
Java: 32bit/jdk1.8.0_72 -server -XX:+UseConcMarkSweepGC

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([60809F1579237ABB:DA52F06DFA0D94AE]: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:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 16212 lines...]
   [junit4] Suite: 

Re: Jira version tag for master branch

[Jan Høydahl]

Could you do the same to Solr’s JIRA?

We now both have both a “master” and “6.0” version. Which of them should we tag 
“trunk” issues with?

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 3. feb. 2016 kl. 21.26 skrev Ryan Ernst :
> 
> FYI, I just renamed the "Trunk" version to "master", to match what we have 
> now with git. Since it was just a rename, it appears all the existing issues 
> that used Trunk as a fix version are already updated.

[jira] [Commented] (SOLR-8653) Apache Solr page still directs people to Subversion

[JIRA]

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

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

Any comment on this? Should we publish the news story as-is or do anyone have a 
better idea?

> Apache Solr page still directs people to Subversion
> ---
>
> Key: SOLR-8653
> URL: https://issues.apache.org/jira/browse/SOLR-8653
> Project: Solr
>  Issue Type: Bug
>Reporter: Erick Erickson
>
> This page needs to be updated desperately:
> http://lucene.apache.org/solr/resources.html#solr-version-control as it's all 
> about Subversion
> Arguably a bug, but I wouldn't object to it being changed to "improvement"



--
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] (LUCENE-6997) Graduate GeoUtils and postings based GeoPointField from sandbox...

[Nicholas Knize (JIRA)]

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

Nicholas Knize resolved LUCENE-6997.

Resolution: Done
  Assignee: Nicholas Knize

> Graduate GeoUtils and postings based GeoPointField from sandbox...
> --
>
> Key: LUCENE-6997
> URL: https://issues.apache.org/jira/browse/LUCENE-6997
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
> Fix For: 5.5, trunk
>
> Attachments: LUCENE-6997.patch, LUCENE-6997.patch
>
>
> {{GeoPointField}} is a lightweight dependency-free postings based geo field 
> currently in sandbox. It has evolved into a very fast lightweight geo option 
> that heavily leverages the optimized performance of the postings structure. 
> It was originally intended to graduate to core but this does not seem 
> appropriate given the variety of "built on postings" term encoding options 
> (e.g., see LUCENE-6930).  
> Additionally, the {{Geo*Utils}} classes are dependency free lightweight 
> relational approximation utilities used by both {{GeoPointField}} and the BKD 
> based {{LatLonField}} and can also be applied to benefit the lucene-spatial 
> module.
> These classes have been evolving and baking for some time and are at a 
> maturity level qualifying for promotion from sandbox. This will allow support 
> for experimental encoding methods with (minimal) backwards compatibility - 
> something sandbox does not allow.
> Since GeoPoint classes are dependency free, all GeoPointField and support and 
> utility classes currently in sandbox would be promoted to the spatial3d 
> package. (possibly a separate issue to rename spatial3d to spatialcore or 
> spatiallite?) Such that for basic lightweight Geo support one would only need 
> a handful of lucene jars. By simply adding the lucene-spatial module and its 
> dependency jars users can obtain more advanced geospatial support (heatmap 
> facets, full shape relations, etc).



--
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-7015) Refactor spatial module to spatial-extras

[Nicholas Knize (JIRA)]

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

Nicholas Knize updated LUCENE-7015:
---
Labels: blocker  (was: )

> Refactor spatial module to spatial-extras
> -
>
> Key: LUCENE-7015
> URL: https://issues.apache.org/jira/browse/LUCENE-7015
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>  Labels: blocker
> Fix For: 6.0
>
>
> Follow on to LUCENE-6997: non GeoPoint* classes need to be refactored from 
> existing spatial module to a new spatial-extras module. All dev-tools, build 
> and project files will be updated to correctly reference and build the new 
> module.



--
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-7019) explore two-phase iteration for GeoPoint query

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7019:


I think this is a quite nasty performance bug / adversary in the multi valued 
case ... I think we should fix it for 5.5.

> explore two-phase iteration for GeoPoint query
> --
>
> Key: LUCENE-7019
> URL: https://issues.apache.org/jira/browse/LUCENE-7019
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-7019.patch, LUCENE-7019.patch
>
>
> This query today uses an approximation+confirm approach, but it all happens 
> when you call scorer(), in a termsEnum loop.
> This causes several problems (even after 
> https://issues.apache.org/jira/browse/LUCENE-7018) because it can do too much 
> work, if queries have multiple values since the doc can be "confirmed" more 
> than once.
> I think it would be better to delay this confirmation as much as possible, so 
> that other parts of the query (e.g. other filters, conjunctions, etc) can 
> eliminate checks as well.



--
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-8416) The collections create API should return after all replicas are active.

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-8416:
--
Summary: The collections create API should return after all replicas are 
active.   (was: Solr collection creation API should return after all cores are 
alive )

> The collections create API should return after all replicas are active. 
> 
>
> Key: SOLR-8416
> URL: https://issues.apache.org/jira/browse/SOLR-8416
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Michael Sun
>Assignee: Mark Miller
> Attachments: SOLR-8416.patch, SOLR-8416.patch, SOLR-8416.patch, 
> SOLR-8416.patch, SOLR-8416.patch
>
>
> Currently the collection creation API returns once all cores are created. In 
> large cluster the cores may not be alive for some period of time after cores 
> are created. For any thing requested during that period, Solr appears 
> unstable and can return failure. Therefore it's better  the collection 
> creation API waits for all cores to become alive and returns after that.



--
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-Tests-5.x-Java7 - Build # 3961 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/3961/

1 tests failed.
FAILED:  org.apache.solr.search.TestIndexSearcher.testReopen

Error Message:
nothing changed, searcher should be the same expected 
same: was 
not:

Stack Trace:
java.lang.AssertionError: nothing changed, searcher should be the same expected 
same: was 
not:
at 
__randomizedtesting.SeedInfo.seed([71EAFF9264F2CFDC:5DA22E8417CE40FF]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotSame(Assert.java:641)
at org.junit.Assert.assertSame(Assert.java:580)
at 
org.apache.solr.search.TestIndexSearcher.testReopen(TestIndexSearcher.java:134)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 

[jira] [Updated] (SOLR-3141) Deprecate OPTIMIZE command in Solr

[JIRA]

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

Jan Høydahl updated SOLR-3141:
--
Fix Version/s: (was: 4.9)
   5.5

> Deprecate OPTIMIZE command in Solr
> --
>
> Key: SOLR-3141
> URL: https://issues.apache.org/jira/browse/SOLR-3141
> Project: Solr
>  Issue Type: Improvement
>  Components: update
>Affects Versions: 3.5
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>  Labels: force, optimize
> Fix For: 5.5, Trunk
>
> Attachments: SOLR-3141.patch, SOLR-3141.patch, SOLR-3141.patch
>
>
> Background: LUCENE-3454 renames optimize() as forceMerge(). Please read that 
> issue first.
> Now that optimize() is rarely necessary anymore, and renamed in Lucene APIs, 
> what should be done with Solr's ancient optimize command?



--
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-3141) Warn in logs at Optimize (was: Deprecate OPTIMIZE command in Solr)

[JIRA]

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

Jan Høydahl updated SOLR-3141:
--
Summary: Warn in logs at Optimize (was: Deprecate OPTIMIZE command in Solr) 
 (was: Deprecate OPTIMIZE command in Solr)

> Warn in logs at Optimize (was: Deprecate OPTIMIZE command in Solr)
> --
>
> Key: SOLR-3141
> URL: https://issues.apache.org/jira/browse/SOLR-3141
> Project: Solr
>  Issue Type: Improvement
>  Components: update
>Affects Versions: 3.5
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>  Labels: force, optimize
> Fix For: 5.5, Trunk
>
> Attachments: SOLR-3141.patch, SOLR-3141.patch, SOLR-3141.patch
>
>
> Background: LUCENE-3454 renames optimize() as forceMerge(). Please read that 
> issue first.
> Now that optimize() is rarely necessary anymore, and renamed in Lucene APIs, 
> what should be done with Solr's ancient optimize command?



--
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-3141) Warn in logs at Optimize (was: Deprecate OPTIMIZE command in Solr)

[JIRA]

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

Jan Høydahl resolved SOLR-3141.
---
Resolution: Fixed

Warn in log patch committed to master and branch_5x
Issue renamed to reflect this.

Please open a new issue if you want to implement some of the more controversial 
ideas from this JIRA.

> Warn in logs at Optimize (was: Deprecate OPTIMIZE command in Solr)
> --
>
> Key: SOLR-3141
> URL: https://issues.apache.org/jira/browse/SOLR-3141
> Project: Solr
>  Issue Type: Improvement
>  Components: update
>Affects Versions: 3.5
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>  Labels: force, optimize
> Fix For: 5.5, Trunk
>
> Attachments: SOLR-3141.patch, SOLR-3141.patch, SOLR-3141.patch
>
>
> Background: LUCENE-3454 renames optimize() as forceMerge(). Please read that 
> issue first.
> Now that optimize() is rarely necessary anymore, and renamed in Lucene APIs, 
> what should be done with Solr's ancient optimize command?



--
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-7019) explore two-phase iteration for GeoPoint query

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-7019:

Attachment: LUCENE-7019.patch

Here's an initial patch, the tests seem happy.

In order to keep the optimization where we only verify edges, we have to use an 
additional SparseBitSet.

I didn't do any benchmarking yet: i expect that if you benchmark the query in 
isolation, it can only be very slightly slower (since it needs to set another 
bit for those edge terms). But I think it should be much better if e.g. AND'd 
with a termquery or similar.

> explore two-phase iteration for GeoPoint query
> --
>
> Key: LUCENE-7019
> URL: https://issues.apache.org/jira/browse/LUCENE-7019
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-7019.patch
>
>
> This query today uses an approximation+confirm approach, but it all happens 
> when you call scorer(), in a termsEnum loop.
> This causes several problems (even after 
> https://issues.apache.org/jira/browse/LUCENE-7018) because it can do too much 
> work, if queries have multiple values since the doc can be "confirmed" more 
> than once.
> I think it would be better to delay this confirmation as much as possible, so 
> that other parts of the query (e.g. other filters, conjunctions, etc) can 
> eliminate checks as well.



--
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-NightlyTests-trunk - Build # 929 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/929/

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

Error Message:
Timeout occured while waiting response from server at: 
http://127.0.0.1:39508/t_/f

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:39508/t_/f
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:587)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:240)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:229)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.makeRequest(CollectionsAPIDistributedZkTest.java:375)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.deletePartiallyCreatedCollection(CollectionsAPIDistributedZkTest.java:236)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:164)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:964)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:939)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:53)
at 

[jira] [Commented] (SOLR-8621) solrconfig.xml: deprecate/replace with

[ASF subversion and git services (JIRA)]

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

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

Commit e9c90037aaf2f392d7f99a7837abd944a9577e9e in lucene-solr's branch 
refs/heads/master from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e9c9003 ]

SOLR-8621: TestMergePolicyConfig.testTieredMergePolicyConfig now randomly 
chooses between solrconfig-tieredmergepolicy.xml and 
solrconfig-tieredmergepolicyfactory.xml; 
solrconfig-tieredmergepolicyfactory.xml fix so that 
TestMergePolicyConfig.testTieredMergePolicyConfig passes.


> solrconfig.xml: deprecate/replace  with 
> -
>
> Key: SOLR-8621
> URL: https://issues.apache.org/jira/browse/SOLR-8621
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Attachments: SOLR-8621.patch, explicit-merge-auto-set.patch
>
>
> * end-user benefits:*
> * Lucene's UpgradeIndexMergePolicy can be configured in Solr
> * (with SOLR-5730) Lucene's SortingMergePolicy can be configured in Solr
> * customisability: arbitrary merge policies including wrapping/nested merge 
> policies can be created and configured
> *(proposed) roadmap:*
> * solr 5.5 introduces  support
> * solr 5.5(\?) deprecates (but maintains)  support
> * solr 6.0(\?) removes  support 
> +work-in-progress git branch:+ 
> [master-solr-8621|https://github.com/apache/lucene-solr/tree/master-solr-8621]



--
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-8621) solrconfig.xml: deprecate/replace with

[ASF subversion and git services (JIRA)]

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

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

Commit 39fd942514a5474d81a285a3a69f4d2c1dca33c7 in lucene-solr's branch 
refs/heads/branch_5x from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=39fd942 ]

SOLR-8621: TestMergePolicyConfig.testTieredMergePolicyConfig now randomly 
chooses between solrconfig-tieredmergepolicy.xml and 
solrconfig-tieredmergepolicyfactory.xml; 
solrconfig-tieredmergepolicyfactory.xml fix so that 
TestMergePolicyConfig.testTieredMergePolicyConfig passes.


> solrconfig.xml: deprecate/replace  with 
> -
>
> Key: SOLR-8621
> URL: https://issues.apache.org/jira/browse/SOLR-8621
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Attachments: SOLR-8621.patch, explicit-merge-auto-set.patch
>
>
> * end-user benefits:*
> * Lucene's UpgradeIndexMergePolicy can be configured in Solr
> * (with SOLR-5730) Lucene's SortingMergePolicy can be configured in Solr
> * customisability: arbitrary merge policies including wrapping/nested merge 
> policies can be created and configured
> *(proposed) roadmap:*
> * solr 5.5 introduces  support
> * solr 5.5(\?) deprecates (but maintains)  support
> * solr 6.0(\?) removes  support 
> +work-in-progress git branch:+ 
> [master-solr-8621|https://github.com/apache/lucene-solr/tree/master-solr-8621]



--
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_72) - Build # 5609 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5609/
Java: 32bit/jdk1.8.0_72 -client -XX:+UseParallelGC

2 tests failed.
FAILED:  
org.apache.solr.handler.component.SpellCheckComponentTest.testRebuildOnCommit

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([DB3C8B394BBD80C4:9130F65418B123A7]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:754)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:721)
at 
org.apache.solr.handler.component.SpellCheckComponentTest.testRebuildOnCommit(SpellCheckComponentTest.java:267)
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:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//arr[@name='suggestion'][.='lucenejava']
xml response was: 

0336


request 
was:q=lowerfilt:lucenejavt=spellCheckCompRH=true=xml
at 

[jira] [Updated] (SOLR-7341) xjoin - join data from external sources

[Tom Winch (JIRA)]

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

Tom Winch updated SOLR-7341:

Attachment: SOLR-7341.patch-trunk

git patch

> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Tom Winch
>Priority: Minor
> Fix For: 4.10.3, 5.3.1, Trunk
>
> Attachments: SOLR-7341.patch-4_10, SOLR-7341.patch-5_3, 
> SOLR-7341.patch-trunk, SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR 
> results in a query and the SOLR result set to be filtered by the results of 
> an external query. Values from the external results are made available in the 
> SOLR results and may also be used to boost the scores of corresponding 
> documents during the search. The contrib consists of the Java classes 
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and 
> associated classes), which must be configured in solrconfig.xml, and the 
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the 
> user to provide the link between SOLR and the external results source. 
> External results and SOLR documents are matched via a single configurable 
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains 
> these classes and interfaces and should be included in SOLR's class path from 
> solrconfig.xml, as should a JAR containing the user implementations of the 
> previously mentioned interfaces. For example:
> {code:xml}
> 
>   ..
>   
>/>
>   ..
>   
>   
>   ..
> 
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an 
> external source to perform a query (or otherwise collect results). Parameters 
> with prefix ".external." are passed from the SOLR query URL 
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and 
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR 
> search to generate external results, and is passed parameters from the SOLR 
> query URL (as above)
> For example, the implementation might perform queries of an external source 
> based on the 'q' SOLR query URL parameter (in full,  name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults() 
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result 
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending) 
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component, 
> configured in solrconfig.xml and included in one or more SOLR request 
> handlers. There is one XJoin search component per external source, and each 
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves 
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and 
> external results via the join field, adding attributes from the external 
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing 
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR 
> documents and external results
> * external - this parameter set is passed to configure the 
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
>  class="org.apache.solr.search.xjoin.XJoinSearchComponent">
>   test.TestXJoinResultsFactory
>   id
>   
> 1,2,3
>   
> 
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during 
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure 
> it. To properly use the XJoinSearchComponent in a request handler, it must be 
> included at the start and end of the component list, and may be configured 
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults 
> implementation (created by the factory at search time) to be included in the 
> SOLR results
> * fl - a comma-separated list of attributes from results objects (contained 
> in an XJoinResults implementation) to be 

[jira] [Comment Edited] (SOLR-7341) xjoin - join data from external sources

[Tom Winch (JIRA)]

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

Tom Winch edited comment on SOLR-7341 at 2/9/16 1:00 PM:
-

trunk patch is for git; others (remain) for svn


was (Author: tomjon):
git patch

> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Tom Winch
>Priority: Minor
> Fix For: 4.10.3, 5.3.1, Trunk
>
> Attachments: SOLR-7341.patch-4_10, SOLR-7341.patch-5_3, 
> SOLR-7341.patch-trunk, SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR 
> results in a query and the SOLR result set to be filtered by the results of 
> an external query. Values from the external results are made available in the 
> SOLR results and may also be used to boost the scores of corresponding 
> documents during the search. The contrib consists of the Java classes 
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and 
> associated classes), which must be configured in solrconfig.xml, and the 
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the 
> user to provide the link between SOLR and the external results source. 
> External results and SOLR documents are matched via a single configurable 
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains 
> these classes and interfaces and should be included in SOLR's class path from 
> solrconfig.xml, as should a JAR containing the user implementations of the 
> previously mentioned interfaces. For example:
> {code:xml}
> 
>   ..
>   
>/>
>   ..
>   
>   
>   ..
> 
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an 
> external source to perform a query (or otherwise collect results). Parameters 
> with prefix ".external." are passed from the SOLR query URL 
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and 
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR 
> search to generate external results, and is passed parameters from the SOLR 
> query URL (as above)
> For example, the implementation might perform queries of an external source 
> based on the 'q' SOLR query URL parameter (in full,  name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults() 
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result 
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending) 
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component, 
> configured in solrconfig.xml and included in one or more SOLR request 
> handlers. There is one XJoin search component per external source, and each 
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves 
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and 
> external results via the join field, adding attributes from the external 
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing 
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR 
> documents and external results
> * external - this parameter set is passed to configure the 
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
>  class="org.apache.solr.search.xjoin.XJoinSearchComponent">
>   test.TestXJoinResultsFactory
>   id
>   
> 1,2,3
>   
> 
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during 
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure 
> it. To properly use the XJoinSearchComponent in a request handler, it must be 
> included at the start and end of the component list, and may be configured 
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults 
> implementation (created by the factory at search time) to be included in the 
> SOLR results
> * fl 

[jira] [Commented] (SOLR-8621) solrconfig.xml: deprecate/replace with

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-8621:
---

bq. About splitting the work, is there something you prefer to do?

Could I take on the {{solr/core/src/test-files/solr/collection1/conf}} portion 
of the solrconfig.xml changes? It continues from the remaining bits of the 
master-solr-8621 working branch that weren't yet ready to be committed 
alongside the main changes.

bq. BTW, I'll delete the remote tracking branch or this feature. We can create 
a new one if needed. Have you pushed anything more to it?

>From the things pushed late yesterday and not included in the main commit, I 
>have squashed/rebased stuff locally and captured all I need i.e. the 
>master-solr-8621 working branch as-is can be deleted. Not sure if we need or 
>want a new one to replace it?

> solrconfig.xml: deprecate/replace  with 
> -
>
> Key: SOLR-8621
> URL: https://issues.apache.org/jira/browse/SOLR-8621
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Attachments: SOLR-8621.patch, explicit-merge-auto-set.patch
>
>
> * end-user benefits:*
> * Lucene's UpgradeIndexMergePolicy can be configured in Solr
> * (with SOLR-5730) Lucene's SortingMergePolicy can be configured in Solr
> * customisability: arbitrary merge policies including wrapping/nested merge 
> policies can be created and configured
> *(proposed) roadmap:*
> * solr 5.5 introduces  support
> * solr 5.5(\?) deprecates (but maintains)  support
> * solr 6.0(\?) removes  support 
> +work-in-progress git branch:+ 
> [master-solr-8621|https://github.com/apache/lucene-solr/tree/master-solr-8621]



--
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-8621) solrconfig.xml: deprecate/replace with

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-8621:
---

It's great to collaborate on this :-) and I agree if we don't work on the same 
code paths then no need for a remote branch. Yes please, go ahead and delete 
the master-solr-8621 working branch.

Could you take care of the {{solr/contrib}} and {{solr/example}} solrconfig.xml 
changes? And opening the follow-on issue to remove support for 
{{}} in 6.0?

My next steps are to continue on the 
{{core/src/test-files/solr/collection1/conf}} solrconfig.xml changes and in 
parallel with that to rebase SOLR-5730 where a {{SortingMergePolicyFactory}} 
code review would be much appreciated later on.

> solrconfig.xml: deprecate/replace  with 
> -
>
> Key: SOLR-8621
> URL: https://issues.apache.org/jira/browse/SOLR-8621
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Attachments: SOLR-8621.patch, explicit-merge-auto-set.patch
>
>
> * end-user benefits:*
> * Lucene's UpgradeIndexMergePolicy can be configured in Solr
> * (with SOLR-5730) Lucene's SortingMergePolicy can be configured in Solr
> * customisability: arbitrary merge policies including wrapping/nested merge 
> policies can be created and configured
> *(proposed) roadmap:*
> * solr 5.5 introduces  support
> * solr 5.5(\?) deprecates (but maintains)  support
> * solr 6.0(\?) removes  support 
> +work-in-progress git branch:+ 
> [master-solr-8621|https://github.com/apache/lucene-solr/tree/master-solr-8621]



--
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-7016) Solr/Lucene 5.4.1: FastVectorHighlighter still fails with StringIndexOutOfBoundsException

[JIRA]

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

Bjørn Hjelle updated LUCENE-7016:
-
Priority: Minor  (was: Critical)

> Solr/Lucene 5.4.1: FastVectorHighlighter still fails with 
> StringIndexOutOfBoundsException
> -
>
> Key: LUCENE-7016
> URL: https://issues.apache.org/jira/browse/LUCENE-7016
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/highlighter
>Affects Versions: 5.4.1
> Environment: OS X 10.10.5
>Reporter: Bjørn Hjelle
>Priority: Minor
>  Labels: fastvectorhighlighter
>
> I have reported issues with highlighting of EdgeNGram fields in SOLR-7926. 
> As a workaround I now try to use an NGramField and the FastVectorHighlighter, 
> but I often hit the FastVectorHighlighter 
> StringIndexOutOfBoundsException-issue.
> Note that I use luceneMatchVersion="4.3". Without this, the whole term is 
> highlighted, not just the search-term, as I reported in SOLR-7926.
> Any help with this would be highly appreciated! (Or tips on how otherwise to 
> achieve proper highlighting of EdgeNGram and NGram-fields.)
> The issue can easily be reproduced by following these steps: 
> Download and start Solr 5.4.1, create a core:
> -
> $ wget http://apache.uib.no/lucene/solr/5.4.1/solr-5.4.1.tgz
> $ tar xvf solr-5.4.1.tgz
> $ cd solr-5.4.1
> $ bin/solr start -f 
> $ bin/solr create_core -c test -d server/solr/configsets/basic_configs
> (in a second terminal window)
> Add dynamic field and fieldtype to server/solr/test/conf/schema.xml:
> -
>  stored="true" termVectors="true" termPositions="true" termOffsets="true"/>
>   
>   
>   
>   
>maxGramSize="20" luceneMatchVersion="4.3"/>
>   
>   
>   
>   
>   
>   
> 
> Replace existing /select requestHandler in 
> server/solr/test/conf/solrconfig.xml with:
> -
> 
>
>  explicit
>  10
>  name_ngram
>  100%
>  edismax
>  
>   name_ngram
>  
>  *
>  true
>  name_ngram 
>  true
>
>   
>   
> Stop and restart Solr
> ---  
>   
> Create and index this document: 
> --  
> $ more doc.xml 
> 
>   
> 1
> Jan-Ole Pedersen
>   
> 
> $ bin/post -c test doc.xml 
> Execute search: 
> $ curl "http://localhost:8983/solr/test/select?q=jan+ol=json=true;
> {
>   "responseHeader":{
> "status":500,
> "QTime":3,
> "params":{
>   "q":"jan ol",
>   "indent":"true",
>   "wt":"json"}},
>   "response":{"numFound":1,"start":0,"docs":[
>   {
> "id":"1",
> "name_ngram":"Jan-Ole Pedersen",
> "_version_":1525256012582354944}]
>   },
>   "error":{
> "msg":"String index out of range: -6",
> "trace":"java.lang.StringIndexOutOfBoundsException: String index out of 
> range: -6\n\tat java.lang.String.substring(String.java:1954)\n\tat 
> org.apache.lucene.search.vectorhighlight.BaseFragmentsBuilder.makeFragment(BaseFragmentsBuilder.java:180)\n\tat
>  
> org.apache.lucene.search.vectorhighlight.BaseFragmentsBuilder.createFragments(BaseFragmentsBuilder.java:145)\n\tat
>  
> org.apache.lucene.search.vectorhighlight.FastVectorHighlighter.getBestFragments(FastVectorHighlighter.java:187)\n\tat
>  
> org.apache.solr.highlight.DefaultSolrHighlighter.doHighlightingByFastVectorHighlighter(DefaultSolrHighlighter.java:479)\n\tat
>  
> org.apache.solr.highlight.DefaultSolrHighlighter.doHighlighting(DefaultSolrHighlighter.java:426)\n\tat
>  
> org.apache.solr.handler.component.HighlightComponent.process(HighlightComponent.java:143)\n\tat
>  
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:273)\n\tat
>  
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)\n\tat
>  org.apache.solr.core.SolrCore.execute(SolrCore.java:2073)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:658)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:457)\n\tat 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:223)\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:181)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)\n\tat
>  
> 

[jira] [Commented] (LUCENE-7016) Solr/Lucene 5.4.1: FastVectorHighlighter still fails with StringIndexOutOfBoundsException

[JIRA]

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

Bjørn Hjelle commented on LUCENE-7016:
--

I just found out that by using the StandardTokenizerFactory instead of the 
WhitespaceTokenizerFactory, the exception is not raised. I will set the 
priority to minor as this is not an issue for me now.

The exception is still raised when using the WhitespaceTokenizerFactory (on 
both the index and query side), so I will leave the issue open. 

> Solr/Lucene 5.4.1: FastVectorHighlighter still fails with 
> StringIndexOutOfBoundsException
> -
>
> Key: LUCENE-7016
> URL: https://issues.apache.org/jira/browse/LUCENE-7016
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/highlighter
>Affects Versions: 5.4.1
> Environment: OS X 10.10.5
>Reporter: Bjørn Hjelle
>Priority: Critical
>  Labels: fastvectorhighlighter
>
> I have reported issues with highlighting of EdgeNGram fields in SOLR-7926. 
> As a workaround I now try to use an NGramField and the FastVectorHighlighter, 
> but I often hit the FastVectorHighlighter 
> StringIndexOutOfBoundsException-issue.
> Note that I use luceneMatchVersion="4.3". Without this, the whole term is 
> highlighted, not just the search-term, as I reported in SOLR-7926.
> Any help with this would be highly appreciated! (Or tips on how otherwise to 
> achieve proper highlighting of EdgeNGram and NGram-fields.)
> The issue can easily be reproduced by following these steps: 
> Download and start Solr 5.4.1, create a core:
> -
> $ wget http://apache.uib.no/lucene/solr/5.4.1/solr-5.4.1.tgz
> $ tar xvf solr-5.4.1.tgz
> $ cd solr-5.4.1
> $ bin/solr start -f 
> $ bin/solr create_core -c test -d server/solr/configsets/basic_configs
> (in a second terminal window)
> Add dynamic field and fieldtype to server/solr/test/conf/schema.xml:
> -
>  stored="true" termVectors="true" termPositions="true" termOffsets="true"/>
>   
>   
>   
>   
>maxGramSize="20" luceneMatchVersion="4.3"/>
>   
>   
>   
>   
>   
>   
> 
> Replace existing /select requestHandler in 
> server/solr/test/conf/solrconfig.xml with:
> -
> 
>
>  explicit
>  10
>  name_ngram
>  100%
>  edismax
>  
>   name_ngram
>  
>  *
>  true
>  name_ngram 
>  true
>
>   
>   
> Stop and restart Solr
> ---  
>   
> Create and index this document: 
> --  
> $ more doc.xml 
> 
>   
> 1
> Jan-Ole Pedersen
>   
> 
> $ bin/post -c test doc.xml 
> Execute search: 
> $ curl "http://localhost:8983/solr/test/select?q=jan+ol=json=true;
> {
>   "responseHeader":{
> "status":500,
> "QTime":3,
> "params":{
>   "q":"jan ol",
>   "indent":"true",
>   "wt":"json"}},
>   "response":{"numFound":1,"start":0,"docs":[
>   {
> "id":"1",
> "name_ngram":"Jan-Ole Pedersen",
> "_version_":1525256012582354944}]
>   },
>   "error":{
> "msg":"String index out of range: -6",
> "trace":"java.lang.StringIndexOutOfBoundsException: String index out of 
> range: -6\n\tat java.lang.String.substring(String.java:1954)\n\tat 
> org.apache.lucene.search.vectorhighlight.BaseFragmentsBuilder.makeFragment(BaseFragmentsBuilder.java:180)\n\tat
>  
> org.apache.lucene.search.vectorhighlight.BaseFragmentsBuilder.createFragments(BaseFragmentsBuilder.java:145)\n\tat
>  
> org.apache.lucene.search.vectorhighlight.FastVectorHighlighter.getBestFragments(FastVectorHighlighter.java:187)\n\tat
>  
> org.apache.solr.highlight.DefaultSolrHighlighter.doHighlightingByFastVectorHighlighter(DefaultSolrHighlighter.java:479)\n\tat
>  
> org.apache.solr.highlight.DefaultSolrHighlighter.doHighlighting(DefaultSolrHighlighter.java:426)\n\tat
>  
> org.apache.solr.handler.component.HighlightComponent.process(HighlightComponent.java:143)\n\tat
>  
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:273)\n\tat
>  
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)\n\tat
>  org.apache.solr.core.SolrCore.execute(SolrCore.java:2073)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:658)\n\tat 
> 

[jira] [Created] (LUCENE-7019) explore two-phase iteration for GeoPoint query

[Robert Muir (JIRA)]

Robert Muir created LUCENE-7019:
---

 Summary: explore two-phase iteration for GeoPoint query
 Key: LUCENE-7019
 URL: https://issues.apache.org/jira/browse/LUCENE-7019
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir


This query today uses an approximation+confirm approach, but it all happens 
when you call scorer(), in a termsEnum loop.

This causes several problems (even after 
https://issues.apache.org/jira/browse/LUCENE-7018) because it can do too much 
work, if queries have multiple values since the doc can be "confirmed" more 
than once.

I think it would be better to delay this confirmation as much as possible, so 
that other parts of the query (e.g. other filters, conjunctions, etc) can 
eliminate checks as well.



--
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: State of Michigan

[Martin Gainty]

To anyone who is not familiar with financial crisis facing the taxpayers of 
State of Michigan
State of Michigan is attempting to determine how to fix the schools in Detroit 
to restore heat and to fix the areas where snow has collapsed roofs
in schools and caused severe water damage and mildew. The pricetag for fixing 
the Detroit School System will be a minimum of 3.4B 
UShttps://www.mackinac.org/21919
State of Michigan is attempting to determine how to replace the Lead 
Contanimation Water System for the city of Flint MiThe pricetag for fixing the 
City of Flint water system will be a minimum of 1.5B US
This does not budget in providing lifetime care all of the children who are now 
suffering side-effects from drinking lead poisined 
waterhttp://www.wilx.com/home/headlines/Big-difference-on-Flint-fix-price-tag-366248571.html

To anyone that has attempted to collect past due monies.. interest is charged 
to a client when they fall behind in paying their bill..typically terms of 1/10 
net 90 apply which is if you pay me in 10 days I deduct 1% from your bill..if 
you wait 90 days you ADD accrued interest to principal

State of Michigan is in technical bankruptcy because they have insufficient 
funds to meet Detroit School obligation and the Flint Water obligationThe 
governor has called out the National Guard who is now delivering bottled water 
to those in Flint affected by lead poisined water
http://www.detroitnews.com/story/news/politics/2016/01/17/snyder-appeal-obama-flint-disaster-declaration/78944416/
Knowing these facts can you honestly say a Consultants LLC deserves interest on 
any past due amount from the State of Michigan..that is:The consultant needs 
that money more than the child who is sitting in a freezing cold classroom 
because their is no money to turn on heat?The consultant needs that money more 
than the child who is suffering from drinking lead-poisoned water in Flint?
Careful Dude (whatever the term dude means)..the citizens of Michigan are 
listening to your response
Martin 
__ 

   


From: mgai...@hotmail.com
To: dev@lucene.apache.org; bmal...@umich.edu
Subject: RE: LLC expense figures and interest income
Date: Mon, 8 Feb 2016 20:16:39 -0500




$3939  is chump change for professional consultants (whatever thats supposed to 
be) for local 'consultants'waste and fraud here in the commonwealth is measured 
in "millions "does anyone know where the LLC gets $3939  when City of Flint and 
State of Mi are supposedly bankrupt?Martin 
__ 
Son: Dad whats a LLC?
Father: In a consulting LLC when a consultant gets sued they are only 
responsible for an LLC Max Liability 
Son: I dont understand?
Father: Consulting Company LLC makes out like a bandit..the other guy eats 
scrod   
 > Date: Mon, 8 Feb 2016 11:06:02 -0800
> Subject: Re: LLC expense figures and interest income
> From: erickerick...@gmail.com
> To: dev@lucene.apache.org
> 
> Sorry, autocomplete failure. Wish the tax guy's name wasn't Devin.
> 
> Ignore please.
> 
> No way to delete this is there?
> 
> Erick
> 
> On Mon, Feb 8, 2016 at 10:58 AM, Erick Erickson  
> wrote:
> > And one other question from Bernadette.
> >
> > Thanks!
> > Erick
> >
> >
> > -- Forwarded message --
> > From: Bernadette Malinoski 
> > Date: Mon, Feb 8, 2016 at 10:35 AM
> > Subject: LLC expense figures and interest income
> > To: Erick Erickson 
> >
> >
> > So, on form C-EZ Devin has $3939 in expenses
> >
> > QB report has $3517 (see attached)  I think the difference might be
> > the proportion of Devin's professional fees which he was going to
> > allot to the LLC.
> >
> > Also, our UMCU interest for the Workplace Partners account is shown in
> > the attached as Other Income for the LLC.  I believe Devin has just
> > combined that with our other interest bearing accounts on the 1040.
> > That might be exactly where it belongs, but if it needs to go with the
> > business income, it would change the company numbers by just a bit on
> > all the related schedules/forms.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

  

[jira] [Updated] (SOLR-7341) xjoin - join data from external sources

[Tom Winch (JIRA)]

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

Tom Winch updated SOLR-7341:

Affects Version/s: (was: 4.10.3)
Fix Version/s: 4.10.3
   5.3.1

> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Tom Winch
>Priority: Minor
> Fix For: 4.10.3, 5.3.1, Trunk
>
> Attachments: SOLR-7341.patch-4_10, SOLR-7341.patch-5_3, 
> SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR 
> results in a query and the SOLR result set to be filtered by the results of 
> an external query. Values from the external results are made available in the 
> SOLR results and may also be used to boost the scores of corresponding 
> documents during the search. The contrib consists of the Java classes 
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and 
> associated classes), which must be configured in solrconfig.xml, and the 
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the 
> user to provide the link between SOLR and the external results source. 
> External results and SOLR documents are matched via a single configurable 
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains 
> these classes and interfaces and should be included in SOLR's class path from 
> solrconfig.xml, as should a JAR containing the user implementations of the 
> previously mentioned interfaces. For example:
> {code:xml}
> 
>   ..
>   
>/>
>   ..
>   
>   
>   ..
> 
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an 
> external source to perform a query (or otherwise collect results). Parameters 
> with prefix ".external." are passed from the SOLR query URL 
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and 
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR 
> search to generate external results, and is passed parameters from the SOLR 
> query URL (as above)
> For example, the implementation might perform queries of an external source 
> based on the 'q' SOLR query URL parameter (in full,  name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults() 
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result 
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending) 
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component, 
> configured in solrconfig.xml and included in one or more SOLR request 
> handlers. There is one XJoin search component per external source, and each 
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves 
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and 
> external results via the join field, adding attributes from the external 
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing 
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR 
> documents and external results
> * external - this parameter set is passed to configure the 
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
>  class="org.apache.solr.search.xjoin.XJoinSearchComponent">
>   test.TestXJoinResultsFactory
>   id
>   
> 1,2,3
>   
> 
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during 
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure 
> it. To properly use the XJoinSearchComponent in a request handler, it must be 
> included at the start and end of the component list, and may be configured 
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults 
> implementation (created by the factory at search time) to be included in the 
> SOLR results
> * fl - a comma-separated list of attributes from results objects (contained 
> in an XJoinResults 

[jira] [Updated] (LUCENE-7019) explore two-phase iteration for GeoPoint query

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-7019:

Attachment: LUCENE-7019.patch

updated patch that eliminates more checks for e.g. multi-valued cases (by 
inverting the logic to "preapproved" docs).

since here we talk about docs not terms, there is no reason to assume edge 
cases are "abnormal", so it basically just flips the logic.

also rather than hardcoding sparse bitset, i added a crude heuristic to use a 
sparse impl only when the field is sparse, to try to reduce the overhead of 
this change.

> explore two-phase iteration for GeoPoint query
> --
>
> Key: LUCENE-7019
> URL: https://issues.apache.org/jira/browse/LUCENE-7019
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-7019.patch, LUCENE-7019.patch
>
>
> This query today uses an approximation+confirm approach, but it all happens 
> when you call scorer(), in a termsEnum loop.
> This causes several problems (even after 
> https://issues.apache.org/jira/browse/LUCENE-7018) because it can do too much 
> work, if queries have multiple values since the doc can be "confirmed" more 
> than once.
> I think it would be better to delay this confirmation as much as possible, so 
> that other parts of the query (e.g. other filters, conjunctions, etc) can 
> eliminate checks as well.



--
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-7019) explore two-phase iteration for GeoPoint query

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-7019:
--

+1 to use two-phase iteration. The patch looks good.

> explore two-phase iteration for GeoPoint query
> --
>
> Key: LUCENE-7019
> URL: https://issues.apache.org/jira/browse/LUCENE-7019
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-7019.patch, LUCENE-7019.patch
>
>
> This query today uses an approximation+confirm approach, but it all happens 
> when you call scorer(), in a termsEnum loop.
> This causes several problems (even after 
> https://issues.apache.org/jira/browse/LUCENE-7018) because it can do too much 
> work, if queries have multiple values since the doc can be "confirmed" more 
> than once.
> I think it would be better to delay this confirmation as much as possible, so 
> that other parts of the query (e.g. other filters, conjunctions, etc) can 
> eliminate checks as well.



--
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-8621) solrconfig.xml: deprecate/replace with

[Shai Erera (JIRA)]

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

Shai Erera commented on SOLR-8621:
--

[~cpoerschke]: OK so let's do the following:

* Move all solrconfig.xmls to use the new factory, except the legacy ones (used 
for tests). Also, let's mark somehow all the tests/code that we want to remove 
in master, so it will be easier to track.

* Open an issue to remove support for {{}} in 6.0. We can make it 
a blocker for 6.0.

* About the ref guide, I don't think that we work on it via JIRA. Do we modify 
it in confluence directly?

About splitting the work, is there something you prefer to do? If not, I'd 
rather handle the existing solrconfigs than modify the ref guide. You'll 
probably do a better job at it than me ;). I will gladly help with reviews!

Also, if there's anything else you think should be done in the context of this 
issue, or need help with, please let me know!

> solrconfig.xml: deprecate/replace  with 
> -
>
> Key: SOLR-8621
> URL: https://issues.apache.org/jira/browse/SOLR-8621
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Attachments: SOLR-8621.patch, explicit-merge-auto-set.patch
>
>
> * end-user benefits:*
> * Lucene's UpgradeIndexMergePolicy can be configured in Solr
> * (with SOLR-5730) Lucene's SortingMergePolicy can be configured in Solr
> * customisability: arbitrary merge policies including wrapping/nested merge 
> policies can be created and configured
> *(proposed) roadmap:*
> * solr 5.5 introduces  support
> * solr 5.5(\?) deprecates (but maintains)  support
> * solr 6.0(\?) removes  support 
> +work-in-progress git branch:+ 
> [master-solr-8621|https://github.com/apache/lucene-solr/tree/master-solr-8621]



--
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-8621) solrconfig.xml: deprecate/replace with

[Shai Erera (JIRA)]

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

Shai Erera commented on SOLR-8621:
--

bq. Could I take on the

Sure. You lead this, I'm only here to help :). So tell me how can I help more.

bq. Not sure if we need or want a new one to replace it?

For fixing the config xmls, I don't think that we need a branch. If we're not 
collaborating on the same task / code path, no need for a remote branch. If 
that's OK with you, I'll go ahead and delete it.

> solrconfig.xml: deprecate/replace  with 
> -
>
> Key: SOLR-8621
> URL: https://issues.apache.org/jira/browse/SOLR-8621
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Attachments: SOLR-8621.patch, explicit-merge-auto-set.patch
>
>
> * end-user benefits:*
> * Lucene's UpgradeIndexMergePolicy can be configured in Solr
> * (with SOLR-5730) Lucene's SortingMergePolicy can be configured in Solr
> * customisability: arbitrary merge policies including wrapping/nested merge 
> policies can be created and configured
> *(proposed) roadmap:*
> * solr 5.5 introduces  support
> * solr 5.5(\?) deprecates (but maintains)  support
> * solr 6.0(\?) removes  support 
> +work-in-progress git branch:+ 
> [master-solr-8621|https://github.com/apache/lucene-solr/tree/master-solr-8621]



--
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-EA] Lucene-Solr-trunk-Linux (64bit/jdk-9-ea+104) - Build # 15827 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15827/
Java: 64bit/jdk-9-ea+104 -XX:-UseCompressedOops -XX:+UseG1GC 
-XX:-CompactStrings -XX:-UseSuperWord

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

Error Message:
Error from server at http://127.0.0.1:53572/awholynewcollection_0: non ok 
status: 500, message:Server Error

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:53572/awholynewcollection_0: non ok status: 
500, message:Server Error
at 
__randomizedtesting.SeedInfo.seed([F46F9DBF2A70DB9A:7C3BA265848CB662]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:511)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:240)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:229)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:957)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForNon403or404or503(AbstractFullDistribZkTestBase.java:1773)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:723)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:160)
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:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:964)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:939)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

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

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-5.x/1175/

No tests ran.

Build Log:
[...truncated 27721 lines...]
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/build.xml:766: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/build.xml:299: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/lucene/build.xml:420: 
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/lucene/common-build.xml:2273:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/lucene/analysis/build.xml:122:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/lucene/analysis/build.xml:38:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/lucene/common-build.xml:1701:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/lucene/common-build.xml:612:
 Error deploying artifact 'org.apache.lucene:lucene-analyzers-icu:jar': Error 
deploying artifact: Error transferring file

Total time: 11 minutes 3 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[jira] [Updated] (LUCENE-5438) add near-real-time replication

[Michael McCandless (JIRA)]

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

Michael McCandless updated LUCENE-5438:
---
Attachment: LUCENE-5438.patch

Here's the latest applyable patch from the branch.  Tests patch but
not yet precommit... I'll work on it.

I tried to keep the core changes to a minimum (simplified vs previous
iterations), but there were some additions that NRT replication needs,
like asking IW to write deletes to disk on opening the NRT reader.
The changes to SegmentInfos.java are not as scary as they look (just
factoring out methods to read/write from {{IndexInput/Output}} too).

I've marked the new APIs experimental or internal, and put all
the new classes under o.a.l.replication.nrt.

The important classes are {{PrimaryNode}} (you create this on the JVM
that will index documents) and {{ReplicaNode}} (you create that on
other JVMs to receive newly flushed files).  They are both abstract:
you must subclass and implement methods that actually do the work of
moving files, etc.  The tests do this using a simple TCP socket
server.

Both {{PrimaryNode}} and {{ReplicaNode}} expose a {{SearcherManager}},
which you use for searching.  They both have {{commit}} methods.

The primary node uses a merged segment warmer that pre-copies merged
files before letting the local IW cutover.  This way NRT latency isn't
blocked by copying merged files out (normally).  An alternative to
this would be to have the replicas do their own merging, but I think
that gets quite complex.


> add near-real-time replication
> --
>
> Key: LUCENE-5438
> URL: https://issues.apache.org/jira/browse/LUCENE-5438
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/replicator
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 6.0
>
> Attachments: LUCENE-5438.patch, LUCENE-5438.patch, LUCENE-5438.patch, 
> LUCENE-5438.patch
>
>
> Lucene's replication module makes it easy to incrementally sync index
> changes from a master index to any number of replicas, and it
> handles/abstracts all the underlying complexity of holding a
> time-expiring snapshot, finding which files need copying, syncing more
> than one index (e.g., taxo + index), etc.
> But today you must first commit on the master, and then again the
> replica's copied files are fsync'd, because the code operates on
> commit points.  But this isn't "technically" necessary, and it mixes
> up durability and fast turnaround time.
> Long ago we added near-real-time readers to Lucene, for the same
> reason: you shouldn't have to commit just to see the new index
> changes.
> I think we should do the same for replication: allow the new segments
> to be copied out to replica(s), and new NRT readers to be opened, to
> fully decouple committing from visibility.  This way apps can then
> separately choose when to replicate (for freshness), and when to
> commit (for durability).
> I think for some apps this could be a compelling alternative to the
> "re-index all documents on each shard" approach that Solr Cloud /
> ElasticSearch implement today, and it may also mean that the
> transaction log can remain external to / above the cluster.



--
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-8097) Implement a builder pattern for constructing a Solrj client

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-8097:


Thanks for the patch Jason. The patch doesn't apply cleanly on master but I 
tried looking at the patch through the diff file directly and this is a good 
direction to move in. Let's cover other Clients too and I'd leave out Embedded 
for now and tackle that one in the end.

> Implement a builder pattern for constructing a Solrj client
> ---
>
> Key: SOLR-8097
> URL: https://issues.apache.org/jira/browse/SOLR-8097
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Hrishikesh Gadre
>Priority: Minor
> Attachments: SOLR-8097.patch
>
>
> Currently Solrj clients (e.g. CloudSolrClient) supports multiple constructors 
> as follows,
> public CloudSolrClient(String zkHost) 
> public CloudSolrClient(String zkHost, HttpClient httpClient) 
> public CloudSolrClient(Collection zkHosts, String chroot)
> public CloudSolrClient(Collection zkHosts, String chroot, HttpClient 
> httpClient)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders, HttpClient 
> httpClient)
> It is kind of problematic while introducing an additional parameters (since 
> we need to introduce additional constructors). Instead it will be helpful to 
> provide SolrClient Builder which can provide either default values or support 
> overriding specific parameter. 



--
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-8621) solrconfig.xml: deprecate/replace with

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-8621:
---

Hmm, small hiccup re: {{MergePolicyFactory}}'s {{getMergePolicy}} signature. 
The {{SortingMergePolicyFactory}} in SOLR-5730 needs access to the schema with 
the 'obvious' signature change being
{code}
-  public abstract MergePolicy getMergePolicy();
+  public abstract MergePolicy getMergePolicy(IndexSchema schema);
{code}
for the abstract {{MergePolicyFactory}} class and all classes inheriting from 
it.

[~shaie] - would you have any thoughts on this? I'm thinking that changing the 
signature at this point is still okay since  support is not 
yet released and in practice {{SolrIndexConfig.buildMergePolicy(final 
IndexSchema schema)}} is always able to pass the schema to the getMergePolicy 
method.

> solrconfig.xml: deprecate/replace  with 
> -
>
> Key: SOLR-8621
> URL: https://issues.apache.org/jira/browse/SOLR-8621
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Attachments: SOLR-8621.patch, explicit-merge-auto-set.patch
>
>
> * end-user benefits:*
> * Lucene's UpgradeIndexMergePolicy can be configured in Solr
> * (with SOLR-5730) Lucene's SortingMergePolicy can be configured in Solr
> * customisability: arbitrary merge policies including wrapping/nested merge 
> policies can be created and configured
> *(proposed) roadmap:*
> * solr 5.5 introduces  support
> * solr 5.5(\?) deprecates (but maintains)  support
> * solr 6.0(\?) removes  support 
> +work-in-progress git branch:+ 
> [master-solr-8621|https://github.com/apache/lucene-solr/tree/master-solr-8621]



--
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-8534) Add generic support for Collection APIs to be async

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-8534:


Instead of duplicating async code for async why not add another class 
(AsyncCollectionAdminRequest? ) so that the following classes instead directly 
extend the async behavior:
* CollectionAdminRoleRequest
* CreateAlias
* DeleteAlias
* OverseerStatus

The rest looks fine to me.

> Add generic support for Collection APIs to be async
> ---
>
> Key: SOLR-8534
> URL: https://issues.apache.org/jira/browse/SOLR-8534
> Project: Solr
>  Issue Type: Improvement
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Fix For: 5.5, Trunk
>
> Attachments: SOLR-8534.patch, SOLR-8534.patch, SOLR-8534.patch, 
> SOLR-8534.patch, SOLR-8534_solrJ.patch
>
>
> Currently only a handful of Collection API calls support the async parameter. 
> I propose to extended support for async to most APIs.
> The Overseer has a generic support for calls to be async. So we should 
> leverage that and make all commands implemented within the 
> OverseerCollectionMessageHandler to support async



--
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-8653) Apache Solr page still directs people to Subversion

[JIRA]

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

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

Thanks, changes committed.
I have started writing a paragraph on the Wiki about the need to re-fork

> Apache Solr page still directs people to Subversion
> ---
>
> Key: SOLR-8653
> URL: https://issues.apache.org/jira/browse/SOLR-8653
> Project: Solr
>  Issue Type: Bug
>Reporter: Erick Erickson
>
> This page needs to be updated desperately:
> http://lucene.apache.org/solr/resources.html#solr-version-control as it's all 
> about Subversion
> Arguably a bug, but I wouldn't object to it being changed to "improvement"



--
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-5730) make Lucene's SortingMergePolicy and EarlyTerminatingSortingCollector configurable in Solr

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-5730:
---

Resumed rebasing work for this ticket here, 
[jira/solr-5730-master|https://github.com/apache/lucene-solr/tree/jira/solr-5730-master]
 working-branch created (but final commit will still be attached as patch to 
this ticket for consistency and clarity), reviews, comments, etc. welcome as 
always.

(Note that the working-branch commit marked as 
[tentative|https://github.com/apache/lucene-solr/commit/e0b2ebf9c5b9013c8ab2a10717feefd11a101bcb]
 would form part not of SOLR-5730 here but it or something equivalent will be 
committed as part of SOLR-8621.)

> make Lucene's SortingMergePolicy and EarlyTerminatingSortingCollector 
> configurable in Solr
> --
>
> Key: SOLR-5730
> URL: https://issues.apache.org/jira/browse/SOLR-5730
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
>  Labels: blocker
> Fix For: 5.5, master
>
> Attachments: SOLR-5730-part1of2.patch, SOLR-5730-part1of2.patch, 
> SOLR-5730-part2of2.patch, SOLR-5730-part2of2.patch
>
>
> *Example configuration (solrconfig.xml) - corresponding to latest attached 
> patch:*
> {noformat}
> 
>   timestamp desc
> 
> {noformat}
> *Example configuration (solrconfig.xml) - corresponding to current 
> (work-in-progress master-solr-8621) SOLR-8621 efforts:*
> {noformat}
> -
> +
> +  TieredMergePolicyFactory
> +  timestamp desc
> +
> {noformat}
> *Example use (EarlyTerminatingSortingCollector):*
> {noformat}
> =timestamp+desc=true
> {noformat}



--
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-6997) Graduate GeoUtils and postings based GeoPointField from sandbox...

[Nicholas Knize (JIRA)]

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

Nicholas Knize updated LUCENE-6997:
---
Labels: blocker  (was: )

> Graduate GeoUtils and postings based GeoPointField from sandbox...
> --
>
> Key: LUCENE-6997
> URL: https://issues.apache.org/jira/browse/LUCENE-6997
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>  Labels: blocker
> Fix For: 5.5, trunk
>
> Attachments: LUCENE-6997.patch, LUCENE-6997.patch
>
>
> {{GeoPointField}} is a lightweight dependency-free postings based geo field 
> currently in sandbox. It has evolved into a very fast lightweight geo option 
> that heavily leverages the optimized performance of the postings structure. 
> It was originally intended to graduate to core but this does not seem 
> appropriate given the variety of "built on postings" term encoding options 
> (e.g., see LUCENE-6930).  
> Additionally, the {{Geo*Utils}} classes are dependency free lightweight 
> relational approximation utilities used by both {{GeoPointField}} and the BKD 
> based {{LatLonField}} and can also be applied to benefit the lucene-spatial 
> module.
> These classes have been evolving and baking for some time and are at a 
> maturity level qualifying for promotion from sandbox. This will allow support 
> for experimental encoding methods with (minimal) backwards compatibility - 
> something sandbox does not allow.
> Since GeoPoint classes are dependency free, all GeoPointField and support and 
> utility classes currently in sandbox would be promoted to the spatial3d 
> package. (possibly a separate issue to rename spatial3d to spatialcore or 
> spatiallite?) Such that for basic lightweight Geo support one would only need 
> a handful of lucene jars. By simply adding the lucene-spatial module and its 
> dependency jars users can obtain more advanced geospatial support (heatmap 
> facets, full shape relations, etc).



--
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-8621) solrconfig.xml: deprecate/replace with

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-8621:
---

[e0b2ebf9c5b9013c8ab2a10717feefd11a101bcb|https://github.com/apache/lucene-solr/commit/e0b2ebf9c5b9013c8ab2a10717feefd11a101bcb]
 on 
[jira/solr-5730-master|https://github.com/apache/lucene-solr/tree/jira/solr-5730-master]
 working-branch turned out as my preferred way of making the {{IndexSchema}} 
available to {{SortingMergePolicyFactory}} but if the alternative of
{code}
-  public abstract MergePolicy getMergePolicy();
+  public abstract MergePolicy getMergePolicy(IndexSchema schema);
{code}
is considered more suitable then it's something that can be easily changed 
tomorrow/Wednesday. [~shaie] - what do you think?

> solrconfig.xml: deprecate/replace  with 
> -
>
> Key: SOLR-8621
> URL: https://issues.apache.org/jira/browse/SOLR-8621
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Blocker
> Fix For: 5.5, master
>
> Attachments: SOLR-8621.patch, explicit-merge-auto-set.patch
>
>
> * end-user benefits:*
> * Lucene's UpgradeIndexMergePolicy can be configured in Solr
> * (with SOLR-5730) Lucene's SortingMergePolicy can be configured in Solr
> * customisability: arbitrary merge policies including wrapping/nested merge 
> policies can be created and configured
> *(proposed) roadmap:*
> * solr 5.5 introduces  support
> * solr 5.5(\?) deprecates (but maintains)  support
> * solr 6.0(\?) removes  support 
> +work-in-progress summary:+
>  * main code changes have been committed to master and branch_5x
>  * {color:red}further small code change required:{color} MergePolicyFactory 
> constructor or MergePolicyFactory.getMergePolicy method to take IndexSchema 
> argument (e.g. for use by SortingMergePolicyFactory being added under related 
> SOLR-5730)
>  * Solr Reference Guide changes (directly in Confluence?)
>  * changes to remaining solrconfig.xml
>  ** solr/core/src/test-files/solr/collection1/conf - Christine
>  ** solr/contrib
>  ** solr/example
> +open question:+
>  * Do we want to error if luceneMatchVersion >= 5.5 and deprecated 
> mergePolicy/mergeFactor/maxMergeDocs are used? See [~hossman]'s comment on 
> Feb 1st. The code as-is permits mergePolicy irrespective of 
> luceneMatchVersion, I think.



--
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-8665) When using configsets, instanceDir is set to the configset directory

[Shawn Heisey (JIRA)]

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

Shawn Heisey updated SOLR-8665:
---
Attachment: core-directories-with-configsets.png

Screenshot from a user, showing the various directories for a core in the admin 
UI.

> When using configsets, instanceDir is set to the configset directory
> 
>
> Key: SOLR-8665
> URL: https://issues.apache.org/jira/browse/SOLR-8665
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3.1
>Reporter: Shawn Heisey
> Attachments: core-directories-with-configsets.png
>
>
> When configsets are used, the instanceDir for each core is set to the 
> configset directory.  This likely made the feature a lot easier to write, but 
> it causes problems for things like the last index timestamp for the 
> dataimport handler.  Instead of ending up in the parent directory of dataDir, 
> it ends up in the configset directory, which means that all cores using that 
> configset have the same dataimport last index timestamp.
> I'm not sure whether there is anything else that might be affected by the 
> shared instanceDir.



--
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-8665) When using configsets, instanceDir is set to the configset directory

[Shawn Heisey (JIRA)]

Shawn Heisey created SOLR-8665:
--

 Summary: When using configsets, instanceDir is set to the 
configset directory
 Key: SOLR-8665
 URL: https://issues.apache.org/jira/browse/SOLR-8665
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.3.1
Reporter: Shawn Heisey


When configsets are used, the instanceDir for each core is set to the configset 
directory.  This likely made the feature a lot easier to write, but it causes 
problems for things like the last index timestamp for the dataimport handler.  
Instead of ending up in the parent directory of dataDir, it ends up in the 
configset directory, which means that all cores using that configset have the 
same dataimport last index timestamp.

I'm not sure whether there is anything else that might be affected by the 
shared instanceDir.




--
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 (64bit/jdk1.7.0_80) - Build # 15525 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/15525/
Java: 64bit/jdk1.7.0_80 -XX:-UseCompressedOops -XX:+UseG1GC

2 tests failed.
FAILED:  org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test

Error Message:
Could not find a healthy node to handle the request.

Stack Trace:
org.apache.solr.common.SolrException: Could not find a healthy node to handle 
the request.
at 
__randomizedtesting.SeedInfo.seed([A4AB0EA2EFDB02D6:2CFF317841276F2E]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1084)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:482)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:463)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.commit(AbstractFullDistribZkTestBase.java:1504)
at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:214)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:964)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:939)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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 

[jira] [Created] (SOLR-8666) Add header to SearchHandler to indicate whether solr is connection to zk

[Keith Laban (JIRA)]

Keith Laban created SOLR-8666:
-

 Summary: Add header to SearchHandler to indicate whether solr is 
connection to zk
 Key: SOLR-8666
 URL: https://issues.apache.org/jira/browse/SOLR-8666
 Project: Solr
  Issue Type: Improvement
Reporter: Keith Laban


Currently solr update requests error out if a zookeeper check fails, however 
SearchHandler does not do these checks. As a result, if a request is sent to a 
node which should be part of a SolrCloud but is not connected to zookeeper and 
thinks that its Active, it's possible the response is composed of stale data. 

The purpose of this header is to allow the client to decide whether or not the 
result data should be considered valid.

This patch also returns the {{zkConnected}} header in the ping handler to allow 
external health checks to use this information. 

See [SOLR-8599] for an example of when this situation can arise. 



--
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-8466) Add support for UnInvertedField based faceting to FacetComponent

[ASF subversion and git services (JIRA)]

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

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

Commit 93750292c258ca9361a9e3271fb2087be40557ec in lucene-solr's branch 
refs/heads/master from [~mkhludnev]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9375029 ]

SOLR-8466: fixing CHANGES.txt moving to 5.5.0 Features.


> Add support for UnInvertedField based faceting to FacetComponent
> 
>
> Key: SOLR-8466
> URL: https://issues.apache.org/jira/browse/SOLR-8466
> Project: Solr
>  Issue Type: New Feature
>  Components: Facet Module, faceting
>Affects Versions: 5.0, 5.1, 5.2, 5.2.1, 5.3, 5.3.1, 5.4
>Reporter: Jamie Johnson
>Assignee: Mikhail Khludnev
> Attachments: 8466.diff, SOLR-8466-failure.txt, SOLR-8466.patch, 
> SOLR-8466.patch, SOLR-8466.patch, SOLR-8466.patch, SOLR-8466.patch, 
> SOLR-8466.patch
>
>
> The new JSON Faceting API supports building an UnInvertedField to do faceting 
> which would be beneficial to add to Solr FacetComponent.  This would provide 
> additional options to implementors to choose the appropriate method of 
> faceting for their particular use case.



--
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] [Reopened] (LUCENE-6997) Graduate GeoUtils and postings based GeoPointField from sandbox...

[Nicholas Knize (JIRA)]

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

Nicholas Knize reopened LUCENE-6997:


> Graduate GeoUtils and postings based GeoPointField from sandbox...
> --
>
> Key: LUCENE-6997
> URL: https://issues.apache.org/jira/browse/LUCENE-6997
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
> Fix For: 5.5, trunk
>
> Attachments: LUCENE-6997.patch, LUCENE-6997.patch
>
>
> {{GeoPointField}} is a lightweight dependency-free postings based geo field 
> currently in sandbox. It has evolved into a very fast lightweight geo option 
> that heavily leverages the optimized performance of the postings structure. 
> It was originally intended to graduate to core but this does not seem 
> appropriate given the variety of "built on postings" term encoding options 
> (e.g., see LUCENE-6930).  
> Additionally, the {{Geo*Utils}} classes are dependency free lightweight 
> relational approximation utilities used by both {{GeoPointField}} and the BKD 
> based {{LatLonField}} and can also be applied to benefit the lucene-spatial 
> module.
> These classes have been evolving and baking for some time and are at a 
> maturity level qualifying for promotion from sandbox. This will allow support 
> for experimental encoding methods with (minimal) backwards compatibility - 
> something sandbox does not allow.
> Since GeoPoint classes are dependency free, all GeoPointField and support and 
> utility classes currently in sandbox would be promoted to the spatial3d 
> package. (possibly a separate issue to rename spatial3d to spatialcore or 
> spatiallite?) Such that for basic lightweight Geo support one would only need 
> a handful of lucene jars. By simply adding the lucene-spatial module and its 
> dependency jars users can obtain more advanced geospatial support (heatmap 
> facets, full shape relations, etc).



--
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-8466) Add support for UnInvertedField based faceting to FacetComponent

[ASF subversion and git services (JIRA)]

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

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

Commit eac3bb9b32a45e5fc9faa54b372f89e25606a976 in lucene-solr's branch 
refs/heads/master from [~mkhludnev]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=eac3bb9 ]

SOLR-8466: facet.method=uif for UnInvertedField faceting, like it was with 'fc' 
earlier.


> Add support for UnInvertedField based faceting to FacetComponent
> 
>
> Key: SOLR-8466
> URL: https://issues.apache.org/jira/browse/SOLR-8466
> Project: Solr
>  Issue Type: New Feature
>  Components: Facet Module, faceting
>Affects Versions: 5.0, 5.1, 5.2, 5.2.1, 5.3, 5.3.1, 5.4
>Reporter: Jamie Johnson
>Assignee: Mikhail Khludnev
> Attachments: 8466.diff, SOLR-8466-failure.txt, SOLR-8466.patch, 
> SOLR-8466.patch, SOLR-8466.patch, SOLR-8466.patch, SOLR-8466.patch, 
> SOLR-8466.patch
>
>
> The new JSON Faceting API supports building an UnInvertedField to do faceting 
> which would be beneficial to add to Solr FacetComponent.  This would provide 
> additional options to implementors to choose the appropriate method of 
> faceting for their particular use case.



--
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-7015) Refactor spatial module to spatial-extras

[David Smiley (JIRA)]

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

David Smiley updated LUCENE-7015:
-
Component/s: modules/spatial

> Refactor spatial module to spatial-extras
> -
>
> Key: LUCENE-7015
> URL: https://issues.apache.org/jira/browse/LUCENE-7015
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>  Labels: blocker
> Fix For: 6.0
>
>
> Follow on to LUCENE-6997: non GeoPoint* classes need to be refactored from 
> existing spatial module to a new spatial-extras module. All dev-tools, build 
> and project files will be updated to correctly reference and build the new 
> module.



--
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-6997) Graduate GeoUtils and postings based GeoPointField from sandbox...

[Nicholas Knize (JIRA)]

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

Nicholas Knize edited comment on LUCENE-6997 at 2/9/16 9:16 PM:


Updated patch to refactor {{GeoPoint*}} classes from 
{{org.apache.lucene.spatial}} to {{org.apache.lucene.spatial.geopoint}}


was (Author: nknize):
Updated patch to refactor {GeoPoint*} classes from {org.apache.lucene.spatial} 
to {org.apache.lucene.spatial.geopoint}

> Graduate GeoUtils and postings based GeoPointField from sandbox...
> --
>
> Key: LUCENE-6997
> URL: https://issues.apache.org/jira/browse/LUCENE-6997
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>  Labels: blocker
> Fix For: 5.5, trunk
>
> Attachments: LUCENE-6997.patch, LUCENE-6997.patch, LUCENE-6997.patch
>
>
> {{GeoPointField}} is a lightweight dependency-free postings based geo field 
> currently in sandbox. It has evolved into a very fast lightweight geo option 
> that heavily leverages the optimized performance of the postings structure. 
> It was originally intended to graduate to core but this does not seem 
> appropriate given the variety of "built on postings" term encoding options 
> (e.g., see LUCENE-6930).  
> Additionally, the {{Geo*Utils}} classes are dependency free lightweight 
> relational approximation utilities used by both {{GeoPointField}} and the BKD 
> based {{LatLonField}} and can also be applied to benefit the lucene-spatial 
> module.
> These classes have been evolving and baking for some time and are at a 
> maturity level qualifying for promotion from sandbox. This will allow support 
> for experimental encoding methods with (minimal) backwards compatibility - 
> something sandbox does not allow.
> Since GeoPoint classes are dependency free, all GeoPointField and support and 
> utility classes currently in sandbox would be promoted to the spatial3d 
> package. (possibly a separate issue to rename spatial3d to spatialcore or 
> spatiallite?) Such that for basic lightweight Geo support one would only need 
> a handful of lucene jars. By simply adding the lucene-spatial module and its 
> dependency jars users can obtain more advanced geospatial support (heatmap 
> facets, full shape relations, etc).



--
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-6997) Graduate GeoUtils and postings based GeoPointField from sandbox...

[Nicholas Knize (JIRA)]

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

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

Updated patch to refactor {GeoPoint*} classes from {org.apache.lucene.spatial} 
to {org.apache.lucene.spatial.geopoint}

> Graduate GeoUtils and postings based GeoPointField from sandbox...
> --
>
> Key: LUCENE-6997
> URL: https://issues.apache.org/jira/browse/LUCENE-6997
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>  Labels: blocker
> Fix For: 5.5, trunk
>
> Attachments: LUCENE-6997.patch, LUCENE-6997.patch, LUCENE-6997.patch
>
>
> {{GeoPointField}} is a lightweight dependency-free postings based geo field 
> currently in sandbox. It has evolved into a very fast lightweight geo option 
> that heavily leverages the optimized performance of the postings structure. 
> It was originally intended to graduate to core but this does not seem 
> appropriate given the variety of "built on postings" term encoding options 
> (e.g., see LUCENE-6930).  
> Additionally, the {{Geo*Utils}} classes are dependency free lightweight 
> relational approximation utilities used by both {{GeoPointField}} and the BKD 
> based {{LatLonField}} and can also be applied to benefit the lucene-spatial 
> module.
> These classes have been evolving and baking for some time and are at a 
> maturity level qualifying for promotion from sandbox. This will allow support 
> for experimental encoding methods with (minimal) backwards compatibility - 
> something sandbox does not allow.
> Since GeoPoint classes are dependency free, all GeoPointField and support and 
> utility classes currently in sandbox would be promoted to the spatial3d 
> package. (possibly a separate issue to rename spatial3d to spatialcore or 
> spatiallite?) Such that for basic lightweight Geo support one would only need 
> a handful of lucene jars. By simply adding the lucene-spatial module and its 
> dependency jars users can obtain more advanced geospatial support (heatmap 
> facets, full shape relations, etc).



--
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] (LUCENE-7019) explore two-phase iteration for GeoPoint query

[Nicholas Knize (JIRA)]

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

Nicholas Knize resolved LUCENE-7019.

Resolution: Fixed

> explore two-phase iteration for GeoPoint query
> --
>
> Key: LUCENE-7019
> URL: https://issues.apache.org/jira/browse/LUCENE-7019
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial
>Reporter: Robert Muir
> Fix For: 5.5, master
>
> Attachments: LUCENE-7019.patch, LUCENE-7019.patch
>
>
> This query today uses an approximation+confirm approach, but it all happens 
> when you call scorer(), in a termsEnum loop.
> This causes several problems (even after 
> https://issues.apache.org/jira/browse/LUCENE-7018) because it can do too much 
> work, if queries have multiple values since the doc can be "confirmed" more 
> than once.
> I think it would be better to delay this confirmation as much as possible, so 
> that other parts of the query (e.g. other filters, conjunctions, etc) can 
> eliminate checks as well.



--
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-Solaris (multiarch/jdk1.7.0) - Build # 385 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Solaris/385/
Java: multiarch/jdk1.7.0 -d32 -server -XX:+UseConcMarkSweepGC

3 tests failed.
FAILED:  org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test

Error Message:
Could not find a healthy node to handle the request.

Stack Trace:
org.apache.solr.common.SolrException: Could not find a healthy node to handle 
the request.
at 
__randomizedtesting.SeedInfo.seed([89A82D50E3C090C3:1FC128A4D3CFD3B]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1084)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:482)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:463)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.commit(AbstractFullDistribZkTestBase.java:1504)
at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:214)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:964)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:939)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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 

[jira] [Updated] (SOLR-8666) Add header to SearchHandler to indicate whether solr is connection to zk

[Keith Laban (JIRA)]

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

Keith Laban updated SOLR-8666:
--
Attachment: SOLR-8666.patch

Patch added

> Add header to SearchHandler to indicate whether solr is connection to zk
> 
>
> Key: SOLR-8666
> URL: https://issues.apache.org/jira/browse/SOLR-8666
> Project: Solr
>  Issue Type: Improvement
>Reporter: Keith Laban
> Attachments: SOLR-8666.patch
>
>
> Currently solr update requests error out if a zookeeper check fails, however 
> SearchHandler does not do these checks. As a result, if a request is sent to 
> a node which should be part of a SolrCloud but is not connected to zookeeper 
> and thinks that its Active, it's possible the response is composed of stale 
> data. 
> The purpose of this header is to allow the client to decide whether or not 
> the result data should be considered valid.
> This patch also returns the {{zkConnected}} header in the ping handler to 
> allow external health checks to use this information. 
> See [SOLR-8599] for an example of when this situation can arise. 



--
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-7019) explore two-phase iteration for GeoPoint query

[ASF subversion and git services (JIRA)]

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

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

Commit b8f57232f2d3ea2304b530f10576922a665786b2 in lucene-solr's branch 
refs/heads/branch_5_4 from nknize
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b8f5723 ]

LUCENE-7019: add two-phase iteration to GeoPointTermQueryConstantScoreWrapper


> explore two-phase iteration for GeoPoint query
> --
>
> Key: LUCENE-7019
> URL: https://issues.apache.org/jira/browse/LUCENE-7019
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial
>Reporter: Robert Muir
> Fix For: 5.5, master
>
> Attachments: LUCENE-7019.patch, LUCENE-7019.patch
>
>
> This query today uses an approximation+confirm approach, but it all happens 
> when you call scorer(), in a termsEnum loop.
> This causes several problems (even after 
> https://issues.apache.org/jira/browse/LUCENE-7018) because it can do too much 
> work, if queries have multiple values since the doc can be "confirmed" more 
> than once.
> I think it would be better to delay this confirmation as much as possible, so 
> that other parts of the query (e.g. other filters, conjunctions, etc) can 
> eliminate checks as well.



--
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-6997) Graduate GeoUtils and postings based GeoPointField from sandbox...

[Nicholas Knize (JIRA)]

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

Nicholas Knize commented on LUCENE-6997:


+1

bq. With each approach, the Queries can only be used with a particular Field 
implementation.

This definitely warrants an organized package hierarchy. With the existing flat 
structure it implies queries can be used with any document.*Field 
implementation. Good idea, I'll make the change!

> Graduate GeoUtils and postings based GeoPointField from sandbox...
> --
>
> Key: LUCENE-6997
> URL: https://issues.apache.org/jira/browse/LUCENE-6997
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
> Fix For: 5.5, trunk
>
> Attachments: LUCENE-6997.patch, LUCENE-6997.patch
>
>
> {{GeoPointField}} is a lightweight dependency-free postings based geo field 
> currently in sandbox. It has evolved into a very fast lightweight geo option 
> that heavily leverages the optimized performance of the postings structure. 
> It was originally intended to graduate to core but this does not seem 
> appropriate given the variety of "built on postings" term encoding options 
> (e.g., see LUCENE-6930).  
> Additionally, the {{Geo*Utils}} classes are dependency free lightweight 
> relational approximation utilities used by both {{GeoPointField}} and the BKD 
> based {{LatLonField}} and can also be applied to benefit the lucene-spatial 
> module.
> These classes have been evolving and baking for some time and are at a 
> maturity level qualifying for promotion from sandbox. This will allow support 
> for experimental encoding methods with (minimal) backwards compatibility - 
> something sandbox does not allow.
> Since GeoPoint classes are dependency free, all GeoPointField and support and 
> utility classes currently in sandbox would be promoted to the spatial3d 
> package. (possibly a separate issue to rename spatial3d to spatialcore or 
> spatiallite?) Such that for basic lightweight Geo support one would only need 
> a handful of lucene jars. By simply adding the lucene-spatial module and its 
> dependency jars users can obtain more advanced geospatial support (heatmap 
> facets, full shape relations, etc).



--
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-EA] Lucene-Solr-trunk-Linux (32bit/jdk-9-ea+104) - Build # 15822 - Still Failing!

[david.w.smi...@gmail.com]

LOL

On Tue, Feb 9, 2016 at 4:43 AM Uwe Schindler  wrote:

> LOL. If compact string wouldn't have been disabled, I would say: Compact
> String comprumpted(TM) the version :-)
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
> > -Original Message-
> > From: Robert Muir [mailto:rcm...@gmail.com]
> > Sent: Tuesday, February 09, 2016 4:00 AM
> > To: dev@lucene.apache.org
> > Subject: Re: [JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk-9-ea+104) -
> > Build # 15822 - Still Failing!
> >
> > best jvm crash ever.
> >
> > On Mon, Feb 8, 2016 at 9:54 PM, Policeman Jenkins Server
> >  wrote:
> > >[junit4] >>> JVM J2 emitted unexpected output (verbatim) 
> > >[junit4] #
> > >[junit4] # A fatal error has been detected by the Java Runtime
> > Environment:
> > >[junit4] #
> > >[junit4] #  SIGSEGV (0xb) at pc=0x89c03155, pid=14255, tid=14333
> > >[junit4] #
> > >[junit4] # JRE version: ˆ„K÷ +¡àø+¡à  (9.0+104) (build )
> > >[junit4] # Java VM: Java HotSpot(TM) Server VM (9-ea+104-2016-02-03-
> > 214936.javare.4385.nc, mixed mode, tiered, concurrent mark sweep gc,
> > linux-x86)
> > >[junit4] # Problematic frame:
> > >[junit4] # C  0x89c03155
> > >[junit4] #
> > >[junit4] # No core dump will be written. Core dumps have been
> disabled.
> > To enable core dumping, try "ulimit -c unlimited" before starting Java
> again
> > >[junit4] #
> > >[junit4] # An error report file with more information is saved as:
> > >[junit4] # /home/jenkins/workspace/Lucene-Solr-trunk-
> > Linux/lucene/build/codecs/test/J2/hs_err_pid14255.log
> > >[junit4] [thread 15849 also had an error]
> > >[junit4] [thread 14331 also had an error]
> > >[junit4] [thread 14332 also had an error]
> > >[junit4]
> > >[junit4] [error occurred during error reporting , id 0xb]
> > >[junit4]
> > >[junit4] #
> > >[junit4] # If you would like to submit a bug report, please visit:
> > >[junit4] #   http://bugreport.java.com/bugreport/crash.jsp
> > >[junit4] #
> > >[junit4] <<< JVM J2: EOF 
> > >
> >
> > -
> > 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
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

[jira] [Updated] (SOLR-5730) make Lucene's SortingMergePolicy and EarlyTerminatingSortingCollector configurable in Solr

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-5730:
--
Description: 
*Example configuration (solrconfig.xml) - corresponding to current 
[jira/solr-5730-master|https://github.com/apache/lucene-solr/tree/jira/solr-5730-master]
 work-in-progress branch:*
{noformat}
-
+
+  in
+  org.apache.solr.index.TieredMergePolicyFactory
+  timestamp desc
+
{noformat}

*Example use (EarlyTerminatingSortingCollector):*
{noformat}
=timestamp+desc=true
{noformat}

  was:
*Example configuration (solrconfig.xml) - corresponding to latest attached 
patch:*
{noformat}

  timestamp desc

{noformat}

*Example configuration (solrconfig.xml) - corresponding to current 
(work-in-progress master-solr-8621) SOLR-8621 efforts:*
{noformat}
-
+
+  TieredMergePolicyFactory
+  timestamp desc
+
{noformat}

*Example use (EarlyTerminatingSortingCollector):*
{noformat}
=timestamp+desc=true
{noformat}


> make Lucene's SortingMergePolicy and EarlyTerminatingSortingCollector 
> configurable in Solr
> --
>
> Key: SOLR-5730
> URL: https://issues.apache.org/jira/browse/SOLR-5730
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
>  Labels: blocker
> Fix For: 5.5, master
>
> Attachments: SOLR-5730-part1of2.patch, SOLR-5730-part1of2.patch, 
> SOLR-5730-part2of2.patch, SOLR-5730-part2of2.patch
>
>
> *Example configuration (solrconfig.xml) - corresponding to current 
> [jira/solr-5730-master|https://github.com/apache/lucene-solr/tree/jira/solr-5730-master]
>  work-in-progress branch:*
> {noformat}
> -
> +
> +  in
> +  org.apache.solr.index.TieredMergePolicyFactory
> +  timestamp desc
> +
> {noformat}
> *Example use (EarlyTerminatingSortingCollector):*
> {noformat}
> =timestamp+desc=true
> {noformat}



--
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-8621) solrconfig.xml: deprecate/replace with

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-8621:
--
Description: 
* end-user benefits:*
* Lucene's UpgradeIndexMergePolicy can be configured in Solr
* (with SOLR-5730) Lucene's SortingMergePolicy can be configured in Solr
* customisability: arbitrary merge policies including wrapping/nested merge 
policies can be created and configured

*(proposed) roadmap:*
* solr 5.5 introduces  support
* solr 5.5(\?) deprecates (but maintains)  support
* solr 6.0(\?) removes  support 

+work-in-progress summary:+
 * main code changes have been committed to master and branch_5x
 * {color:red}further small code change required:{color} MergePolicyFactory 
constructor or MergePolicyFactory.getMergePolicy method to take IndexSchema 
argument (e.g. for use by SortingMergePolicyFactory being added under related 
SOLR-5730)
 * Solr Reference Guide changes (directly in Confluence?)
 * changes to remaining solrconfig.xml
 ** solr/core/src/test-files/solr/collection1/conf - Christine
 ** solr/contrib
 ** solr/example

+open question:+
 * Do we want to error if luceneMatchVersion >= 5.5 and deprecated 
mergePolicy/mergeFactor/maxMergeDocs are used? See [~hossman]'s comment on Feb 
1st. The code as-is permits mergePolicy irrespective of luceneMatchVersion, I 
think.

  was:
* end-user benefits:*
* Lucene's UpgradeIndexMergePolicy can be configured in Solr
* (with SOLR-5730) Lucene's SortingMergePolicy can be configured in Solr
* customisability: arbitrary merge policies including wrapping/nested merge 
policies can be created and configured

*(proposed) roadmap:*
* solr 5.5 introduces  support
* solr 5.5(\?) deprecates (but maintains)  support
* solr 6.0(\?) removes  support 

+work-in-progress git branch:+ 
[master-solr-8621|https://github.com/apache/lucene-solr/tree/master-solr-8621]



> solrconfig.xml: deprecate/replace  with 
> -
>
> Key: SOLR-8621
> URL: https://issues.apache.org/jira/browse/SOLR-8621
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Attachments: SOLR-8621.patch, explicit-merge-auto-set.patch
>
>
> * end-user benefits:*
> * Lucene's UpgradeIndexMergePolicy can be configured in Solr
> * (with SOLR-5730) Lucene's SortingMergePolicy can be configured in Solr
> * customisability: arbitrary merge policies including wrapping/nested merge 
> policies can be created and configured
> *(proposed) roadmap:*
> * solr 5.5 introduces  support
> * solr 5.5(\?) deprecates (but maintains)  support
> * solr 6.0(\?) removes  support 
> +work-in-progress summary:+
>  * main code changes have been committed to master and branch_5x
>  * {color:red}further small code change required:{color} MergePolicyFactory 
> constructor or MergePolicyFactory.getMergePolicy method to take IndexSchema 
> argument (e.g. for use by SortingMergePolicyFactory being added under related 
> SOLR-5730)
>  * Solr Reference Guide changes (directly in Confluence?)
>  * changes to remaining solrconfig.xml
>  ** solr/core/src/test-files/solr/collection1/conf - Christine
>  ** solr/contrib
>  ** solr/example
> +open question:+
>  * Do we want to error if luceneMatchVersion >= 5.5 and deprecated 
> mergePolicy/mergeFactor/maxMergeDocs are used? See [~hossman]'s comment on 
> Feb 1st. The code as-is permits mergePolicy irrespective of 
> luceneMatchVersion, I think.



--
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-8621) solrconfig.xml: deprecate/replace with

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-8621:
--
Labels: blocker  (was: )

> solrconfig.xml: deprecate/replace  with 
> -
>
> Key: SOLR-8621
> URL: https://issues.apache.org/jira/browse/SOLR-8621
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>  Labels: blocker
> Fix For: 5.5, master
>
> Attachments: SOLR-8621.patch, explicit-merge-auto-set.patch
>
>
> * end-user benefits:*
> * Lucene's UpgradeIndexMergePolicy can be configured in Solr
> * (with SOLR-5730) Lucene's SortingMergePolicy can be configured in Solr
> * customisability: arbitrary merge policies including wrapping/nested merge 
> policies can be created and configured
> *(proposed) roadmap:*
> * solr 5.5 introduces  support
> * solr 5.5(\?) deprecates (but maintains)  support
> * solr 6.0(\?) removes  support 
> +work-in-progress summary:+
>  * main code changes have been committed to master and branch_5x
>  * {color:red}further small code change required:{color} MergePolicyFactory 
> constructor or MergePolicyFactory.getMergePolicy method to take IndexSchema 
> argument (e.g. for use by SortingMergePolicyFactory being added under related 
> SOLR-5730)
>  * Solr Reference Guide changes (directly in Confluence?)
>  * changes to remaining solrconfig.xml
>  ** solr/core/src/test-files/solr/collection1/conf - Christine
>  ** solr/contrib
>  ** solr/example
> +open question:+
>  * Do we want to error if luceneMatchVersion >= 5.5 and deprecated 
> mergePolicy/mergeFactor/maxMergeDocs are used? See [~hossman]'s comment on 
> Feb 1st. The code as-is permits mergePolicy irrespective of 
> luceneMatchVersion, I think.



--
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-7019) explore two-phase iteration for GeoPoint query

[ASF subversion and git services (JIRA)]

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

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

Commit a928e4b40652cad760cf2d596db08370c07dfc2f in lucene-solr's branch 
refs/heads/master from nknize
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a928e4b ]

LUCENE-7019: add two-phase iteration to GeoPointTermQueryConstantScoreWrapper


> explore two-phase iteration for GeoPoint query
> --
>
> Key: LUCENE-7019
> URL: https://issues.apache.org/jira/browse/LUCENE-7019
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial
>Reporter: Robert Muir
> Fix For: 5.5, master
>
> Attachments: LUCENE-7019.patch, LUCENE-7019.patch
>
>
> This query today uses an approximation+confirm approach, but it all happens 
> when you call scorer(), in a termsEnum loop.
> This causes several problems (even after 
> https://issues.apache.org/jira/browse/LUCENE-7018) because it can do too much 
> work, if queries have multiple values since the doc can be "confirmed" more 
> than once.
> I think it would be better to delay this confirmation as much as possible, so 
> that other parts of the query (e.g. other filters, conjunctions, etc) can 
> eliminate checks as well.



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