[jira] [Commented] (SOLR-10097) Migrate Documents to Another Collection

[frank (JIRA)]

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

frank commented on SOLR-10097:
--

where user's list?

> Migrate Documents to Another Collection
> ---
>
> Key: SOLR-10097
> URL: https://issues.apache.org/jira/browse/SOLR-10097
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
> Environment: redhat x86_64
>Reporter: frank
> Fix For: 6.3
>
>
> I have a solr collections on the merger, we would like to ask the next 
> question is as follows I have two collections, c1 and c2,
> C1 colleciton there are 10 data, id is from c1_0 to c1_9,
> C2 colleciton also has 10 data, id is from c2_0 to c2_9,
> I now want to c1 id c1_ format data into the c2, I implemented the following 
> order, it seems no effect, and why?
> I c1 designated in the new router.field=id
> http://localhost:8081/solr/admin/collections?action=CREATE=c1=3=3=3=myconf=id
> I refer to 
> https://cwiki.apache.org/confluence/display/solr/Collections+API#CollectionsAPI-api12
> Solr version 6.3.0
> I have a problem? Or understanding wrong?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-6.x-Linux (64bit/jdk1.8.0_121) - Build # 2793 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2793/
Java: 64bit/jdk1.8.0_121 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

3 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.ForceLeaderTest

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([16422D8DA3B3F29C]:0)


FAILED:  org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([16422D8DA3B3F29C]:0)


FAILED:  org.apache.solr.handler.admin.MBeansHandlerTest.testDiff

Error Message:
expected: but was:

Stack Trace:
org.junit.ComparisonFailure: expected: but 
was:
at 
__randomizedtesting.SeedInfo.seed([16422D8DA3B3F29C:D354E916B305CAFC]:0)
at org.junit.Assert.assertEquals(Assert.java:125)
at org.junit.Assert.assertEquals(Assert.java:147)
at 
org.apache.solr.handler.admin.MBeansHandlerTest.testDiff(MBeansHandlerTest.java:63)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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)

Re: Call for MODERATORs on the dev and java-user mailing lists

[Steve Rowe]

Thanks Aurelian.

I’ve created a JIRA to request the moderator changes: 


Scott (or anybody else interested): if/when you’d like to volunteer to moderate 
one of these mailing lists, please post to that effect on the above JIRA.

--
Steve
www.lucidworks.com

> On Feb 4, 2017, at 12:46 AM, aurelian rosca  wrote:
> 
> i am subscribed to the @dev list now.
> 
> On Fri, Feb 3, 2017 at 10:26 PM, Steve Rowe  wrote:
> 
>> Hi Aurelian,
>> 
>> Your response to the dev@ list required moderation, likely because you’re
>> not subscribed to the dev@ list with the email address you used to
>> respond.  Please first go subscribe to the dev@ list with the email you
>> used to send the message below - see > core/discussion.html#developer-lists> - then let me know when you’ve done
>> that.
>> 
>> You don’t need to be online every day - just make a habit of dealing with
>> the MODERATE emails you get on a regular basis.  The system is set up so
>> that multiple people have the same responsibility, the idea being that one
>> of us will deal with the non-spam in a timely fashion, even though none of
>> us is online all the time.
>> 
>> Thanks!
>> 
>> --
>> Steve
>> www.lucidworks.com
>> 
>>> On Feb 3, 2017, at 3:17 PM, aurelian rosca 
>> wrote:
>>> 
>>> I think i can handle both. I will take a look again next morning about
>>> requirements and i will let you know if I will have questions. Should i
>> be
>>> online each day or just 5days/week.
>>> Pe 03.02.2017 22:07, "Steve Rowe"  a scris:
>>> 
 Great!  We only needed one new volunteer on each of the two lists, so we
 should be all set now.
 
 I’ll go make an INFRA JIRA requesting the moderator changes.
 
 --
 Steve
 www.lucidworks.com
 
> On Feb 3, 2017, at 3:02 PM, aurelian rosca 
 wrote:
> 
> Both.
> Pe 03.02.2017 21:59, "Steve Rowe"  a scris:
> 
>> Thanks Aurelian!
>> 
>> To be clear: are you volunteering to moderate both the dev@ and
 java-user@
>> mailing lists? Or only the java-user@ mailing list?
>> 
>> The only requirement is that you are a subscriber to each list you
>> volunteer to moderate.
>> 
>> --
>> Steve
>> www.lucidworks.com
>> 
>>> On Feb 3, 2017, at 2:17 PM, aurelian rosca 
>> wrote:
>>> 
>>> Seems to be an easy job. I am in.
>>> 
>>> On Feb 3, 2017 9:13 PM, "Steve Rowe"  wrote:
>>> 
 Hello subscribers to dev@l.a.o and java-user@l.a.o:
 
 We need to replace a moderator who no longer wishes to do the job on
>> these
 two mailing lists.
 
 If anyone is interested in being a MODERATOR, please reply back to
 this
 thread.  Being a moderator is really easy, the main chunk of the
 responsibility is just hitting "reply-to all" if you get a message
 with
>> the
 subject MODERATE and the body of the message isn't spam.
 
 More details can be found on the wiki:
>> https://wiki.apache.org/solr/
 MailingListModeratorInfo
 
 --
 Steve
 www.lucidworks.com
 
 
 
>> -
 To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
 For additional commands, e-mail: java-user-h...@lucene.apache.org
 
 
>> 
>> 
>> -
>> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: java-user-h...@lucene.apache.org
>> 
>> 
 
 
 -
 To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
 For additional commands, e-mail: java-user-h...@lucene.apache.org
 
 
>> 
>> 
>> -
>> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: java-user-h...@lucene.apache.org
>> 
>> 


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

Re: Call for MODERATORs on the dev and java-user mailing lists

[aurelian rosca]

i am subscribed to the @dev list now.

On Fri, Feb 3, 2017 at 10:26 PM, Steve Rowe  wrote:

> Hi Aurelian,
>
> Your response to the dev@ list required moderation, likely because you’re
> not subscribed to the dev@ list with the email address you used to
> respond.  Please first go subscribe to the dev@ list with the email you
> used to send the message below - see  core/discussion.html#developer-lists> - then let me know when you’ve done
> that.
>
> You don’t need to be online every day - just make a habit of dealing with
> the MODERATE emails you get on a regular basis.  The system is set up so
> that multiple people have the same responsibility, the idea being that one
> of us will deal with the non-spam in a timely fashion, even though none of
> us is online all the time.
>
> Thanks!
>
> --
> Steve
> www.lucidworks.com
>
> > On Feb 3, 2017, at 3:17 PM, aurelian rosca 
> wrote:
> >
> > I think i can handle both. I will take a look again next morning about
> > requirements and i will let you know if I will have questions. Should i
> be
> > online each day or just 5days/week.
> > Pe 03.02.2017 22:07, "Steve Rowe"  a scris:
> >
> >> Great!  We only needed one new volunteer on each of the two lists, so we
> >> should be all set now.
> >>
> >> I’ll go make an INFRA JIRA requesting the moderator changes.
> >>
> >> --
> >> Steve
> >> www.lucidworks.com
> >>
> >>> On Feb 3, 2017, at 3:02 PM, aurelian rosca 
> >> wrote:
> >>>
> >>> Both.
> >>> Pe 03.02.2017 21:59, "Steve Rowe"  a scris:
> >>>
>  Thanks Aurelian!
> 
>  To be clear: are you volunteering to moderate both the dev@ and
> >> java-user@
>  mailing lists? Or only the java-user@ mailing list?
> 
>  The only requirement is that you are a subscriber to each list you
>  volunteer to moderate.
> 
>  --
>  Steve
>  www.lucidworks.com
> 
> > On Feb 3, 2017, at 2:17 PM, aurelian rosca 
>  wrote:
> >
> > Seems to be an easy job. I am in.
> >
> > On Feb 3, 2017 9:13 PM, "Steve Rowe"  wrote:
> >
> >> Hello subscribers to dev@l.a.o and java-user@l.a.o:
> >>
> >> We need to replace a moderator who no longer wishes to do the job on
>  these
> >> two mailing lists.
> >>
> >> If anyone is interested in being a MODERATOR, please reply back to
> >> this
> >> thread.  Being a moderator is really easy, the main chunk of the
> >> responsibility is just hitting "reply-to all" if you get a message
> >> with
>  the
> >> subject MODERATE and the body of the message isn't spam.
> >>
> >> More details can be found on the wiki:
> https://wiki.apache.org/solr/
> >> MailingListModeratorInfo
> >>
> >> --
> >> Steve
> >> www.lucidworks.com
> >>
> >>
> >> 
> -
> >> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: java-user-h...@lucene.apache.org
> >>
> >>
> 
> 
>  -
>  To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
>  For additional commands, e-mail: java-user-h...@lucene.apache.org
> 
> 
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: java-user-h...@lucene.apache.org
> >>
> >>
>
>
> -
> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-user-h...@lucene.apache.org
>
>

[jira] [Closed] (SOLR-10045) Polygon Error: TopologyException: side location conflict

[David Smiley (JIRA)]

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

David Smiley closed SOLR-10045.
---
Resolution: Not A Problem

> Polygon Error: TopologyException: side location conflict 
> -
>
> Key: SOLR-10045
> URL: https://issues.apache.org/jira/browse/SOLR-10045
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spatial
>Affects Versions: 6.4
> Environment: ubuntu
>Reporter: samur araujo
>Assignee: David Smiley
>  Labels: spatial
>
> Hi all, solr is giving error when the polygon below is provided.
> The corresponding query in postgis does not return error.
> I guess the polygon is correct but JTS is complaining about it. Maybe some 
> parameter to quick fix it should be turned on at query time. 
> To test this issue, please use the polygon in a solr intersect query.
> The full stack-trace is below. 
> POSTGIS QUERY:
> select  geonameid from geoname where 
> ST_Contains(ST_GeomFromText('SRID=4326;MULTIPOLYGON (((32.30749900 
> 35., 32.30322300 35.00627900, 32.30219300 35.00780500, 32.29575000 
> 35.02125200, 32.27494400 35.04652800, 32.27330400 35.05730400, 32.27308300 
> 35.05883400, 32.27622200 35.08499900, 32.27739000 35.08961100, 32.27875100 
> 35.09480700, 32.28125000 35.09838900, 32.28766600 35.09852600, 32.29630700 
> 35.09372300, 32.30083500 35.09119400, 32.32822000 35.06766500, 32.34716800 
> 35.05444300, 32.36441800 35.04505500, 32.38013800 35.04085900, 32.39761000 
> 35.03883400, 32.40680700 35.03886000, 32.42580400 35.04222100, 32.44783400 
> 35.04938900, 32.4700 35.06508300, 32.48119400 35.07188800, 32.49261100 
> 35.08280600, 32.49597200 35.08602900, 32.50686300 35.09994500, 32.52422300 
> 35.13444500, 32.53080400 35.14286000, 32.54022200 35.15008200, 32.5495 
> 35.15719600, 32.55241800 35.16286100, 32.55305500 35.17233300, 32.55625200 
> 35.17433200, 32.56219500 35.17327900, 32.57241800 35.16808300, 32.57619500 
> 35.16869400, 32.57925000 35.16916700, 32.58097100 35.16944500, 32.58375200 
> 35.17050200, 32.60077700 35.17694500, 32.60519400 35.17686100, 32.61086300 
> 35.17677700, 32.61544400 35.17886000, 32.61644400 35.18019500, 32.62302800 
> 35.18891500, 32.62888700 35.18922000, 32.63694400 35.18644300, 32.65591800 
> 35.19411100, 32.66797300 35.19358400, 32.67680700 35.19175000, 32.69352700 
> 35.18502800, 32.71147200 35.18458200, 32.71505700 35.18366600, 32.73430600 
> 35.17863800, 32.7600 35.17780700, 32.74930600 35.17274900, 32.76791800 
> 35.16338700, 32.78491600 35.16033200, 32.80019400 35.15077600, 32.81186300 
> 35.14816700, 32.82375000 35.14255500, 32.83327900 35.14213900, 32.84858300 
> 35.14313900, 32.85455700 35.14527900, 32.87341700 35.15475100, 32.89905500 
> 35.16991800, 32.91033200 35.17661300, 32.91494400 35.18214000, 32.93172100 
> 35.2200, 32.93602800 35.24338900, 32.94211200 35.26694500, 32.94599900 
> 35.29358300, 32.94603000 35.31564000, 32.94352700 35.33736000, 32.94014000 
> 35.34524900, 32.93197300 35.35311100, 32.92986300 35.35897100, 32.93011100 
> 35.36550100, 32.93052700 35.37602600, 32.92911100 35.38744400, 32.92488900 
> 35.39897200, 32.92602900 35.40247300, 32.93452800 35.40127900, 32.95708500 
> 35.39183400, 32.99041700 35.37372200, 33.01625100 35.36166800, 33.02055700 
> 35.36202600, 33.03461100 35.36325100, 33.04089000 35.36194600, 33.05794500 
> 35.35475200, 33.07447100 35.35097100, 33.08872200 35.35141800, 33.09919400 
> 35.35377900, 33.11125200 35.35758200, 33.11927800 35.36280400, 33.12569400 
> 35.36311000, 33.16613800 35.35286000, 33.17822300 35.34977700, 33.22266800 
> 35.35488900, 33.23064000 35.34908300, 33.24366800 35.34738900, 33.24924900 
> 35.34352900, 33.25522200 35.34219400, 33.26564000 35.34544400, 33.27013800 
> 35.34541700, 33.28274900 35.34141500, 33.28802900 35.34191500, 33.29505500 
> 35.34544400, 33.31063800 35.34141500, 33.31758500 35.33961100, 33.34722100 
> 35.33663900, 33.36752700 35.33069600, 33.37966500 35.33308400, 33.40505600 
> 35.33058200, 33.46064000 35.33266800, 33.46213900 35.33230600, 33.46888700 
> 35.33075000, 33.48777800 35.33274800, 33.49741700 35.33525100, 33.51283300 
> 35.33503000, 33.53344300 35.34080500, 33.57466500 35.34425000, 33.61161000 
> 35.35486200, 33.61258300 35.35514100, 33.61883200 35.35355400, 33.62891800 
> 35.35355400, 33.64697300 35.35597200, 33.68272400 35.36580700, 33.70177800 
> 35.37444300, 33.71402700 35.38416700, 33.75102600 35.39963900, 33.77294500 
> 35.40877900, 33.78458400 35.41088900, 33.80305500 35.41122100, 33.82955600 
> 35.40866900, 33.83972200 35.41186100, 33.85691800 35.41027800, 33.89386000 
> 35.41999800, 33.89902900 35.42136000, 33.90047100 35.42174900, 33.9200 
> 35.42861200, 33.95633300 35.43811000, 33.9730 

[jira] [Commented] (SOLR-9914) SimpleFacets: refactor "contains" check into "SubstringBytesRefMatcher" class

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9914:


I don't think SimpleFacets.contains needs to stick around and be deprecated; 
just outright delete it if there are no callers within the codebase.

Otherwise +1; this is a nice generalization.

> SimpleFacets: refactor "contains" check into "SubstringBytesRefMatcher" class
> -
>
> Key: SOLR-9914
> URL: https://issues.apache.org/jira/browse/SOLR-9914
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Jonny Marks
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9914.patch, SOLR-9914.patch
>
>
> This patch refactors the "contains" logic for only including constraints 
> which contain a given substring, into a "BytesRefMatcher" interface and 
> "SubstringBytesRefMatcher" implementation. 
> This allows users to have custom logic for including terms in the filter 
> counts, not only based on substring matches.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7669) Rectangle.fromPolygon could compute smaller bounding boxes

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-7669:
--

It's also true that there tends to be little data out there in the Pacific, and 
thus whoever is searching out there is going to find their searches to be fast 
in general by virtue of that factor.  This is a generalization of course.

> Rectangle.fromPolygon could compute smaller bounding boxes
> --
>
> Key: LUCENE-7669
> URL: https://issues.apache.org/jira/browse/LUCENE-7669
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7669.patch
>
>
> Currently it computes the smallest bounding box that does not cross the 
> dateline. However allowing to cross the dateline could allow to create 
> smaller bounding boxes. For instance, because of that, the bounding box of 
> the Russia polygon has a width of 360 longitude degrees. By allowing 
> rectangles that cross the dateline, we could get a polygon whose width is 
> only 171 longitude degrees. This is useful combined with LUCENE-7661 since it 
> means the grid would have higher resolution.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (SOLR-10097) Migrate Documents to Another Collection

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-10097.
---
Resolution: Not A Problem

Please raise issues like this on the user's list, many more people will see it 
and you'll likely get help much more quickly.

If it's determined that this is a new problem with Solr code, _then_ you should 
raise a JIRA. 

When you do ask on the user's list, you need to add a bit of clarity. You say 
in the title that you want to migrate docs from C1 to C2. But nothing in the 
writeup shows any step where you tried to move the data.

> Migrate Documents to Another Collection
> ---
>
> Key: SOLR-10097
> URL: https://issues.apache.org/jira/browse/SOLR-10097
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
> Environment: redhat x86_64
>Reporter: frank
> Fix For: 6.3
>
>
> I have a solr collections on the merger, we would like to ask the next 
> question is as follows I have two collections, c1 and c2,
> C1 colleciton there are 10 data, id is from c1_0 to c1_9,
> C2 colleciton also has 10 data, id is from c2_0 to c2_9,
> I now want to c1 id c1_ format data into the c2, I implemented the following 
> order, it seems no effect, and why?
> I c1 designated in the new router.field=id
> http://localhost:8081/solr/admin/collections?action=CREATE=c1=3=3=3=myconf=id
> I refer to 
> https://cwiki.apache.org/confluence/display/solr/Collections+API#CollectionsAPI-api12
> Solr version 6.3.0
> I have a problem? Or understanding wrong?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10097) Migrate Documents to Another Collection

[frank (JIRA)]

frank created SOLR-10097:


 Summary: Migrate Documents to Another Collection
 Key: SOLR-10097
 URL: https://issues.apache.org/jira/browse/SOLR-10097
 Project: Solr
  Issue Type: Task
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrCloud
 Environment: redhat x86_64
Reporter: frank
 Fix For: 6.3


I have a solr collections on the merger, we would like to ask the next question 
is as follows I have two collections, c1 and c2,

C1 colleciton there are 10 data, id is from c1_0 to c1_9,

C2 colleciton also has 10 data, id is from c2_0 to c2_9,

I now want to c1 id c1_ format data into the c2, I implemented the following 
order, it seems no effect, and why?

I c1 designated in the new router.field=id

http://localhost:8081/solr/admin/collections?action=CREATE=c1=3=3=3=myconf=id

I refer to 
https://cwiki.apache.org/confluence/display/solr/Collections+API#CollectionsAPI-api12

Solr version 6.3.0

I have a problem? Or understanding wrong?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+153) - Build # 2792 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2792/
Java: 32bit/jdk-9-ea+153 -client -XX:+UseSerialGC

4 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) 
Thread[id=9315, name=searcherExecutor-4359-thread-1, state=WAITING, 
group=TGRP-TestLazyCores] at 
java.base@9-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@9-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:192)
 at 
java.base@9-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062)
 at 
java.base@9-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435)
 at 
java.base@9-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1086)
 at 
java.base@9-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
 at 
java.base@9-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
 at java.base@9-ea/java.lang.Thread.run(Thread.java:844)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.core.TestLazyCores: 
   1) Thread[id=9315, name=searcherExecutor-4359-thread-1, state=WAITING, 
group=TGRP-TestLazyCores]
at java.base@9-ea/jdk.internal.misc.Unsafe.park(Native Method)
at 
java.base@9-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:192)
at 
java.base@9-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062)
at 
java.base@9-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435)
at 
java.base@9-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1086)
at 
java.base@9-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
at 
java.base@9-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base@9-ea/java.lang.Thread.run(Thread.java:844)
at __randomizedtesting.SeedInfo.seed([454E10FAB307D5E]:0)


FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=9315, name=searcherExecutor-4359-thread-1, state=WAITING, 
group=TGRP-TestLazyCores] at 
java.base@9-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@9-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:192)
 at 
java.base@9-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062)
 at 
java.base@9-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435)
 at 
java.base@9-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1086)
 at 
java.base@9-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
 at 
java.base@9-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
 at java.base@9-ea/java.lang.Thread.run(Thread.java:844)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie 
threads that couldn't be terminated:
   1) Thread[id=9315, name=searcherExecutor-4359-thread-1, state=WAITING, 
group=TGRP-TestLazyCores]
at java.base@9-ea/jdk.internal.misc.Unsafe.park(Native Method)
at 
java.base@9-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:192)
at 
java.base@9-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062)
at 
java.base@9-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435)
at 
java.base@9-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1086)
at 
java.base@9-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
at 
java.base@9-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base@9-ea/java.lang.Thread.run(Thread.java:844)
at __randomizedtesting.SeedInfo.seed([454E10FAB307D5E]:0)


FAILED:  org.apache.solr.core.TestLazyCores.testNoCommit

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([454E10FAB307D5E:DB3440DE60171EFB]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:821)
at org.apache.solr.core.TestLazyCores.check10(TestLazyCores.java:794)
at 
org.apache.solr.core.TestLazyCores.testNoCommit(TestLazyCores.java:776)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

[jira] [Commented] (SOLR-6246) Core fails to reload when AnalyzingInfixSuggester is used as a Suggester

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-6246:
--

Thanks [~jefferyyuan] for testing!

> Core fails to reload when AnalyzingInfixSuggester is used as a Suggester
> 
>
> Key: SOLR-6246
> URL: https://issues.apache.org/jira/browse/SOLR-6246
> Project: Solr
>  Issue Type: Sub-task
>  Components: SearchComponents - other
>Affects Versions: 4.8, 4.8.1, 4.9, 5.0, 5.1, 5.2, 5.3, 5.4
>Reporter: Varun Thacker
>Assignee: Steve Rowe
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-6246.patch, SOLR-6246.patch, SOLR-6246-test.patch, 
> SOLR-6246-test.patch, SOLR-6246-test.patch, SOLR-6246-test.patch
>
>
> LUCENE-5477 - added near-real-time suggest building to 
> AnalyzingInfixSuggester. One of the changes that went in was a writer is 
> persisted now to support real time updates via the add() and update() methods.
> When we call Solr's reload command, a new instance of AnalyzingInfixSuggester 
> is created. When trying to create a new writer on the same Directory a lock 
> cannot be obtained and Solr fails to reload the core.
> Also when AnalyzingInfixLookupFactory throws a RuntimeException we should 
> pass along the original message.
> I am not sure what should be the approach to fix it. Should we have a 
> reloadHook where we close the writer?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (LUCENE-7671) Enhance UpgradeIndexMergePolicy with additional options

[Keith Laban (JIRA)]

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

Keith Laban edited comment on LUCENE-7671 at 2/3/17 11:49 PM:
--

Yes, in a nutshell that is my goal. Ultimately I'd like to build a request 
handler in solr that can enable a core to upgrade it's segments without first 
taking it offline or reconfiguring the index writer. When not engaged it should 
have no effect, and when it is engaged it should do minimal work at a time.

The additional bells and whistles of this PR are for backwards compatibility. 

Previous the behavior was:
1) Determine all old segments
2) Ask wrapping merge policy what to do with the old segments
3) Merge segments specified by wrapped merge policy
4) Merge the remaining old segments into a single new segment

Meaning, if you were to upgrade an old index using TierdMergePolicy or similar 
as the wrapped MP and said {{w.forceMerge(Integer.MAX_INT)}}, the TMP would say 
nothing to do, but the UpgradeIndexMergePolicy would then take it upon itself 
to merge everything down into a single segment.

Ideally if {{max number of segments > number of segments}} and the wrapped MP 
is happy, the UIMP should not take it upon itself make any merge decisions and 
only upgrade segments needing upgrade by rewritting each segment.

An additional decision to rely on cascading calls from the IW was chosen so 
that if this was being used as the default MP and an upgrade was in progress, 
old segments could still be candidates for merges issued during a commit.

The idea is loosely based on elasticsearch's ElasticsearchMergePolicy.

There should probably also be support for a Predicate to be passed for 
determining whether the segment should be upgraded (rewritten), then this MP 
can be used for things such as deciding to rewrite segments with a different 
codec.


was (Author: k317h):
Yes, in a nutshell that is my goal. Ultimately I'd like to build a request 
handler in solr that can enable a core to upgrade it's segments without first 
taking it offline or reconfiguring the index writer. When not engaged it should 
have no effect, and when it is engaged it should do minimal work at a time.

The additional bells and whistles of this PR are for backwards compatibility. 

Previous the behavior was:
1) Determine all old segments
2) Ask wrapping merge policy what to do with the old segments
3) Merge segments specified by wrapped merge policy
4) Merge the remaining old segments into a single new segment

Meaning, if you were to upgrade an old index using TierdMergePolicy or similar 
as the wrapped MP and said {{w.forceMerge(Integer.MAX_INT)}}, the TMP would say 
nothing to do, but the UpgradeIndexMergePolicy would then take it upon itself 
to merge everything down into a single segment.

Ideally if {{max number of segments > number of segments}} and the wrapped MP 
is happy, the UIMP should not take it upon itself make any merge decisions and 
only upgrade segments needing upgrade. 

An additional decision to rely on cascading calls from the IW was chosen so 
that if this was being used as the default MP and an upgrade was in progress, 
old segments could still be candidates for merges issued during a commit.

The idea is loosely based on elasticsearch's ElasticsearchMergePolicy.

There should probably also be support for a Predicate to be passed for 
determining whether the segment should be upgraded (rewritten), then this MP 
can be used for things such as deciding to rewrite segments with a different 
codec.

> Enhance UpgradeIndexMergePolicy with additional options
> ---
>
> Key: LUCENE-7671
> URL: https://issues.apache.org/jira/browse/LUCENE-7671
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Keith Laban
>
> Enhance UpgradeIndexMergePolicy to be a MergePolicy that can be used outside 
> the scope the IndexUpgrader.
> The enhancement aims to allow the UpgradeIndexMergePolicy to:
> 1) Delegate normal force merges to the underlying merge policy
> 2) Enable a flag that will explicitly tell UpgradeIndexMergePolicy when it 
> should start looking for upgrades.
> 3) Allow new segments to be considered to be merged with old segments, 
> depending on underlying MergePolicy.
> 4) Be configurable for backwards compatibility such that only segments 
> needing an upgrade would be considered when merging, no explicit upgrades.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7671) Enhance UpgradeIndexMergePolicy with additional options

[Keith Laban (JIRA)]

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

Keith Laban commented on LUCENE-7671:
-

Yes, in a nutshell that is my goal. Ultimately I'd like to build a request 
handler in solr that can enable a core to upgrade it's segments without first 
taking it offline or reconfiguring the index writer. When not engaged it should 
have no effect, and when it is engaged it should do minimal work at a time.

The additional bells and whistles of this PR are for backwards compatibility. 

Previous the behavior was:
1) Determine all old segments
2) Ask wrapping merge policy what to do with the old segments
3) Merge segments specified by wrapped merge policy
4) Merge the remaining old segments into a single new segment

Meaning, if you were to upgrade an old index using TierdMergePolicy or similar 
as the wrapped MP and said {{w.forceMerge(Integer.MAX_INT)}}, the TMP would say 
nothing to do, but the UpgradeIndexMergePolicy would then take it upon itself 
to merge everything down into a single segment.

Ideally if {{max number of segments > number of segments}} and the wrapped MP 
is happy, the UIMP should not take it upon itself make any merge decisions and 
only upgrade segments needing upgrade. 

An additional decision to rely on cascading calls from the IW was chosen so 
that if this was being used as the default MP and an upgrade was in progress, 
old segments could still be candidates for merges issued during a commit.

The idea is loosely based on elasticsearch's ElasticsearchMergePolicy.

There should probably also be support for a Predicate to be passed for 
determining whether the segment should be upgraded (rewritten), then this MP 
can be used for things such as deciding to rewrite segments with a different 
codec.

> Enhance UpgradeIndexMergePolicy with additional options
> ---
>
> Key: LUCENE-7671
> URL: https://issues.apache.org/jira/browse/LUCENE-7671
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Keith Laban
>
> Enhance UpgradeIndexMergePolicy to be a MergePolicy that can be used outside 
> the scope the IndexUpgrader.
> The enhancement aims to allow the UpgradeIndexMergePolicy to:
> 1) Delegate normal force merges to the underlying merge policy
> 2) Enable a flag that will explicitly tell UpgradeIndexMergePolicy when it 
> should start looking for upgrades.
> 3) Allow new segments to be considered to be merged with old segments, 
> depending on underlying MergePolicy.
> 4) Be configurable for backwards compatibility such that only segments 
> needing an upgrade would be considered when merging, no explicit upgrades.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7639) Use Suffix Arrays for fast search with leading asterisks

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7639:


bq. The inverted FST should be smaller than the suffix array and intersecting 
both should be a viable option to get \*abc\* wildcard matches?

Hmm [~dweiss] can you explain more how the infix case (\*abc\*) could be 
handled by the forward and reversed FSTs?

> Use Suffix Arrays for fast search with leading asterisks
> 
>
> Key: LUCENE-7639
> URL: https://issues.apache.org/jira/browse/LUCENE-7639
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Yakov Sirotkin
> Attachments: suffix-array.patch
>
>
> If query term starts with asterisks FST checks all words in the dictionary so 
> request processing speed falls down. This problem can be solved with Suffix 
> Array approach. Luckily, Suffix Array can be constructed after Lucene start 
> from existing index. Unfortunately, Suffix Arrays requires a lot of RAM so we 
> can use it only when special flag is set:
> -Dsolr.suffixArray.enable=true
> It is possible to  speed up Suffix Array initialization using several 
> threads, so we can control number of threads with 
> -Dsolr.suffixArray.initialization_treads_count=5
> This system property can be omitted, the default value is 5.  
> Attached patch is the suggested implementation for SuffixArray support, it 
> works for all terms starting with asterisks with at least 3 consequent 
> non-wildcard characters. This patch do not change search results and  affects 
> only performance issues.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (SOLR-9434) Suggestions failed while spellcheck index build in progress when using AnalyzingInfixSuggester

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-9434.
--
Resolution: Invalid

Seems like suggestions can't be served until the index is built.  Maybe the 
error message could be more explicit or something, but this seems like expected 
behavior to me.

> Suggestions failed while spellcheck index build in progress when using 
> AnalyzingInfixSuggester
> --
>
> Key: SOLR-9434
> URL: https://issues.apache.org/jira/browse/SOLR-9434
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spellchecker
>Affects Versions: 4.6.1
>Reporter: ronak kothari
>
> All the search requests are failing during the window spellcheck index is 
> built while using AnalyzingInfixSuggester
> Observed in Solr 4.6.1
> Reproducible steps:
> 1. Initialized spellcheck component with AnalyzingInfixLookupFactory
> 2. Consider the collection "test_suggest" (if not create one)
> 3. Lets have a dictionary file 'dictionary_a.txt' with size in MBs (~10MB). 
> Each line contains a word (max 20char).
> 4. Now, do the following two things parallel,
>- build the index : GET 
> http://:/solr/test_suggest/suggest_handler?spellcheck.build=true
>- do the search : GET 
> http://:/solr/test_suggest/suggest_handler?q=dr
> Response : All the search requests are failing during the window spellcheck 
> index is built.
> Sample Configuration: 
> 
>   
> suggest_a
>  name="lookupImpl">org.apache.solr.spelling.suggest.fst.AnalyzingInfixLookupFactory
> ./index/analyzingSuggesterIndex_a
> text_general
> ./dictionaries/dictionary_a.txt 
>   
> 
>  class="org.apache.solr.handler.component.SearchHandler">
>   
> true
> suggest
> 30
> true
>   
>   
> suggest
>   
> 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+153) - Build # 18899 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18899/
Java: 64bit/jdk-9-ea+153 -XX:-UseCompressedOops -XX:+UseSerialGC

2 tests failed.
FAILED:  org.apache.solr.handler.admin.TestApiFramework.testFramework

Error Message:


Stack Trace:
java.lang.ExceptionInInitializerError
at 
__randomizedtesting.SeedInfo.seed([79269821F69F96D9:6E505206F04B7AE4]:0)
at 
net.sf.cglib.core.KeyFactory$Generator.generateClass(KeyFactory.java:166)
at 
net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25)
at 
net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:216)
at net.sf.cglib.core.KeyFactory$Generator.create(KeyFactory.java:144)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:116)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:108)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:104)
at net.sf.cglib.proxy.Enhancer.(Enhancer.java:69)
at 
org.easymock.internal.ClassProxyFactory.createEnhancer(ClassProxyFactory.java:259)
at 
org.easymock.internal.ClassProxyFactory.createProxy(ClassProxyFactory.java:174)
at org.easymock.internal.MocksControl.createMock(MocksControl.java:60)
at org.easymock.EasyMock.createMock(EasyMock.java:104)
at 
org.apache.solr.handler.admin.TestCoreAdminApis.getCoreContainerMock(TestCoreAdminApis.java:76)
at 
org.apache.solr.handler.admin.TestApiFramework.testFramework(TestApiFramework.java:59)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:543)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 

[jira] [Resolved] (SOLR-6246) Core fails to reload when AnalyzingInfixSuggester is used as a Suggester

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-6246.
--
   Resolution: Fixed
 Assignee: Steve Rowe
Fix Version/s: master (7.0)
   6.5

> Core fails to reload when AnalyzingInfixSuggester is used as a Suggester
> 
>
> Key: SOLR-6246
> URL: https://issues.apache.org/jira/browse/SOLR-6246
> Project: Solr
>  Issue Type: Sub-task
>  Components: SearchComponents - other
>Affects Versions: 4.8, 4.8.1, 4.9, 5.0, 5.1, 5.2, 5.3, 5.4
>Reporter: Varun Thacker
>Assignee: Steve Rowe
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-6246.patch, SOLR-6246.patch, SOLR-6246-test.patch, 
> SOLR-6246-test.patch, SOLR-6246-test.patch, SOLR-6246-test.patch
>
>
> LUCENE-5477 - added near-real-time suggest building to 
> AnalyzingInfixSuggester. One of the changes that went in was a writer is 
> persisted now to support real time updates via the add() and update() methods.
> When we call Solr's reload command, a new instance of AnalyzingInfixSuggester 
> is created. When trying to create a new writer on the same Directory a lock 
> cannot be obtained and Solr fails to reload the core.
> Also when AnalyzingInfixLookupFactory throws a RuntimeException we should 
> pass along the original message.
> I am not sure what should be the approach to fix it. Should we have a 
> reloadHook where we close the writer?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (SOLR-9435) Un-recoverable state while using AnalyzingInfixLookupFactory with collection RELOAD action

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-9435.
--
   Resolution: Duplicate
 Assignee: Steve Rowe
Fix Version/s: 6.4.1

This issue looks like the same set of problems outlined in SOLR-6246, and fixed 
in Solr 6.4.1 with LUCENE-7564 and LUCENE-7670.

Please reopen if the problem reported here is not fixed as of 6.4.1.

> Un-recoverable state while using AnalyzingInfixLookupFactory with collection 
> RELOAD action
> --
>
> Key: SOLR-9435
> URL: https://issues.apache.org/jira/browse/SOLR-9435
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spellchecker
>Affects Versions: 4.6.1
>Reporter: ronak kothari
>Assignee: Steve Rowe
> Fix For: 6.4.1
>
>
> All search requests fails after few sequiancial of Collection RELOAD requests 
> with using spellcheck component
> with AnalyzingInfixSuggester
> Observed in Solr 4.6.1
> Reproducible steps:
> 1. Initialized spellcheck component with AnalyzingInfixLookupFactory
> 2. Consider the collection "test_suggest" (if not create one)
> 3. Lets have a dictionary file 'dictionary_a.txt' with size in MBs (~20MB). 
> Each line contains a word (max 20char).
> 4. Now, hit the collection reload (or core reload) few times in sequence. 
> (Make sure that your dictionary files is large enough)
>- req (core reload) : GET 
> http://:/solr/admin/cores?action=RELOAD=test_suggest
>or
>- req (collection reload) : GET 
> http://:/solr/admin/collections?action=RELOAD=test_suggest
> 5. do the search : GET 
> http://:/solr/test_suggest/suggest_handler?q=dr
> Response : All the search requests fails.
> Note : Do not turn off buildOnStartup
> Sample Configuration: 
> 
>   
> suggest_a
>  name="lookupImpl">org.apache.solr.spelling.suggest.fst.AnalyzingInfixLookupFactory
> ./index/analyzingSuggesterIndex_a
> text_general
> ./dictionaries/dictionary_a.txt 
> true
>   
> 
>  class="org.apache.solr.handler.component.SearchHandler">
>   
> true
> suggest
> 30
> true
>   
>   
> suggest
>   
> 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-6246) Core fails to reload when AnalyzingInfixSuggester is used as a Suggester

[ASF subversion and git services (JIRA)]

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

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

Commit 7b081e468a97b353a5e096ed69163ee9c3044925 in lucene-solr's branch 
refs/heads/branch_6x from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7b081e4 ]

SOLR-6246: SolrSuggester.build() now throws SolrCoreState.CoreIsClosedException 
when a core reload/shutdown happens; add a random test lookup dictionary with 
configurable size; add {Analyzing,Blended}InfixSuggester reload/build tests; 
add a wrapped-exception expectThrows() variant to LuceneTestCase


> Core fails to reload when AnalyzingInfixSuggester is used as a Suggester
> 
>
> Key: SOLR-6246
> URL: https://issues.apache.org/jira/browse/SOLR-6246
> Project: Solr
>  Issue Type: Sub-task
>  Components: SearchComponents - other
>Affects Versions: 4.8, 4.8.1, 4.9, 5.0, 5.1, 5.2, 5.3, 5.4
>Reporter: Varun Thacker
> Attachments: SOLR-6246.patch, SOLR-6246.patch, SOLR-6246-test.patch, 
> SOLR-6246-test.patch, SOLR-6246-test.patch, SOLR-6246-test.patch
>
>
> LUCENE-5477 - added near-real-time suggest building to 
> AnalyzingInfixSuggester. One of the changes that went in was a writer is 
> persisted now to support real time updates via the add() and update() methods.
> When we call Solr's reload command, a new instance of AnalyzingInfixSuggester 
> is created. When trying to create a new writer on the same Directory a lock 
> cannot be obtained and Solr fails to reload the core.
> Also when AnalyzingInfixLookupFactory throws a RuntimeException we should 
> pass along the original message.
> I am not sure what should be the approach to fix it. Should we have a 
> reloadHook where we close the writer?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-6246) Core fails to reload when AnalyzingInfixSuggester is used as a Suggester

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-6246: SolrSuggester.build() now throws SolrCoreState.CoreIsClosedException 
when a core reload/shutdown happens; add a random test lookup dictionary with 
configurable size; add {Analyzing,Blended}InfixSuggester reload/build tests; 
add a wrapped-exception expectThrows() variant to LuceneTestCase


> Core fails to reload when AnalyzingInfixSuggester is used as a Suggester
> 
>
> Key: SOLR-6246
> URL: https://issues.apache.org/jira/browse/SOLR-6246
> Project: Solr
>  Issue Type: Sub-task
>  Components: SearchComponents - other
>Affects Versions: 4.8, 4.8.1, 4.9, 5.0, 5.1, 5.2, 5.3, 5.4
>Reporter: Varun Thacker
> Attachments: SOLR-6246.patch, SOLR-6246.patch, SOLR-6246-test.patch, 
> SOLR-6246-test.patch, SOLR-6246-test.patch, SOLR-6246-test.patch
>
>
> LUCENE-5477 - added near-real-time suggest building to 
> AnalyzingInfixSuggester. One of the changes that went in was a writer is 
> persisted now to support real time updates via the add() and update() methods.
> When we call Solr's reload command, a new instance of AnalyzingInfixSuggester 
> is created. When trying to create a new writer on the same Directory a lock 
> cannot be obtained and Solr fails to reload the core.
> Also when AnalyzingInfixLookupFactory throws a RuntimeException we should 
> pass along the original message.
> I am not sure what should be the approach to fix it. Should we have a 
> reloadHook where we close the writer?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-6246) Core fails to reload when AnalyzingInfixSuggester is used as a Suggester

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-6246: add CHANGES entry


> Core fails to reload when AnalyzingInfixSuggester is used as a Suggester
> 
>
> Key: SOLR-6246
> URL: https://issues.apache.org/jira/browse/SOLR-6246
> Project: Solr
>  Issue Type: Sub-task
>  Components: SearchComponents - other
>Affects Versions: 4.8, 4.8.1, 4.9, 5.0, 5.1, 5.2, 5.3, 5.4
>Reporter: Varun Thacker
> Attachments: SOLR-6246.patch, SOLR-6246.patch, SOLR-6246-test.patch, 
> SOLR-6246-test.patch, SOLR-6246-test.patch, SOLR-6246-test.patch
>
>
> LUCENE-5477 - added near-real-time suggest building to 
> AnalyzingInfixSuggester. One of the changes that went in was a writer is 
> persisted now to support real time updates via the add() and update() methods.
> When we call Solr's reload command, a new instance of AnalyzingInfixSuggester 
> is created. When trying to create a new writer on the same Directory a lock 
> cannot be obtained and Solr fails to reload the core.
> Also when AnalyzingInfixLookupFactory throws a RuntimeException we should 
> pass along the original message.
> I am not sure what should be the approach to fix it. Should we have a 
> reloadHook where we close the writer?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-6246) Core fails to reload when AnalyzingInfixSuggester is used as a Suggester

[ASF subversion and git services (JIRA)]

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

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

Commit 90b16c6d855c534fda1229f1afe7bc622cd0b7da in lucene-solr's branch 
refs/heads/branch_6x from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=90b16c6 ]

SOLR-6246: add CHANGES entry


> Core fails to reload when AnalyzingInfixSuggester is used as a Suggester
> 
>
> Key: SOLR-6246
> URL: https://issues.apache.org/jira/browse/SOLR-6246
> Project: Solr
>  Issue Type: Sub-task
>  Components: SearchComponents - other
>Affects Versions: 4.8, 4.8.1, 4.9, 5.0, 5.1, 5.2, 5.3, 5.4
>Reporter: Varun Thacker
> Attachments: SOLR-6246.patch, SOLR-6246.patch, SOLR-6246-test.patch, 
> SOLR-6246-test.patch, SOLR-6246-test.patch, SOLR-6246-test.patch
>
>
> LUCENE-5477 - added near-real-time suggest building to 
> AnalyzingInfixSuggester. One of the changes that went in was a writer is 
> persisted now to support real time updates via the add() and update() methods.
> When we call Solr's reload command, a new instance of AnalyzingInfixSuggester 
> is created. When trying to create a new writer on the same Directory a lock 
> cannot be obtained and Solr fails to reload the core.
> Also when AnalyzingInfixLookupFactory throws a RuntimeException we should 
> pass along the original message.
> I am not sure what should be the approach to fix it. Should we have a 
> reloadHook where we close the writer?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7669) Rectangle.fromPolygon could compute smaller bounding boxes

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7669:


It's not a single polygon crossing the date line here right?  (I think we check 
and prevent that).  But rather N polygons in a multi-polygon search, where 
their overall bounding box crosses the dateline.  I do think it is bad that we 
become so slow in this case?  Why should we penalize people searching around 
the Fiji islands :)

> Rectangle.fromPolygon could compute smaller bounding boxes
> --
>
> Key: LUCENE-7669
> URL: https://issues.apache.org/jira/browse/LUCENE-7669
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7669.patch
>
>
> Currently it computes the smallest bounding box that does not cross the 
> dateline. However allowing to cross the dateline could allow to create 
> smaller bounding boxes. For instance, because of that, the bounding box of 
> the Russia polygon has a width of 360 longitude degrees. By allowing 
> rectangles that cross the dateline, we could get a polygon whose width is 
> only 171 longitude degrees. This is useful combined with LUCENE-7661 since it 
> means the grid would have higher resolution.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10091) Support for CDCR using an external queueing service

[Otis Gospodnetic (JIRA)]

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

Otis Gospodnetic commented on SOLR-10091:
-

Would this create a dependency on (specific version of) Kafka?  You may want to 
run that by dev@

> Support for CDCR using an external queueing service
> ---
>
> Key: SOLR-10091
> URL: https://issues.apache.org/jira/browse/SOLR-10091
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 6.x
>Reporter: Oliver Bates
>Priority: Minor
>  Labels: features
>
> The idea is to contribute part of the work presented here:
> https://www.youtube.com/watch?v=83vbY9f3nXA
> Specifically these components:
> - update processor that writes updates to an external queueing service 
> (abstracted by an interface)
> - a Kafka implementation of this interface (that goes into /contrib?) so 
> anyone using kafka can use this "out of the box"
> - a consumer application
> For the consumer application, the idea is an app that's queue-agnostic and 
> then the queue-specific consumer bit is loaded at runtime. In this case, 
> there's a "default" kafka consumer in there as well.
> I'm not exactly sure what the best structure would be for these pieces (the 
> kafka implementations and the general consumer app code), so I'll simply post 
> class definitions here and let the community decide where they should go.
> The core work is finished. I just need to clean it up a bit and convert the 
> tests to fit this repo (right now they're using an external framework).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10064) The Nightly test HdfsCollectionsAPIDistributedZkTest appears to be too fragile.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10064:


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

SOLR-10064: Lower block cache size to fit within default limits.


> The Nightly test HdfsCollectionsAPIDistributedZkTest appears to be too 
> fragile.
> ---
>
> Key: SOLR-10064
> URL: https://issues.apache.org/jira/browse/SOLR-10064
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Mark Miller
>
> HdfsCollectionsAPIDistributedZkTest 73.00% half–cracked 30.00 282.56 @Nightly



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: VOTE: Apache Solr Ref Guide for 6.4

[Steve Rowe]

I’m done.

--
Steve
www.lucidworks.com

> On Feb 3, 2017, at 5:52 PM, Cassandra Targett  wrote:
> 
> Thanks guys for your reviews and fixing the small issues you see as you go.
> 
> Steve, let me know when you've fixed those issues, and I'll respin and
> put up a new RC.
> 
> On Fri, Feb 3, 2017 at 4:09 PM, Steve Rowe  wrote:
>> On page 345, there is a table that is missing content because it’s truncated 
>> on the right (a column is missing), under:
>> 
>> https://cwiki.apache.org/confluence/display/solr/Learning+To+Rank | Concepts 
>> | Training | Feature engineering
>> 
>> I found several other minor problems, but missing info as above seems worthy 
>> of respin.  Sorry I didn’t look earlier.  I’ll go make edits now.
>> 
>> --
>> Steve
>> www.lucidworks.com
>> 
>>> On Feb 3, 2017, at 1:43 PM, Tomás Fernández Löbbe  
>>> wrote:
>>> 
>>> +1 eyeballed all the pages and read some random sections.
>>> Two minor things I caught (not for respin), some of the examples in LTR for 
>>> some reason are very narrow (pages 355 to 365).
>>> We still talk about DismaxRequestHandler in "Overview of Searching in 
>>> Solr", and we even say it's the default. I'll go and change it now.
>>> 
>>> 
>>> 
>>> On Wed, Feb 1, 2017 at 7:11 AM, Joel Bernstein  wrote:
>>> +1. I reviewed the changes to the Streaming Expressions docs. They look 
>>> good.
>>> 
>>> Joel Bernstein
>>> http://joelsolr.blogspot.com/
>>> 
>>> On Tue, Jan 31, 2017 at 11:40 PM, David Smiley  
>>> wrote:
>>> +1 from me.  I reviewed the Highlighting section specifically and found a 
>>> small error (fixed in Confluence just now) but not enough to warrant a 
>>> respin IMO.
>>> 
>>> On Tue, Jan 31, 2017 at 10:44 AM Cassandra Targett  
>>> wrote:
>>> Please vote to release the Apache Solr Ref Guide for Solr 6.4.
>>> 
>>> Artifacts can be found at:
>>> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-6.4-RC0/
>>> 
>>> $ cat apache-solr-ref-guide-6.4-RC0/apache-solr-ref-guide-6.4.pdf.sha1
>>> 2e5f27c1aae36fde5717dd01a4495c5e299c9407  apache-solr-ref-guide-6.4.pdf
>>> 
>>> I'm not a huge fan of releasing with issues found at the last minute
>>> such as the one Erick E filed last night (SOLR-10061, about issues
>>> with the CoreAdmin API docs), but in this case I have a bunch of other
>>> stuff to do this week & next at the day job, I don't know the
>>> CoreAdmin API that well, and when SOLR-8029 (v2 API) is backported to
>>> 6.x, we will likely revamp ALL of the API pages, including that one.
>>> 
>>> So, that said, here's +1 from me.
>>> 
>>> Cassandra
>>> 
>>> -
>>> 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
>>> 
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

[jira] [Commented] (SOLR-10053) TestSolrCloudWithDelegationTokens failures

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-10053:
---

Github user hgadre closed the pull request at:

https://github.com/apache/lucene-solr/pull/150


> TestSolrCloudWithDelegationTokens failures
> --
>
> Key: SOLR-10053
> URL: https://issues.apache.org/jira/browse/SOLR-10053
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
> Attachments: fail.log, stdout, stdout, stdout
>
>
> The TestSolrCloudWithDelegationTokens tests fail often at Jenkins. I have 
> been so far unable to reproduce them using the failing seeds. However, 
> beasting these tests seem to cause failures (once after about 10-12 runs).
> Latest Jenkins failure: 
> https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.4/12/
> It wasn't apparent what caused these failures. To cut down the noise on 
> Jenkins, I propose that we disable the test with @AwaitsFix (or bad apple) 
> annotation and continue to debug and fix this test.
> WDYT, [~markrmil...@gmail.com]?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[GitHub] lucene-solr pull request #150: [SOLR-10053] Ignore delegation token cancelat...

[hgadre]

Github user hgadre closed the pull request at:

https://github.com/apache/lucene-solr/pull/150


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Commented] (LUCENE-7671) Enhance UpgradeIndexMergePolicy with additional options

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7671:


Can you describe the overall goal/use case here?  E.g. is the goal to reshape 
{{UpgradeIndexMergePolicy}} so that you can use it indefinitely as the merge 
policy for your {{IndexWriter}}?

> Enhance UpgradeIndexMergePolicy with additional options
> ---
>
> Key: LUCENE-7671
> URL: https://issues.apache.org/jira/browse/LUCENE-7671
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Keith Laban
>
> Enhance UpgradeIndexMergePolicy to be a MergePolicy that can be used outside 
> the scope the IndexUpgrader.
> The enhancement aims to allow the UpgradeIndexMergePolicy to:
> 1) Delegate normal force merges to the underlying merge policy
> 2) Enable a flag that will explicitly tell UpgradeIndexMergePolicy when it 
> should start looking for upgrades.
> 3) Allow new segments to be considered to be merged with old segments, 
> depending on underlying MergePolicy.
> 4) Be configurable for backwards compatibility such that only segments 
> needing an upgrade would be considered when merging, no explicit upgrades.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: VOTE: Apache Solr Ref Guide for 6.4

[Cassandra Targett]

Thanks guys for your reviews and fixing the small issues you see as you go.

Steve, let me know when you've fixed those issues, and I'll respin and
put up a new RC.

On Fri, Feb 3, 2017 at 4:09 PM, Steve Rowe  wrote:
> On page 345, there is a table that is missing content because it’s truncated 
> on the right (a column is missing), under:
>
> https://cwiki.apache.org/confluence/display/solr/Learning+To+Rank | Concepts 
> | Training | Feature engineering
>
> I found several other minor problems, but missing info as above seems worthy 
> of respin.  Sorry I didn’t look earlier.  I’ll go make edits now.
>
> --
> Steve
> www.lucidworks.com
>
>> On Feb 3, 2017, at 1:43 PM, Tomás Fernández Löbbe  
>> wrote:
>>
>> +1 eyeballed all the pages and read some random sections.
>> Two minor things I caught (not for respin), some of the examples in LTR for 
>> some reason are very narrow (pages 355 to 365).
>> We still talk about DismaxRequestHandler in "Overview of Searching in Solr", 
>> and we even say it's the default. I'll go and change it now.
>>
>>
>>
>> On Wed, Feb 1, 2017 at 7:11 AM, Joel Bernstein  wrote:
>> +1. I reviewed the changes to the Streaming Expressions docs. They look good.
>>
>> Joel Bernstein
>> http://joelsolr.blogspot.com/
>>
>> On Tue, Jan 31, 2017 at 11:40 PM, David Smiley  
>> wrote:
>> +1 from me.  I reviewed the Highlighting section specifically and found a 
>> small error (fixed in Confluence just now) but not enough to warrant a 
>> respin IMO.
>>
>> On Tue, Jan 31, 2017 at 10:44 AM Cassandra Targett  
>> wrote:
>> Please vote to release the Apache Solr Ref Guide for Solr 6.4.
>>
>> Artifacts can be found at:
>> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-6.4-RC0/
>>
>> $ cat apache-solr-ref-guide-6.4-RC0/apache-solr-ref-guide-6.4.pdf.sha1
>> 2e5f27c1aae36fde5717dd01a4495c5e299c9407  apache-solr-ref-guide-6.4.pdf
>>
>> I'm not a huge fan of releasing with issues found at the last minute
>> such as the one Erick E filed last night (SOLR-10061, about issues
>> with the CoreAdmin API docs), but in this case I have a bunch of other
>> stuff to do this week & next at the day job, I don't know the
>> CoreAdmin API that well, and when SOLR-8029 (v2 API) is backported to
>> 6.x, we will likely revamp ALL of the API pages, including that one.
>>
>> So, that said, here's +1 from me.
>>
>> Cassandra
>>
>> -
>> 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
>>
>>
>
>
> -
> 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] (SOLR-10036) Revise jackson-core version from 2.5.4 to latest

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-10036:
-

Tests passed as soon as I stopped using root. :)

> Revise jackson-core version from 2.5.4 to latest
> 
>
> Key: SOLR-10036
> URL: https://issues.apache.org/jira/browse/SOLR-10036
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Shashank Pedamallu
> Attachments: SOLR-10036.patch
>
>
> The current jackson-core dependency in Solr is not compatible with Amazon AWS 
> S3 dependency. AWS S3 requires jackson-core-2.6.6 while Solr uses 
> jackson-core-dependency-2.5.4. This is blocking the usage of latest updates 
> from S3.
> It would be greatly helpful if someone could revise the jackson-core jar in 
> Solr to the latest version. This is a ShowStopper for our Public company.
> Details of my Setup:
> Solr Version: 6.3
> AWS SDK version: 1.11.76



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: VOTE: Apache Solr Ref Guide for 6.4

[Steve Rowe]

On page 345, there is a table that is missing content because it’s truncated on 
the right (a column is missing), under: 

https://cwiki.apache.org/confluence/display/solr/Learning+To+Rank | Concepts | 
Training | Feature engineering

I found several other minor problems, but missing info as above seems worthy of 
respin.  Sorry I didn’t look earlier.  I’ll go make edits now.

--
Steve
www.lucidworks.com

> On Feb 3, 2017, at 1:43 PM, Tomás Fernández Löbbe  
> wrote:
> 
> +1 eyeballed all the pages and read some random sections. 
> Two minor things I caught (not for respin), some of the examples in LTR for 
> some reason are very narrow (pages 355 to 365). 
> We still talk about DismaxRequestHandler in "Overview of Searching in Solr", 
> and we even say it's the default. I'll go and change it now.
> 
> 
> 
> On Wed, Feb 1, 2017 at 7:11 AM, Joel Bernstein  wrote:
> +1. I reviewed the changes to the Streaming Expressions docs. They look good.
> 
> Joel Bernstein
> http://joelsolr.blogspot.com/
> 
> On Tue, Jan 31, 2017 at 11:40 PM, David Smiley  
> wrote:
> +1 from me.  I reviewed the Highlighting section specifically and found a 
> small error (fixed in Confluence just now) but not enough to warrant a respin 
> IMO.
> 
> On Tue, Jan 31, 2017 at 10:44 AM Cassandra Targett  
> wrote:
> Please vote to release the Apache Solr Ref Guide for Solr 6.4.
> 
> Artifacts can be found at:
> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-6.4-RC0/
> 
> $ cat apache-solr-ref-guide-6.4-RC0/apache-solr-ref-guide-6.4.pdf.sha1
> 2e5f27c1aae36fde5717dd01a4495c5e299c9407  apache-solr-ref-guide-6.4.pdf
> 
> I'm not a huge fan of releasing with issues found at the last minute
> such as the one Erick E filed last night (SOLR-10061, about issues
> with the CoreAdmin API docs), but in this case I have a bunch of other
> stuff to do this week & next at the day job, I don't know the
> CoreAdmin API that well, and when SOLR-8029 (v2 API) is backported to
> 6.x, we will likely revamp ALL of the API pages, including that one.
> 
> So, that said, here's +1 from me.
> 
> Cassandra
> 
> -
> 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
> 
> 


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

Re: Call for MODERATORs on the dev and java-user mailing lists

[Steve Rowe]

Hmm, can’t do math today: the average per list is more like 1 message every 3 
days on a per list basis, assuming matches for subject:MODERATE on the 
gmail.com web UI is accurate.  It's bursty though: some days several come 
through, other days none.  Mostly (90% ?) it’s spam.

--
Steve
www.lucidworks.com

> On Feb 3, 2017, at 4:52 PM, Steve Rowe  wrote:
> 
> Hi Scott,
> 
> FYI the average number of MODERATE emails per day per mailing list is roughly 
> *1* (I’ve received about 50 in the last 2 months over the 3 mailing lists 
> I've been moderating up to this point), so the effort involved is fairly 
> small.
> 
> --
> Steve
> www.lucidworks.com
> 
>> On Feb 3, 2017, at 4:34 PM, scott cote  wrote:
>> 
>> Let me ask if I can get some cycles to do this.
>> 
>> I’m interested but I have to check first.
>> 
>> SCott
>> 
>> scott.c...@lucidworks.com
>> 
>> 
>>> On Feb 3, 2017, at 3:14 PM, Steve Rowe  wrote:
>>> 
>>> FYI I’m holding off on creating the INFRA JIRA until Aurelian has 
>>> acknowledged subscribing to dev@lucene.
>>> 
>>> In the meantime, if anybody else is interested in moderating either the 
>>> java-user@lucene or dev@lucene mailing list, please raise your hand.  
>>> Thanks!
>>> 
>>> --
>>> Steve
>>> www.lucidworks.com
>>> 
 On Feb 3, 2017, at 3:26 PM, Steve Rowe  wrote:
 
 Hi Aurelian, 
 
 Your response to the dev@ list required moderation, likely because you’re 
 not subscribed to the dev@ list with the email address you used to 
 respond.  Please first go subscribe to the dev@ list with the email you 
 used to send the message below - see 
  - then let 
 me know when you’ve done that.
 
 You don’t need to be online every day - just make a habit of dealing with 
 the MODERATE emails you get on a regular basis.  The system is set up so 
 that multiple people have the same responsibility, the idea being that one 
 of us will deal with the non-spam in a timely fashion, even though none of 
 us is online all the time.
 
 Thanks!
 
 --
 Steve
 www.lucidworks.com
 
> On Feb 3, 2017, at 3:17 PM, aurelian rosca  wrote:
> 
> I think i can handle both. I will take a look again next morning about
> requirements and i will let you know if I will have questions. Should i be
> online each day or just 5days/week.
> Pe 03.02.2017 22:07, "Steve Rowe"  a scris:
> 
>> Great!  We only needed one new volunteer on each of the two lists, so we
>> should be all set now.
>> 
>> I’ll go make an INFRA JIRA requesting the moderator changes.
>> 
>> --
>> Steve
>> www.lucidworks.com
>> 
>>> On Feb 3, 2017, at 3:02 PM, aurelian rosca 
>> wrote:
>>> 
>>> Both.
>>> Pe 03.02.2017 21:59, "Steve Rowe"  a scris:
>>> 
 Thanks Aurelian!
 
 To be clear: are you volunteering to moderate both the dev@ and
>> java-user@
 mailing lists? Or only the java-user@ mailing list?
 
 The only requirement is that you are a subscriber to each list you
 volunteer to moderate.
 
 --
 Steve
 www.lucidworks.com
 
> On Feb 3, 2017, at 2:17 PM, aurelian rosca 
 wrote:
> 
> Seems to be an easy job. I am in.
> 
> On Feb 3, 2017 9:13 PM, "Steve Rowe"  wrote:
> 
>> Hello subscribers to dev@l.a.o and java-user@l.a.o:
>> 
>> We need to replace a moderator who no longer wishes to do the job on
 these
>> two mailing lists.
>> 
>> If anyone is interested in being a MODERATOR, please reply back to
>> this
>> thread.  Being a moderator is really easy, the main chunk of the
>> responsibility is just hitting "reply-to all" if you get a message
>> with
 the
>> subject MODERATE and the body of the message isn't spam.
>> 
>> More details can be found on the wiki: https://wiki.apache.org/solr/
>> MailingListModeratorInfo
>> 
>> --
>> Steve
>> www.lucidworks.com
>> 
>> 
>> -
>> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: java-user-h...@lucene.apache.org
>> 
>> 
 
 
 -
 To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
 For additional commands, e-mail: java-user-h...@lucene.apache.org
 
 
>> 
>> 
>> 

[jira] [Commented] (SOLR-9714) Ability to configure STOP_PORT

[JIRA]

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

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

Also see SOLR-9137

> Ability to configure STOP_PORT
> --
>
> Key: SOLR-9714
> URL: https://issues.apache.org/jira/browse/SOLR-9714
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 5.5.3, 6.2.1
>Reporter: hu xiaodong
>Priority: Minor
> Attachments: SOLR-9714.patch, SOLR-9714.patch
>
>
> Our system just has port planning,we have the requirement to configure what 
> to use as stop port explicitly. but now I can configure the stop_port on the 
> starting script($SOLR_HOME/bin/solr), but can not use the port to stop solr 
> gracefully. I think the script has a little problem.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Closed] (SOLR-10093) Possibility to change SOLR stop and RMI ports

[JIRA]

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

Jan Høydahl closed SOLR-10093.
--
Resolution: Duplicate

Closing as duplicate of SOLR-9714. Also see SOLR-9137 which is related

> Possibility to change SOLR stop and RMI ports
> -
>
> Key: SOLR-10093
> URL: https://issues.apache.org/jira/browse/SOLR-10093
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 6.4
>Reporter: Christian Brönnimann
>Priority: Minor
>  Labels: features, port, scripts
>
> My SOLR start port is 10443.
> I've found hard coded rules (-1000 and +1) for stop and RMI ports in file 
> /opt/solr/bin/solr.
> I've set the three variables in /etc/default/solr.in.sh for all 3 ports:
> SOLR_PORT="10443"
> STOP_PORT="10442"
> RMI_PORT="10444"
> SOLR has bound to these ports, but with this setting I could not stop SOLR 
> anymore.
> I had to edit the rules in /opt/solr/bin/solr by replacing 1000 and 1 by 
> the value 1.
> Could you please change the scripts, that the ports may be configured in 
> /etc/default/solr.in.sh ?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Call for MODERATORs on the dev and java-user mailing lists

[Steve Rowe]

Hi Scott,

FYI the average number of MODERATE emails per day per mailing list is roughly 
*1* (I’ve received about 50 in the last 2 months over the 3 mailing lists I've 
been moderating up to this point), so the effort involved is fairly small.

--
Steve
www.lucidworks.com

> On Feb 3, 2017, at 4:34 PM, scott cote  wrote:
> 
> Let me ask if I can get some cycles to do this.
> 
> I’m interested but I have to check first.
> 
> SCott
> 
> scott.c...@lucidworks.com
> 
> 
>> On Feb 3, 2017, at 3:14 PM, Steve Rowe  wrote:
>> 
>> FYI I’m holding off on creating the INFRA JIRA until Aurelian has 
>> acknowledged subscribing to dev@lucene.
>> 
>> In the meantime, if anybody else is interested in moderating either the 
>> java-user@lucene or dev@lucene mailing list, please raise your hand.  Thanks!
>> 
>> --
>> Steve
>> www.lucidworks.com
>> 
>>> On Feb 3, 2017, at 3:26 PM, Steve Rowe  wrote:
>>> 
>>> Hi Aurelian, 
>>> 
>>> Your response to the dev@ list required moderation, likely because you’re 
>>> not subscribed to the dev@ list with the email address you used to respond. 
>>>  Please first go subscribe to the dev@ list with the email you used to send 
>>> the message below - see 
>>>  - then let 
>>> me know when you’ve done that.
>>> 
>>> You don’t need to be online every day - just make a habit of dealing with 
>>> the MODERATE emails you get on a regular basis.  The system is set up so 
>>> that multiple people have the same responsibility, the idea being that one 
>>> of us will deal with the non-spam in a timely fashion, even though none of 
>>> us is online all the time.
>>> 
>>> Thanks!
>>> 
>>> --
>>> Steve
>>> www.lucidworks.com
>>> 
 On Feb 3, 2017, at 3:17 PM, aurelian rosca  wrote:
 
 I think i can handle both. I will take a look again next morning about
 requirements and i will let you know if I will have questions. Should i be
 online each day or just 5days/week.
 Pe 03.02.2017 22:07, "Steve Rowe"  a scris:
 
> Great!  We only needed one new volunteer on each of the two lists, so we
> should be all set now.
> 
> I’ll go make an INFRA JIRA requesting the moderator changes.
> 
> --
> Steve
> www.lucidworks.com
> 
>> On Feb 3, 2017, at 3:02 PM, aurelian rosca 
> wrote:
>> 
>> Both.
>> Pe 03.02.2017 21:59, "Steve Rowe"  a scris:
>> 
>>> Thanks Aurelian!
>>> 
>>> To be clear: are you volunteering to moderate both the dev@ and
> java-user@
>>> mailing lists? Or only the java-user@ mailing list?
>>> 
>>> The only requirement is that you are a subscriber to each list you
>>> volunteer to moderate.
>>> 
>>> --
>>> Steve
>>> www.lucidworks.com
>>> 
 On Feb 3, 2017, at 2:17 PM, aurelian rosca 
>>> wrote:
 
 Seems to be an easy job. I am in.
 
 On Feb 3, 2017 9:13 PM, "Steve Rowe"  wrote:
 
> Hello subscribers to dev@l.a.o and java-user@l.a.o:
> 
> We need to replace a moderator who no longer wishes to do the job on
>>> these
> two mailing lists.
> 
> If anyone is interested in being a MODERATOR, please reply back to
> this
> thread.  Being a moderator is really easy, the main chunk of the
> responsibility is just hitting "reply-to all" if you get a message
> with
>>> the
> subject MODERATE and the body of the message isn't spam.
> 
> More details can be found on the wiki: https://wiki.apache.org/solr/
> MailingListModeratorInfo
> 
> --
> Steve
> www.lucidworks.com
> 
> 
> -
> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-user-h...@lucene.apache.org
> 
> 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: java-user-h...@lucene.apache.org
>>> 
>>> 
> 
> 
> -
> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-user-h...@lucene.apache.org
> 
> 
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: java-user-h...@lucene.apache.org
>> 
> 
> 
> -
> To 

[jira] [Commented] (SOLR-10076) Hiding keystore and truststore passwords from /admin/info/* outputs

[JIRA]

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

Jan Høydahl commented on SOLR-10076:


Been thinking about the same, but perhaps instead of a generic rule about 
containing password, we could have a property somewhere for what paths to hide. 
I would also like to hide the content of some ZK nodes such as security.json, 
and there may also be other places where passwords are exposed through props or 
APIs...

Ideal would be if this could be coupled with Authorization, so that certain 
info could be controlled through group membership in AuthorizationPlugin?

> Hiding keystore and truststore passwords from /admin/info/* outputs
> ---
>
> Key: SOLR-10076
> URL: https://issues.apache.org/jira/browse/SOLR-10076
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mano Kovacs
>
> Passing keystore and truststore password is done by system properties, via 
> cmd line parameter.
> As result, {{/admin/info/properties}} and {{/admin/info/system}} will print 
> out the received password.
> Proposing solution to automatically redact value of any system property 
> before output, containing the word {{password}}, and replacing its value with 
> {{**}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Cannot edit WIKI anymore

[Steve Rowe]

No problem Shawn, hopefully you’ll catch and fix my (inevitable) next mistake :)

--
Steve
www.lucidworks.com

> On Feb 3, 2017, at 4:36 PM, Shawn Heisey  wrote:
> 
> On 2/3/2017 2:23 PM, Steve Rowe wrote:
>> Looks like Shawn Heisey accidentally removed several people when
>> trying to alphabetize about 10 months ago:
>> .
>> I’ll go fix.
> 
> Ouch!  I don't recall doing anything just for alphabetizing ... but I do
> apologize if I screwed it up.  Thanks for fixing!
> 
> Shawn
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: Cannot edit WIKI anymore

[Shawn Heisey]

On 2/3/2017 2:23 PM, Steve Rowe wrote:
> Looks like Shawn Heisey accidentally removed several people when
> trying to alphabetize about 10 months ago:
> .
> I’ll go fix.

Ouch!  I don't recall doing anything just for alphabetizing ... but I do
apologize if I screwed it up.  Thanks for fixing!

Shawn


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

Re: Cannot edit WIKI anymore

[Jan Høydahl]

Thanks, I’m back :)

Strange, cause I was allowed to edit 
https://wiki.apache.org/solr/ContributorsGroup on 2017-01-13 (I’m still the 
latest editor, see bottom of page)

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

> 3. feb. 2017 kl. 22.27 skrev Steve Rowe :
> 
> Done.
> 
> --
> Steve
> www.lucidworks.com
> 
>> On Feb 3, 2017, at 4:23 PM, Steve Rowe  wrote:
>> 
>> Looks like Shawn Heisey accidentally removed several people when trying to 
>> alphabetize about 10 months ago: 
>> .  I’ll 
>> go fix.
>> 
>> --
>> Steve
>> www.lucidworks.com
>> 
>>> On Feb 3, 2017, at 4:20 PM, Jan Høydahl  wrote:
>>> 
>>> Hi
>>> 
>>> I seem to have been removed from https://wiki.apache.org/solr/AdminGroup, 
>>> cause I cannot edit any wiki page anymore
>>> Can someone with Admin access please add me back? My userId is JanHoydahl
>>> 
>>> --
>>> Jan Høydahl, search solution architect
>>> Cominvent AS - www.cominvent.com
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>> 
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: Cannot edit WIKI anymore

[Steve Rowe]

Done.

--
Steve
www.lucidworks.com

> On Feb 3, 2017, at 4:23 PM, Steve Rowe  wrote:
> 
> Looks like Shawn Heisey accidentally removed several people when trying to 
> alphabetize about 10 months ago: 
> .  I’ll 
> go fix.
> 
> --
> Steve
> www.lucidworks.com
> 
>> On Feb 3, 2017, at 4:20 PM, Jan Høydahl  wrote:
>> 
>> Hi
>> 
>> I seem to have been removed from https://wiki.apache.org/solr/AdminGroup, 
>> cause I cannot edit any wiki page anymore
>> Can someone with Admin access please add me back? My userId is JanHoydahl
>> 
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
> 


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

Re: Cannot edit WIKI anymore

[Steve Rowe]

Looks like Shawn Heisey accidentally removed several people when trying to 
alphabetize about 10 months ago: 
.  I’ll go 
fix.

--
Steve
www.lucidworks.com

> On Feb 3, 2017, at 4:20 PM, Jan Høydahl  wrote:
> 
> Hi
> 
> I seem to have been removed from https://wiki.apache.org/solr/AdminGroup, 
> cause I cannot edit any wiki page anymore
> Can someone with Admin access please add me back? My userId is JanHoydahl
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
> 
> 
> -
> 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

Cannot edit WIKI anymore

[Jan Høydahl]

Hi

I seem to have been removed from https://wiki.apache.org/solr/AdminGroup, cause 
I cannot edit any wiki page anymore
Can someone with Admin access please add me back? My userId is JanHoydahl

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


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

[jira] [Commented] (SOLR-8028) ConcurrentModificationException thrown from JavaBinCodec

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-8028:


Giving the stacktrace, it happens to list of field values of SolrInputDocument, 
thus it's might be caused:
 * by reusing SolrInputDocument instance;
 * by reusing field values lists;
May it be the case? 

> ConcurrentModificationException thrown from JavaBinCodec
> 
>
> Key: SOLR-8028
> URL: https://issues.apache.org/jira/browse/SOLR-8028
> Project: Solr
>  Issue Type: Bug
>  Components: clients - java
>Affects Versions: 4.10.3
>Reporter: lvchuanwen
>Priority: Critical
>  Labels: ConcurrentModificationException
>
> while pressure test by LoadRunner ,There are some 
> ConcurrentModificationException.
> Caused by: java.util.ConcurrentModificationException
>   at java.util.ArrayList$Itr.next(ArrayList.java:837)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeArray(JavaBinCodec.java:474)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:250)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:153)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeSolrInputDocument(JavaBinCodec.java:424)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:250)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:153)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeSolrInputDocument(JavaBinCodec.java:424)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:274)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:153)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:274)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:153)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeMapEntry(JavaBinCodec.java:509)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:294)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:294)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:153)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeIterator(JavaBinCodec.java:450)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeIterator(JavaBinCodec.java:450)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:282)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:153)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:153)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeNamedList(JavaBinCodec.java:148)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:242)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:242)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:153)
>   at 
> org.apache.solr.common.util.JavaBinCodec.marshal(JavaBinCodec.java:96)
>   at 
> org.apache.solr.common.util.JavaBinCodec.marshal(JavaBinCodec.java:96)
>   at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.marshal(JavaBinUpdateRequestCodec.java:83)
>   at 
> org.apache.solr.client.solrj.impl.BinaryRequestWriter.getContentStream(BinaryRequestWriter.java:67)
>   at 
> org.apache.solr.client.solrj.impl.BinaryRequestWriter.getContentStream(BinaryRequestWriter.java:67)
>   at 
> org.apache.solr.client.solrj.request.RequestWriter$LazyContentStream.getDelegate(RequestWriter.java:95)
>   at 
> org.apache.solr.client.solrj.request.RequestWriter$LazyContentStream.getName(RequestWriter.java:105)
>   at 
> org.apache.solr.client.solrj.request.RequestWriter$LazyContentStream.getName(RequestWriter.java:105)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrServer.createMethod(HttpSolrServer.java:370)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrServer.createMethod(HttpSolrServer.java:304)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:229)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:225)
>   at 
> org.apache.solr.client.solrj.impl.LBHttpSolrServer.doRequest(LBHttpSolrServer.java:345)
>   ... 30 more
> java.util.ConcurrentModificationException
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:229)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:225)
>   at 
> 

JDK 9 EA Build 155 is available on java.net

[Rory O'Donnell]

Hi Uwe & Dawid,

*JDK 9 Early Access* b155   is 
available on java.net


Can you confirm fix for :

 * b154 - JDK-8157611 : field visiblePackages is null for the unnamed
   module producing NPE when accessed


There have been a number of fixes to bugs reported by Open Source 
projects since the last availability email  :


 * b155 - JDK-8167273 : Calendar.getDisplayNames inconsistent with
   DateFormatSymbols
 * b153 - JDK-8163449 : Allow per protocol setting for URLConnection
   defaultUseCaches
 * b152 - JDK-8172158 : Annotation processor not run with -source <= 8


Dalibor and I are presenting at FOSDEM this weekend, we would love to 
meet you there!


 * JDK 9 Outreach - The Awesome Parts
   


Rgds,Rory

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

Re: Call for MODERATORs on the dev and java-user mailing lists

[Steve Rowe]

FYI I’m holding off on creating the INFRA JIRA until Aurelian has acknowledged 
subscribing to dev@lucene.

In the meantime, if anybody else is interested in moderating either the 
java-user@lucene or dev@lucene mailing list, please raise your hand.  Thanks!

--
Steve
www.lucidworks.com

> On Feb 3, 2017, at 3:26 PM, Steve Rowe  wrote:
> 
> Hi Aurelian, 
> 
> Your response to the dev@ list required moderation, likely because you’re not 
> subscribed to the dev@ list with the email address you used to respond.  
> Please first go subscribe to the dev@ list with the email you used to send 
> the message below - see 
>  - then let me 
> know when you’ve done that.
> 
> You don’t need to be online every day - just make a habit of dealing with the 
> MODERATE emails you get on a regular basis.  The system is set up so that 
> multiple people have the same responsibility, the idea being that one of us 
> will deal with the non-spam in a timely fashion, even though none of us is 
> online all the time.
> 
> Thanks!
> 
> --
> Steve
> www.lucidworks.com
> 
>> On Feb 3, 2017, at 3:17 PM, aurelian rosca  wrote:
>> 
>> I think i can handle both. I will take a look again next morning about
>> requirements and i will let you know if I will have questions. Should i be
>> online each day or just 5days/week.
>> Pe 03.02.2017 22:07, "Steve Rowe"  a scris:
>> 
>>> Great!  We only needed one new volunteer on each of the two lists, so we
>>> should be all set now.
>>> 
>>> I’ll go make an INFRA JIRA requesting the moderator changes.
>>> 
>>> --
>>> Steve
>>> www.lucidworks.com
>>> 
 On Feb 3, 2017, at 3:02 PM, aurelian rosca 
>>> wrote:
 
 Both.
 Pe 03.02.2017 21:59, "Steve Rowe"  a scris:
 
> Thanks Aurelian!
> 
> To be clear: are you volunteering to moderate both the dev@ and
>>> java-user@
> mailing lists? Or only the java-user@ mailing list?
> 
> The only requirement is that you are a subscriber to each list you
> volunteer to moderate.
> 
> --
> Steve
> www.lucidworks.com
> 
>> On Feb 3, 2017, at 2:17 PM, aurelian rosca 
> wrote:
>> 
>> Seems to be an easy job. I am in.
>> 
>> On Feb 3, 2017 9:13 PM, "Steve Rowe"  wrote:
>> 
>>> Hello subscribers to dev@l.a.o and java-user@l.a.o:
>>> 
>>> We need to replace a moderator who no longer wishes to do the job on
> these
>>> two mailing lists.
>>> 
>>> If anyone is interested in being a MODERATOR, please reply back to
>>> this
>>> thread.  Being a moderator is really easy, the main chunk of the
>>> responsibility is just hitting "reply-to all" if you get a message
>>> with
> the
>>> subject MODERATE and the body of the message isn't spam.
>>> 
>>> More details can be found on the wiki: https://wiki.apache.org/solr/
>>> MailingListModeratorInfo
>>> 
>>> --
>>> Steve
>>> www.lucidworks.com
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: java-user-h...@lucene.apache.org
>>> 
>>> 
> 
> 
> -
> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-user-h...@lucene.apache.org
> 
> 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: java-user-h...@lucene.apache.org
>>> 
>>> 
> 


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

[jira] [Comment Edited] (LUCENE-7674) java.lang.IllegalStateException: Child query must not match same docs with parent filter. Combine them as must clauses (+) to find a problem doc. docId=2147483647

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev edited comment on LUCENE-7674 at 2/3/17 9:09 PM:
--

[^LUCENE-7674.patch] introduces {{CheckingQueryBitSetProducer}} which checks 
parent segment's bitset before caching and switches {{\{\!parent} \{\!child}}} 
to use it. It laid well, beside of, and it's interesting! 
{{BJQParserTest.testGrandChildren()}}. When we have three levels: parent, 
child, grand-child and searching for children (2nd level), it requires to 
include all ascendant levels (parent) in bitset. This, will break existing 
queries for those who run more than two level blocks. But such explicitly 
strict behavior solves problems for those who tires to retrieve intermediate 
levels by \[child] then, I remember a couple of such threads in the list. 
What do you think?
  


was (Author: mkhludnev):
[^LUCENE-7674.patch] introduces {{CheckingQueryBitSetProducer}} which checks 
parent segment's bitset before caching and switches {{\{!parent} \{!child}}} to 
use it. It laid well, beside of, and it's interesting! 
{{BJQParserTest.testGrandChildren()}}. When we have three levels: parent, 
child, grand-child and searching for children (2nd level), it requires to 
include all ascendant levels (parent) in bitset. This, will break existing 
queries for those who run more than two level blocks. But such explicitly 
strict behavior solves problems for those who tires to retrieve intermediate 
levels by \[child] then, I remember a couple of such threads in the list. 
What do you think?
  

> java.lang.IllegalStateException: Child query must not match same docs with 
> parent filter. Combine them as must clauses (+) to find a problem doc. 
> docId=2147483647, class org.apache.lucene.search.ConjunctionScorer
> 
>
> Key: LUCENE-7674
> URL: https://issues.apache.org/jira/browse/LUCENE-7674
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.3
>Reporter: Tim Underwood
> Attachments: LUCENE-7674.patch
>
>
> Started seeing this error message on a production Solr 6.3.0 system today 
> making use of parent/child documents:
> {code}
> java.lang.IllegalStateException: Child query must not match same docs with 
> parent filter. Combine them as must clauses (+) to find a problem doc. 
> docId=2147483647, class org.apache.lucene.search.ConjunctionScorer
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.checkOrthogonal(ToParentBlockJoinQuery.java:403)
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.access$400(ToParentBlockJoinQuery.java:206)
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer$1.nextDoc(ToParentBlockJoinQuery.java:327)
> at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:219)
> at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:172)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:669)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:473)
> at 
> org.apache.solr.search.DocSetUtil.createDocSetGeneric(DocSetUtil.java:106)
> at org.apache.solr.search.DocSetUtil.createDocSet(DocSetUtil.java:95)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1379)
> at 
> org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:1057)
> at 
> org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1227)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListAndSetNC(SolrIndexSearcher.java:1842)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1616)
> at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:617)
> at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:531)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:153)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2213)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:303)
> at 
> 

[jira] [Commented] (LUCENE-7674) java.lang.IllegalStateException: Child query must not match same docs with parent filter. Combine them as must clauses (+) to find a problem doc. docId=2147483647, cla

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on LUCENE-7674:
--

[~tpunder], you've got everything right! Thanks for gathering those pet peeves 
in the list. I need to tackle them sooner or later. 

> java.lang.IllegalStateException: Child query must not match same docs with 
> parent filter. Combine them as must clauses (+) to find a problem doc. 
> docId=2147483647, class org.apache.lucene.search.ConjunctionScorer
> 
>
> Key: LUCENE-7674
> URL: https://issues.apache.org/jira/browse/LUCENE-7674
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.3
>Reporter: Tim Underwood
> Attachments: LUCENE-7674.patch
>
>
> Started seeing this error message on a production Solr 6.3.0 system today 
> making use of parent/child documents:
> {code}
> java.lang.IllegalStateException: Child query must not match same docs with 
> parent filter. Combine them as must clauses (+) to find a problem doc. 
> docId=2147483647, class org.apache.lucene.search.ConjunctionScorer
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.checkOrthogonal(ToParentBlockJoinQuery.java:403)
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.access$400(ToParentBlockJoinQuery.java:206)
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer$1.nextDoc(ToParentBlockJoinQuery.java:327)
> at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:219)
> at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:172)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:669)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:473)
> at 
> org.apache.solr.search.DocSetUtil.createDocSetGeneric(DocSetUtil.java:106)
> at org.apache.solr.search.DocSetUtil.createDocSet(DocSetUtil.java:95)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1379)
> at 
> org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:1057)
> at 
> org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1227)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListAndSetNC(SolrIndexSearcher.java:1842)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1616)
> at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:617)
> at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:531)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:153)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2213)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:303)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:254)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:518)
> at 

[jira] [Updated] (LUCENE-7674) java.lang.IllegalStateException: Child query must not match same docs with parent filter. Combine them as must clauses (+) to find a problem doc. docId=2147483647, class

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated LUCENE-7674:
-
Attachment: LUCENE-7674.patch

[^LUCENE-7674.patch] introduces {{CheckingQueryBitSetProducer}} which checks 
parent segment's bitset before caching and switches {{\{!parent} \{!child}}} to 
use it. It laid well, beside of, and it's interesting! 
{{BJQParserTest.testGrandChildren()}}. When we have three levels: parent, 
child, grand-child and searching for children (2nd level), it requires to 
include all ascendant levels (parent) in bitset. This, will break existing 
queries for those who run more than two level blocks. But such explicitly 
strict behavior solves problems for those who tires to retrieve intermediate 
levels by \[child] then, I remember a couple of such threads in the list. 
What do you think?
  

> java.lang.IllegalStateException: Child query must not match same docs with 
> parent filter. Combine them as must clauses (+) to find a problem doc. 
> docId=2147483647, class org.apache.lucene.search.ConjunctionScorer
> 
>
> Key: LUCENE-7674
> URL: https://issues.apache.org/jira/browse/LUCENE-7674
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.3
>Reporter: Tim Underwood
> Attachments: LUCENE-7674.patch
>
>
> Started seeing this error message on a production Solr 6.3.0 system today 
> making use of parent/child documents:
> {code}
> java.lang.IllegalStateException: Child query must not match same docs with 
> parent filter. Combine them as must clauses (+) to find a problem doc. 
> docId=2147483647, class org.apache.lucene.search.ConjunctionScorer
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.checkOrthogonal(ToParentBlockJoinQuery.java:403)
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.access$400(ToParentBlockJoinQuery.java:206)
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer$1.nextDoc(ToParentBlockJoinQuery.java:327)
> at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:219)
> at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:172)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:669)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:473)
> at 
> org.apache.solr.search.DocSetUtil.createDocSetGeneric(DocSetUtil.java:106)
> at org.apache.solr.search.DocSetUtil.createDocSet(DocSetUtil.java:95)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1379)
> at 
> org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:1057)
> at 
> org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1227)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListAndSetNC(SolrIndexSearcher.java:1842)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1616)
> at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:617)
> at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:531)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:153)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2213)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:303)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:254)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> 

[jira] [Comment Edited] (SOLR-10096) Parallel SQL not returning the correct results for count distinct aggregation

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-10096 at 2/3/17 9:00 PM:
---

About the performance issue you were seeing. The SQL query is likely in 
map_reduce mode which is the default for the SQL interface. If you switch to 
aggregationMode=facet you'll likely see comparable performance to the 
expression you reference.

You can improve your map_reduce throughput by adding workers so it will 
parallelize the distinct operation.


was (Author: joel.bernstein):
About the performance issue you were seeing. The SQL query is likely in 
map_reduce mode which is the default or the SQL interface. If you switch to 
aggregationMode=facet you'll likely see comparable performance to expression 
you reference.

You can improve your map_reduce throughput by adding workers so it parallelize 
the select distinct.

> Parallel SQL not returning the correct results for count distinct aggregation
> -
>
> Key: SOLR-10096
> URL: https://issues.apache.org/jira/browse/SOLR-10096
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Parallel SQL
>Affects Versions: 6.3
>Reporter: Timothy Potter
>
> While trying to compare the results of this perf exp. blogged here:
> https://www.periscopedata.com/blog/use-subqueries-to-count-distinct-50x-faster.html
> I tried this with 6.3 and it only returns the dashboard_id's:
> {code}
> select dashboard_id, count(distinct user_id) as ct from time_on_site_logs 
> group by dashboard_id
> {code}
> Results: (where is ct?)
> {code}
> {"result-set":{"docs":[
> {"dashboard_id":0},
> {"dashboard_id":2},
> {"dashboard_id":5},
> {"dashboard_id":6},
> {"dashboard_id":8},
> {"dashboard_id":10},
> {"dashboard_id":12},
> {"dashboard_id":13},
> {"dashboard_id":14},
> {"dashboard_id":15},
> ...
> {code}
> So I dropped the alias for {{count(distinct user_id)}} and got the wrong 
> results (i.e. it's not applying the distinct for user_id's):
> {code}
> {"result-set":{"docs":[
> {"count(*)":8288,"dashboard_id":0},
> {"count(*)":7392,"dashboard_id":2},
> {"count(*)":23800,"dashboard_id":5},
> {"count(*)":25032,"dashboard_id":6},
> {"count(*)":8960,"dashboard_id":8},
> {"count(*)":7840,"dashboard_id":10},
> {"count(*)":17192,"dashboard_id":12},
> {code}
> So I'm guessing this isn't a supported syntax yet?
> Also, probably a different issue, but I then tried this query:
> {code}
> select distinct dashboard_id, user_id from time_on_site_logs
> {code}
> and it took ~70 secs (m3.xlarge), which is very surprising because this 
> streaming expression (which basically does the initial query above):
> {code}
> select(rollup(facet(time_on_site_logs, q="*:*", 
> buckets="dashboard_id,user_id", bucketSizeLimit=2000, 
> bucketSorts="dashboard_id asc",count(*)), over="dashboard_id", count(*)), 
> dashboard_id,count(*) as unique_users)
> {code}
> Returns in ~1.5 secs ... that's a huge difference in performance.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10096) Parallel SQL not returning the correct results for count distinct aggregation

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-10096:
---

About the performance issue you were seeing. The SQL query is likely in 
map_reduce mode which is the default or the SQL interface. If you switch to 
aggregationMode=facet you'll likely see comparable performance to expression 
you reference.

You can improve your map_reduce throughput by adding workers so it parallelize 
the select distinct.

> Parallel SQL not returning the correct results for count distinct aggregation
> -
>
> Key: SOLR-10096
> URL: https://issues.apache.org/jira/browse/SOLR-10096
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Parallel SQL
>Affects Versions: 6.3
>Reporter: Timothy Potter
>
> While trying to compare the results of this perf exp. blogged here:
> https://www.periscopedata.com/blog/use-subqueries-to-count-distinct-50x-faster.html
> I tried this with 6.3 and it only returns the dashboard_id's:
> {code}
> select dashboard_id, count(distinct user_id) as ct from time_on_site_logs 
> group by dashboard_id
> {code}
> Results: (where is ct?)
> {code}
> {"result-set":{"docs":[
> {"dashboard_id":0},
> {"dashboard_id":2},
> {"dashboard_id":5},
> {"dashboard_id":6},
> {"dashboard_id":8},
> {"dashboard_id":10},
> {"dashboard_id":12},
> {"dashboard_id":13},
> {"dashboard_id":14},
> {"dashboard_id":15},
> ...
> {code}
> So I dropped the alias for {{count(distinct user_id)}} and got the wrong 
> results (i.e. it's not applying the distinct for user_id's):
> {code}
> {"result-set":{"docs":[
> {"count(*)":8288,"dashboard_id":0},
> {"count(*)":7392,"dashboard_id":2},
> {"count(*)":23800,"dashboard_id":5},
> {"count(*)":25032,"dashboard_id":6},
> {"count(*)":8960,"dashboard_id":8},
> {"count(*)":7840,"dashboard_id":10},
> {"count(*)":17192,"dashboard_id":12},
> {code}
> So I'm guessing this isn't a supported syntax yet?
> Also, probably a different issue, but I then tried this query:
> {code}
> select distinct dashboard_id, user_id from time_on_site_logs
> {code}
> and it took ~70 secs (m3.xlarge), which is very surprising because this 
> streaming expression (which basically does the initial query above):
> {code}
> select(rollup(facet(time_on_site_logs, q="*:*", 
> buckets="dashboard_id,user_id", bucketSizeLimit=2000, 
> bucketSorts="dashboard_id asc",count(*)), over="dashboard_id", count(*)), 
> dashboard_id,count(*) as unique_users)
> {code}
> Returns in ~1.5 secs ... that's a huge difference in performance.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10095) Examples do not respect SOLR_HOME and SOLR_LOGS_DIR

[JIRA]

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

Jan Høydahl updated SOLR-10095:
---
Priority: Minor  (was: Major)

> Examples do not respect SOLR_HOME and SOLR_LOGS_DIR
> ---
>
> Key: SOLR-10095
> URL: https://issues.apache.org/jira/browse/SOLR-10095
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Jan Høydahl
>Priority: Minor
>
> The examples do not respect {{SOLR_HOME}} or {{SOLR_LOGS_DIR}} env, but 
> always try to write index and logs to {{SOLR_HOME/../logs}}. Problem is when 
> Solr is installed using the installer script, then {{/opt/solr}} is not 
> supposed to be writable, and starting the examples fail.
> h3. Reproduce
> {noformat}
> sudo install_solr_service.sh solr-6.4.0.tgz
> sudo su solr
> export SOLR_INCLUDE="/etc/default/solr.in.sh"
> /opt/solr/bin/solr -e dih
> Starting up Solr on port 8983 using command:
> /opt/solr/bin/solr start -p 8983 -s "/opt/solr/example/example-DIH/solr"
> Exception in thread "main" java.nio.file.AccessDeniedException: 
> /opt/solr/example/example-DIH/solr/../logs
>   at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
>   at 
> sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:384)
>   at java.nio.file.Files.createDirectory(Files.java:674)
>   at java.nio.file.Files.createAndCheckIsDirectory(Files.java:781)
>   at java.nio.file.Files.createDirectories(Files.java:767)
>   at 
> org.apache.solr.util.SolrCLI$UtilsTool.archiveGcLogs(SolrCLI.java:3604)
>   at org.apache.solr.util.SolrCLI$UtilsTool.runTool(SolrCLI.java:3587)
>   at org.apache.solr.util.SolrCLI.main(SolrCLI.java:256)
> Failed archiving old GC logs
> Exception in thread "main" java.nio.file.AccessDeniedException: 
> /opt/solr/example/example-DIH/solr/../logs
>   at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
>   at 
> sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:384)
>   at java.nio.file.Files.createDirectory(Files.java:674)
>   at java.nio.file.Files.createAndCheckIsDirectory(Files.java:781)
>   at java.nio.file.Files.createDirectories(Files.java:767)
>   at 
> org.apache.solr.util.SolrCLI$UtilsTool.archiveConsoleLogs(SolrCLI.java:3633)
>   at org.apache.solr.util.SolrCLI$UtilsTool.runTool(SolrCLI.java:3590)
>   at org.apache.solr.util.SolrCLI.main(SolrCLI.java:256)
> Failed archiving old console logs
> ERROR: Logs directory /opt/solr/example/example-DIH/solr/../logs could not be 
> created. Exiting
> ERROR: Process exited with an error: 1 (Exit value: 1)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10095) Examples do not respect SOLR_HOME and SOLR_LOGS_DIR

[JIRA]

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

Jan Høydahl commented on SOLR-10095:


I suggest that if {{SOLR_HOME}} is explicitly defined, either in {{solr.in.sh}} 
or in the environment, then the examples should respect that and place the 
index files there, and the log files in {{SOLR_HOME/../logs}}. If 
{{SOLR_LOGS_DIR}} is also explicitly defined, then that should also be 
respected.

Users just unpacking the tarball and running {{bin/solr -e }} will 
still default to {{/example//...}}.

A challenge is of course that we have no way of separating conf and data using 
config as of today (see SOLR-6671). So our story that it should be possible to 
separate code/conf and data 100% is not really possible.

> Examples do not respect SOLR_HOME and SOLR_LOGS_DIR
> ---
>
> Key: SOLR-10095
> URL: https://issues.apache.org/jira/browse/SOLR-10095
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Jan Høydahl
>
> The examples do not respect {{SOLR_HOME}} or {{SOLR_LOGS_DIR}} env, but 
> always try to write index and logs to {{SOLR_HOME/../logs}}. Problem is when 
> Solr is installed using the installer script, then {{/opt/solr}} is not 
> supposed to be writable, and starting the examples fail.
> h3. Reproduce
> {noformat}
> sudo install_solr_service.sh solr-6.4.0.tgz
> sudo su solr
> export SOLR_INCLUDE="/etc/default/solr.in.sh"
> /opt/solr/bin/solr -e dih
> Starting up Solr on port 8983 using command:
> /opt/solr/bin/solr start -p 8983 -s "/opt/solr/example/example-DIH/solr"
> Exception in thread "main" java.nio.file.AccessDeniedException: 
> /opt/solr/example/example-DIH/solr/../logs
>   at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
>   at 
> sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:384)
>   at java.nio.file.Files.createDirectory(Files.java:674)
>   at java.nio.file.Files.createAndCheckIsDirectory(Files.java:781)
>   at java.nio.file.Files.createDirectories(Files.java:767)
>   at 
> org.apache.solr.util.SolrCLI$UtilsTool.archiveGcLogs(SolrCLI.java:3604)
>   at org.apache.solr.util.SolrCLI$UtilsTool.runTool(SolrCLI.java:3587)
>   at org.apache.solr.util.SolrCLI.main(SolrCLI.java:256)
> Failed archiving old GC logs
> Exception in thread "main" java.nio.file.AccessDeniedException: 
> /opt/solr/example/example-DIH/solr/../logs
>   at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
>   at 
> sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:384)
>   at java.nio.file.Files.createDirectory(Files.java:674)
>   at java.nio.file.Files.createAndCheckIsDirectory(Files.java:781)
>   at java.nio.file.Files.createDirectories(Files.java:767)
>   at 
> org.apache.solr.util.SolrCLI$UtilsTool.archiveConsoleLogs(SolrCLI.java:3633)
>   at org.apache.solr.util.SolrCLI$UtilsTool.runTool(SolrCLI.java:3590)
>   at org.apache.solr.util.SolrCLI.main(SolrCLI.java:256)
> Failed archiving old console logs
> ERROR: Logs directory /opt/solr/example/example-DIH/solr/../logs could not be 
> created. Exiting
> ERROR: Process exited with an error: 1 (Exit value: 1)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10096) Parallel SQL not returning the correct results for count distinct aggregation

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-10096:
---

Count distinct isn't supported yet. I believe this is working in the Calcite 
implementation, but I'll check on this.

> Parallel SQL not returning the correct results for count distinct aggregation
> -
>
> Key: SOLR-10096
> URL: https://issues.apache.org/jira/browse/SOLR-10096
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Parallel SQL
>Affects Versions: 6.3
>Reporter: Timothy Potter
>
> While trying to compare the results of this perf exp. blogged here:
> https://www.periscopedata.com/blog/use-subqueries-to-count-distinct-50x-faster.html
> I tried this with 6.3 and it only returns the dashboard_id's:
> {code}
> select dashboard_id, count(distinct user_id) as ct from time_on_site_logs 
> group by dashboard_id
> {code}
> Results: (where is ct?)
> {code}
> {"result-set":{"docs":[
> {"dashboard_id":0},
> {"dashboard_id":2},
> {"dashboard_id":5},
> {"dashboard_id":6},
> {"dashboard_id":8},
> {"dashboard_id":10},
> {"dashboard_id":12},
> {"dashboard_id":13},
> {"dashboard_id":14},
> {"dashboard_id":15},
> ...
> {code}
> So I dropped the alias for {{count(distinct user_id)}} and got the wrong 
> results (i.e. it's not applying the distinct for user_id's):
> {code}
> {"result-set":{"docs":[
> {"count(*)":8288,"dashboard_id":0},
> {"count(*)":7392,"dashboard_id":2},
> {"count(*)":23800,"dashboard_id":5},
> {"count(*)":25032,"dashboard_id":6},
> {"count(*)":8960,"dashboard_id":8},
> {"count(*)":7840,"dashboard_id":10},
> {"count(*)":17192,"dashboard_id":12},
> {code}
> So I'm guessing this isn't a supported syntax yet?
> Also, probably a different issue, but I then tried this query:
> {code}
> select distinct dashboard_id, user_id from time_on_site_logs
> {code}
> and it took ~70 secs (m3.xlarge), which is very surprising because this 
> streaming expression (which basically does the initial query above):
> {code}
> select(rollup(facet(time_on_site_logs, q="*:*", 
> buckets="dashboard_id,user_id", bucketSizeLimit=2000, 
> bucketSorts="dashboard_id asc",count(*)), over="dashboard_id", count(*)), 
> dashboard_id,count(*) as unique_users)
> {code}
> Returns in ~1.5 secs ... that's a huge difference in performance.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10095) Examples do not respect SOLR_HOME and SOLR_LOGS_DIR

[JIRA]

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

Jan Høydahl updated SOLR-10095:
---
Description: 
The examples do not respect {{SOLR_HOME}} or {{SOLR_LOGS_DIR}} env, but always 
try to write index and logs to {{SOLR_HOME/../logs}}. Problem is when Solr is 
installed using the installer script, then {{/opt/solr}} is not supposed to be 
writable, and starting the examples fail.

h3. Reproduce
{noformat}
sudo install_solr_service.sh solr-6.4.0.tgz
sudo su solr
export SOLR_INCLUDE="/etc/default/solr.in.sh"
/opt/solr/bin/solr -e dih

Starting up Solr on port 8983 using command:
/opt/solr/bin/solr start -p 8983 -s "/opt/solr/example/example-DIH/solr"

Exception in thread "main" java.nio.file.AccessDeniedException: 
/opt/solr/example/example-DIH/solr/../logs
at 
sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at 
sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:384)
at java.nio.file.Files.createDirectory(Files.java:674)
at java.nio.file.Files.createAndCheckIsDirectory(Files.java:781)
at java.nio.file.Files.createDirectories(Files.java:767)
at 
org.apache.solr.util.SolrCLI$UtilsTool.archiveGcLogs(SolrCLI.java:3604)
at org.apache.solr.util.SolrCLI$UtilsTool.runTool(SolrCLI.java:3587)
at org.apache.solr.util.SolrCLI.main(SolrCLI.java:256)
Failed archiving old GC logs
Exception in thread "main" java.nio.file.AccessDeniedException: 
/opt/solr/example/example-DIH/solr/../logs
at 
sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at 
sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:384)
at java.nio.file.Files.createDirectory(Files.java:674)
at java.nio.file.Files.createAndCheckIsDirectory(Files.java:781)
at java.nio.file.Files.createDirectories(Files.java:767)
at 
org.apache.solr.util.SolrCLI$UtilsTool.archiveConsoleLogs(SolrCLI.java:3633)
at org.apache.solr.util.SolrCLI$UtilsTool.runTool(SolrCLI.java:3590)
at org.apache.solr.util.SolrCLI.main(SolrCLI.java:256)
Failed archiving old console logs

ERROR: Logs directory /opt/solr/example/example-DIH/solr/../logs could not be 
created. Exiting

ERROR: Process exited with an error: 1 (Exit value: 1)
{noformat}


  was:
The examples do not respect SOLR_LOGS_DIR env, but always try to write logs to 
{{SOLR_HOME/../logs}}. Problem is when Solr is installed using the installer 
script, then {{/opt/solr}} is not supposed to be writable, and starting the 
examples fail.

h3. Reproduce
{noformat}
sudo install_solr_service.sh solr-6.4.0.tgz
sudo su solr
export SOLR_INCLUDE="/etc/default/solr.in.sh"
/opt/solr/bin/solr -e dih

Starting up Solr on port 8983 using command:
/opt/solr/bin/solr start -p 8983 -s "/opt/solr/example/example-DIH/solr"

Exception in thread "main" java.nio.file.AccessDeniedException: 
/opt/solr/example/example-DIH/solr/../logs
at 
sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at 
sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:384)
at java.nio.file.Files.createDirectory(Files.java:674)
at java.nio.file.Files.createAndCheckIsDirectory(Files.java:781)
at java.nio.file.Files.createDirectories(Files.java:767)
at 
org.apache.solr.util.SolrCLI$UtilsTool.archiveGcLogs(SolrCLI.java:3604)
at org.apache.solr.util.SolrCLI$UtilsTool.runTool(SolrCLI.java:3587)
at org.apache.solr.util.SolrCLI.main(SolrCLI.java:256)
Failed archiving old GC logs
Exception in thread "main" java.nio.file.AccessDeniedException: 
/opt/solr/example/example-DIH/solr/../logs
at 
sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at 
sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:384)
at java.nio.file.Files.createDirectory(Files.java:674)
at java.nio.file.Files.createAndCheckIsDirectory(Files.java:781)
at java.nio.file.Files.createDirectories(Files.java:767)
at 
org.apache.solr.util.SolrCLI$UtilsTool.archiveConsoleLogs(SolrCLI.java:3633)
at org.apache.solr.util.SolrCLI$UtilsTool.runTool(SolrCLI.java:3590)

[jira] [Updated] (SOLR-10095) Examples do not respect SOLR_HOME and SOLR_LOGS_DIR

[JIRA]

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

Jan Høydahl updated SOLR-10095:
---
Summary: Examples do not respect SOLR_HOME and SOLR_LOGS_DIR  (was: 
Examples do not respect SOLR_LOGS_DIR)

> Examples do not respect SOLR_HOME and SOLR_LOGS_DIR
> ---
>
> Key: SOLR-10095
> URL: https://issues.apache.org/jira/browse/SOLR-10095
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Jan Høydahl
>
> The examples do not respect SOLR_LOGS_DIR env, but always try to write logs 
> to {{SOLR_HOME/../logs}}. Problem is when Solr is installed using the 
> installer script, then {{/opt/solr}} is not supposed to be writable, and 
> starting the examples fail.
> h3. Reproduce
> {noformat}
> sudo install_solr_service.sh solr-6.4.0.tgz
> sudo su solr
> export SOLR_INCLUDE="/etc/default/solr.in.sh"
> /opt/solr/bin/solr -e dih
> Starting up Solr on port 8983 using command:
> /opt/solr/bin/solr start -p 8983 -s "/opt/solr/example/example-DIH/solr"
> Exception in thread "main" java.nio.file.AccessDeniedException: 
> /opt/solr/example/example-DIH/solr/../logs
>   at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
>   at 
> sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:384)
>   at java.nio.file.Files.createDirectory(Files.java:674)
>   at java.nio.file.Files.createAndCheckIsDirectory(Files.java:781)
>   at java.nio.file.Files.createDirectories(Files.java:767)
>   at 
> org.apache.solr.util.SolrCLI$UtilsTool.archiveGcLogs(SolrCLI.java:3604)
>   at org.apache.solr.util.SolrCLI$UtilsTool.runTool(SolrCLI.java:3587)
>   at org.apache.solr.util.SolrCLI.main(SolrCLI.java:256)
> Failed archiving old GC logs
> Exception in thread "main" java.nio.file.AccessDeniedException: 
> /opt/solr/example/example-DIH/solr/../logs
>   at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
>   at 
> sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:384)
>   at java.nio.file.Files.createDirectory(Files.java:674)
>   at java.nio.file.Files.createAndCheckIsDirectory(Files.java:781)
>   at java.nio.file.Files.createDirectories(Files.java:767)
>   at 
> org.apache.solr.util.SolrCLI$UtilsTool.archiveConsoleLogs(SolrCLI.java:3633)
>   at org.apache.solr.util.SolrCLI$UtilsTool.runTool(SolrCLI.java:3590)
>   at org.apache.solr.util.SolrCLI.main(SolrCLI.java:256)
> Failed archiving old console logs
> ERROR: Logs directory /opt/solr/example/example-DIH/solr/../logs could not be 
> created. Exiting
> ERROR: Process exited with an error: 1 (Exit value: 1)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10096) Parallel SQL not returning the correct results for count distinct aggregation

[Timothy Potter (JIRA)]

Timothy Potter created SOLR-10096:
-

 Summary: Parallel SQL not returning the correct results for count 
distinct aggregation
 Key: SOLR-10096
 URL: https://issues.apache.org/jira/browse/SOLR-10096
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Parallel SQL
Affects Versions: 6.3
Reporter: Timothy Potter


While trying to compare the results of this perf exp. blogged here:
https://www.periscopedata.com/blog/use-subqueries-to-count-distinct-50x-faster.html

I tried this with 6.3 and it only returns the dashboard_id's:

{code}
select dashboard_id, count(distinct user_id) as ct from time_on_site_logs group 
by dashboard_id
{code}

Results: (where is ct?)
{code}
{"result-set":{"docs":[
{"dashboard_id":0},
{"dashboard_id":2},
{"dashboard_id":5},
{"dashboard_id":6},
{"dashboard_id":8},
{"dashboard_id":10},
{"dashboard_id":12},
{"dashboard_id":13},
{"dashboard_id":14},
{"dashboard_id":15},
...
{code}

So I dropped the alias for {{count(distinct user_id)}} and got the wrong 
results (i.e. it's not applying the distinct for user_id's):
{code}
{"result-set":{"docs":[
{"count(*)":8288,"dashboard_id":0},
{"count(*)":7392,"dashboard_id":2},
{"count(*)":23800,"dashboard_id":5},
{"count(*)":25032,"dashboard_id":6},
{"count(*)":8960,"dashboard_id":8},
{"count(*)":7840,"dashboard_id":10},
{"count(*)":17192,"dashboard_id":12},
{code}

So I'm guessing this isn't a supported syntax yet?

Also, probably a different issue, but I then tried this query:
{code}
select distinct dashboard_id, user_id from time_on_site_logs
{code}
and it took ~70 secs (m3.xlarge), which is very surprising because this 
streaming expression (which basically does the initial query above):
{code}
select(rollup(facet(time_on_site_logs, q="*:*", buckets="dashboard_id,user_id", 
bucketSizeLimit=2000, bucketSorts="dashboard_id asc",count(*)), 
over="dashboard_id", count(*)), dashboard_id,count(*) as unique_users)
{code}
Returns in ~1.5 secs ... that's a huge difference in performance.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10095) Examples do not respect SOLR_LOGS_DIR

[JIRA]

Jan Høydahl created SOLR-10095:
--

 Summary: Examples do not respect SOLR_LOGS_DIR
 Key: SOLR-10095
 URL: https://issues.apache.org/jira/browse/SOLR-10095
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: scripts and tools
Reporter: Jan Høydahl


The examples do not respect SOLR_LOGS_DIR env, but always try to write logs to 
{{SOLR_HOME/../logs}}. Problem is when Solr is installed using the installer 
script, then {{/opt/solr}} is not supposed to be writable, and starting the 
examples fail.

h3. Reproduce
{noformat}
sudo install_solr_service.sh solr-6.4.0.tgz
sudo su solr
export SOLR_INCLUDE="/etc/default/solr.in.sh"
/opt/solr/bin/solr -e dih

Starting up Solr on port 8983 using command:
/opt/solr/bin/solr start -p 8983 -s "/opt/solr/example/example-DIH/solr"

Exception in thread "main" java.nio.file.AccessDeniedException: 
/opt/solr/example/example-DIH/solr/../logs
at 
sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at 
sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:384)
at java.nio.file.Files.createDirectory(Files.java:674)
at java.nio.file.Files.createAndCheckIsDirectory(Files.java:781)
at java.nio.file.Files.createDirectories(Files.java:767)
at 
org.apache.solr.util.SolrCLI$UtilsTool.archiveGcLogs(SolrCLI.java:3604)
at org.apache.solr.util.SolrCLI$UtilsTool.runTool(SolrCLI.java:3587)
at org.apache.solr.util.SolrCLI.main(SolrCLI.java:256)
Failed archiving old GC logs
Exception in thread "main" java.nio.file.AccessDeniedException: 
/opt/solr/example/example-DIH/solr/../logs
at 
sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at 
sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:384)
at java.nio.file.Files.createDirectory(Files.java:674)
at java.nio.file.Files.createAndCheckIsDirectory(Files.java:781)
at java.nio.file.Files.createDirectories(Files.java:767)
at 
org.apache.solr.util.SolrCLI$UtilsTool.archiveConsoleLogs(SolrCLI.java:3633)
at org.apache.solr.util.SolrCLI$UtilsTool.runTool(SolrCLI.java:3590)
at org.apache.solr.util.SolrCLI.main(SolrCLI.java:256)
Failed archiving old console logs

ERROR: Logs directory /opt/solr/example/example-DIH/solr/../logs could not be 
created. Exiting

ERROR: Process exited with an error: 1 (Exit value: 1)
{noformat}




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10036) Revise jackson-core version from 2.5.4 to latest

[Shawn Heisey (JIRA)]

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

Shawn Heisey updated SOLR-10036:

Attachment: SOLR-10036.patch

Patch against master.  Precommit passes on Linux.

Realized that I was running tests as root, which makes some of them fail.  
Trying again as a regular user.

> Revise jackson-core version from 2.5.4 to latest
> 
>
> Key: SOLR-10036
> URL: https://issues.apache.org/jira/browse/SOLR-10036
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Shashank Pedamallu
> Attachments: SOLR-10036.patch
>
>
> The current jackson-core dependency in Solr is not compatible with Amazon AWS 
> S3 dependency. AWS S3 requires jackson-core-2.6.6 while Solr uses 
> jackson-core-dependency-2.5.4. This is blocking the usage of latest updates 
> from S3.
> It would be greatly helpful if someone could revise the jackson-core jar in 
> Solr to the latest version. This is a ShowStopper for our Public company.
> Details of my Setup:
> Solr Version: 6.3
> AWS SDK version: 1.11.76



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Call for MODERATORs on the dev and java-user mailing lists

[Steve Rowe]

Hi Aurelian, 

Your response to the dev@ list required moderation, likely because you’re not 
subscribed to the dev@ list with the email address you used to respond.  Please 
first go subscribe to the dev@ list with the email you used to send the message 
below - see  - 
then let me know when you’ve done that.

You don’t need to be online every day - just make a habit of dealing with the 
MODERATE emails you get on a regular basis.  The system is set up so that 
multiple people have the same responsibility, the idea being that one of us 
will deal with the non-spam in a timely fashion, even though none of us is 
online all the time.

Thanks!

--
Steve
www.lucidworks.com

> On Feb 3, 2017, at 3:17 PM, aurelian rosca  wrote:
> 
> I think i can handle both. I will take a look again next morning about
> requirements and i will let you know if I will have questions. Should i be
> online each day or just 5days/week.
> Pe 03.02.2017 22:07, "Steve Rowe"  a scris:
> 
>> Great!  We only needed one new volunteer on each of the two lists, so we
>> should be all set now.
>> 
>> I’ll go make an INFRA JIRA requesting the moderator changes.
>> 
>> --
>> Steve
>> www.lucidworks.com
>> 
>>> On Feb 3, 2017, at 3:02 PM, aurelian rosca 
>> wrote:
>>> 
>>> Both.
>>> Pe 03.02.2017 21:59, "Steve Rowe"  a scris:
>>> 
 Thanks Aurelian!
 
 To be clear: are you volunteering to moderate both the dev@ and
>> java-user@
 mailing lists? Or only the java-user@ mailing list?
 
 The only requirement is that you are a subscriber to each list you
 volunteer to moderate.
 
 --
 Steve
 www.lucidworks.com
 
> On Feb 3, 2017, at 2:17 PM, aurelian rosca 
 wrote:
> 
> Seems to be an easy job. I am in.
> 
> On Feb 3, 2017 9:13 PM, "Steve Rowe"  wrote:
> 
>> Hello subscribers to dev@l.a.o and java-user@l.a.o:
>> 
>> We need to replace a moderator who no longer wishes to do the job on
 these
>> two mailing lists.
>> 
>> If anyone is interested in being a MODERATOR, please reply back to
>> this
>> thread.  Being a moderator is really easy, the main chunk of the
>> responsibility is just hitting "reply-to all" if you get a message
>> with
 the
>> subject MODERATE and the body of the message isn't spam.
>> 
>> More details can be found on the wiki: https://wiki.apache.org/solr/
>> MailingListModeratorInfo
>> 
>> --
>> Steve
>> www.lucidworks.com
>> 
>> 
>> -
>> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: java-user-h...@lucene.apache.org
>> 
>> 
 
 
 -
 To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
 For additional commands, e-mail: java-user-h...@lucene.apache.org
 
 
>> 
>> 
>> -
>> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: java-user-h...@lucene.apache.org
>> 
>> 


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

[jira] [Updated] (SOLR-10094) /export handler (master only) loses the sort deep into the result set

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-10094:
--
Description: 
This bug only occurs in master, and was likely introduced with the new doc 
values iterator API which is slated for 7.0.

This bug was not caught by tests because there are no tests that have a large 
enough result set to catch the issue. As part of this ticket a test with a 
large enough result set will be added to reproduce the bug.



  was:
This bug only occurs in master, and was likely introduced with the doc values 
new iterator API which is slated for 7.0.

This bug was not caught by tests because there are no tests that have a large 
enough result set to catch the issue. As part of this ticket a test with a 
large enough result set will be added to reproduce the bug.




> /export handler (master only) loses the sort deep into the result set
> -
>
> Key: SOLR-10094
> URL: https://issues.apache.org/jira/browse/SOLR-10094
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (7.0)
>Reporter: Joel Bernstein
>Priority: Blocker
>
> This bug only occurs in master, and was likely introduced with the new doc 
> values iterator API which is slated for 7.0.
> This bug was not caught by tests because there are no tests that have a large 
> enough result set to catch the issue. As part of this ticket a test with a 
> large enough result set will be added to reproduce the bug.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10094) /export handler (master only) loses the sort deep into the result set

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-10094:
---

This is listed as a blocker for 7.0 but should be fixed well in advance of 7.0. 
Currently it also blocking SOLR-8593, because manual testing of the new 
SQLHandler doesn't work properly.

> /export handler (master only) loses the sort deep into the result set
> -
>
> Key: SOLR-10094
> URL: https://issues.apache.org/jira/browse/SOLR-10094
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (7.0)
>Reporter: Joel Bernstein
>Priority: Blocker
>
> This bug only occurs in master, and was likely introduced with the doc values 
> new iterator API which is slated for 7.0.
> This bug was not caught by tests because there are no tests that have a large 
> enough result set to catch the issue. As part of this ticket a test with a 
> large enough result set will be added to reproduce the bug.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10094) /export handler (master only) loses the sort deep into the result set

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-10094:
--
Priority: Blocker  (was: Major)

> /export handler (master only) loses the sort deep into the result set
> -
>
> Key: SOLR-10094
> URL: https://issues.apache.org/jira/browse/SOLR-10094
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (7.0)
>Reporter: Joel Bernstein
>Priority: Blocker
>
> This bug only occurs in master, and was likely introduced with the doc values 
> new iterator API which is slated for 7.0.
> This bug was not caught by tests because there are no tests that have a large 
> enough result set to catch the issue. As part of this ticket a test with a 
> large enough result set will be added to reproduce the bug.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10094) /export handler (master only) loses the sort deep into the result set

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-10094:
--
Description: 
This bug only occurs in master, and was likely introduced with the doc values 
new iterator API which is slated for 7.0.

This bug was not caught by tests because there are no tests that have a large 
enough result set to catch the issue. As part of this ticket a test with a 
large enough result set will be added to reproduce the bug.



  was:
This bug only occurs in master, and was likely introduced with the doc values 
new iterator API which is slated for 7.0.

This bug was not caught by tests because there are no tests that have a large 
enough result set to catch the issue. As part of this ticket a test with a 
large enough result set will be added to reproduce the bug.


> /export handler (master only) loses the sort deep into the result set
> -
>
> Key: SOLR-10094
> URL: https://issues.apache.org/jira/browse/SOLR-10094
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (7.0)
>Reporter: Joel Bernstein
>Priority: Blocker
>
> This bug only occurs in master, and was likely introduced with the doc values 
> new iterator API which is slated for 7.0.
> This bug was not caught by tests because there are no tests that have a large 
> enough result set to catch the issue. As part of this ticket a test with a 
> large enough result set will be added to reproduce the bug.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Call for MODERATORs on the dev and java-user mailing lists

[aurelian rosca]

I think i can handle both. I will take a look again next morning about
requirements and i will let you know if I will have questions. Should i be
online each day or just 5days/week.
Pe 03.02.2017 22:07, "Steve Rowe"  a scris:

> Great!  We only needed one new volunteer on each of the two lists, so we
> should be all set now.
>
> I’ll go make an INFRA JIRA requesting the moderator changes.
>
> --
> Steve
> www.lucidworks.com
>
> > On Feb 3, 2017, at 3:02 PM, aurelian rosca 
> wrote:
> >
> > Both.
> > Pe 03.02.2017 21:59, "Steve Rowe"  a scris:
> >
> >> Thanks Aurelian!
> >>
> >> To be clear: are you volunteering to moderate both the dev@ and
> java-user@
> >> mailing lists? Or only the java-user@ mailing list?
> >>
> >> The only requirement is that you are a subscriber to each list you
> >> volunteer to moderate.
> >>
> >> --
> >> Steve
> >> www.lucidworks.com
> >>
> >>> On Feb 3, 2017, at 2:17 PM, aurelian rosca 
> >> wrote:
> >>>
> >>> Seems to be an easy job. I am in.
> >>>
> >>> On Feb 3, 2017 9:13 PM, "Steve Rowe"  wrote:
> >>>
>  Hello subscribers to dev@l.a.o and java-user@l.a.o:
> 
>  We need to replace a moderator who no longer wishes to do the job on
> >> these
>  two mailing lists.
> 
>  If anyone is interested in being a MODERATOR, please reply back to
> this
>  thread.  Being a moderator is really easy, the main chunk of the
>  responsibility is just hitting "reply-to all" if you get a message
> with
> >> the
>  subject MODERATE and the body of the message isn't spam.
> 
>  More details can be found on the wiki: https://wiki.apache.org/solr/
>  MailingListModeratorInfo
> 
>  --
>  Steve
>  www.lucidworks.com
> 
> 
>  -
>  To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
>  For additional commands, e-mail: java-user-h...@lucene.apache.org
> 
> 
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: java-user-h...@lucene.apache.org
> >>
> >>
>
>
> -
> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-user-h...@lucene.apache.org
>
>

[jira] [Created] (SOLR-10094) /export handler (master only) loses the sort deep into the result set

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-10094:
-

 Summary: /export handler (master only) loses the sort deep into 
the result set
 Key: SOLR-10094
 URL: https://issues.apache.org/jira/browse/SOLR-10094
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: master (7.0)
Reporter: Joel Bernstein


This bug only occurs in master, and was likely introduced with the doc values 
new iterator API which is slated for 7.0.

This bug was not caught by tests because there are no tests that have a large 
enough result set to catch the issue. As part of this ticket a test with a 
large enough result set will be added to reproduce the bug.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Call for MODERATORs on the dev and java-user mailing lists

[Steve Rowe]

Great!  We only needed one new volunteer on each of the two lists, so we should 
be all set now.

I’ll go make an INFRA JIRA requesting the moderator changes.

--
Steve
www.lucidworks.com

> On Feb 3, 2017, at 3:02 PM, aurelian rosca  wrote:
> 
> Both.
> Pe 03.02.2017 21:59, "Steve Rowe"  a scris:
> 
>> Thanks Aurelian!
>> 
>> To be clear: are you volunteering to moderate both the dev@ and java-user@
>> mailing lists? Or only the java-user@ mailing list?
>> 
>> The only requirement is that you are a subscriber to each list you
>> volunteer to moderate.
>> 
>> --
>> Steve
>> www.lucidworks.com
>> 
>>> On Feb 3, 2017, at 2:17 PM, aurelian rosca 
>> wrote:
>>> 
>>> Seems to be an easy job. I am in.
>>> 
>>> On Feb 3, 2017 9:13 PM, "Steve Rowe"  wrote:
>>> 
 Hello subscribers to dev@l.a.o and java-user@l.a.o:
 
 We need to replace a moderator who no longer wishes to do the job on
>> these
 two mailing lists.
 
 If anyone is interested in being a MODERATOR, please reply back to this
 thread.  Being a moderator is really easy, the main chunk of the
 responsibility is just hitting "reply-to all" if you get a message with
>> the
 subject MODERATE and the body of the message isn't spam.
 
 More details can be found on the wiki: https://wiki.apache.org/solr/
 MailingListModeratorInfo
 
 --
 Steve
 www.lucidworks.com
 
 
 -
 To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
 For additional commands, e-mail: java-user-h...@lucene.apache.org
 
 
>> 
>> 
>> -
>> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: java-user-h...@lucene.apache.org
>> 
>> 


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

[jira] [Updated] (SOLR-9217) {!join score=..}.. should delay join to createWeight

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-9217:
---
Description: 
{{ScoreJoinQParserPlugin.XxxCoreJoinQuery}} executes 
{{JoinUtil.createJoinQuery}} on {{rewrite()}}, but it's inefficient in 
{{filter(...)}} syntax or fq. It's better to do that in {{createWeigh()}} as 
it's done in classic Solr {{JoinQuery}}, {{JoinQParserPlugin}}.
All existing tests is enough, we just need to assert rewrite behavior - it 
should rewrite on enclosing range query or so, and doesn't on plain term query. 
 

  was:
{{ScoreJoinQParserPlugin.XxxCoreJoinQuery}} executes 
{{JoinUtil.createJoinQuery}} on {{rewrite()}}, but it makes less effective in 
{{filter(...)}} syntax. It's better to do that in {{createWeigh()}} as it's 
done in classic Solr {{JoinQuery}}.
All existing tests is enough, we just need to assert rewrite behavior - it 
should rewrite on enclosing range query or so, and doesn't on plain term query. 
 


> {!join score=..}.. should delay join to createWeight
> 
>
> Key: SOLR-9217
> URL: https://issues.apache.org/jira/browse/SOLR-9217
> Project: Solr
>  Issue Type: Improvement
>  Components: query parsers
>Affects Versions: 6.1
>Reporter: Mikhail Khludnev
>Priority: Minor
>  Labels: newbie, newdev
>
> {{ScoreJoinQParserPlugin.XxxCoreJoinQuery}} executes 
> {{JoinUtil.createJoinQuery}} on {{rewrite()}}, but it's inefficient in 
> {{filter(...)}} syntax or fq. It's better to do that in {{createWeigh()}} as 
> it's done in classic Solr {{JoinQuery}}, {{JoinQParserPlugin}}.
> All existing tests is enough, we just need to assert rewrite behavior - it 
> should rewrite on enclosing range query or so, and doesn't on plain term 
> query.  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9217) {!join score=..}.. should delay join to createWeight

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-9217:


Hello, 
[~shanky_ty], you are welcome, just look at 
https://wiki.apache.org/solr/HowToContribute .
I've checked that the description is still valid and describes where to start 
well.   

> {!join score=..}.. should delay join to createWeight
> 
>
> Key: SOLR-9217
> URL: https://issues.apache.org/jira/browse/SOLR-9217
> Project: Solr
>  Issue Type: Improvement
>  Components: query parsers
>Affects Versions: 6.1
>Reporter: Mikhail Khludnev
>Priority: Minor
>  Labels: newbie, newdev
>
> {{ScoreJoinQParserPlugin.XxxCoreJoinQuery}} executes 
> {{JoinUtil.createJoinQuery}} on {{rewrite()}}, but it makes less effective in 
> {{filter(...)}} syntax. It's better to do that in {{createWeigh()}} as it's 
> done in classic Solr {{JoinQuery}}.
> All existing tests is enough, we just need to assert rewrite behavior - it 
> should rewrite on enclosing range query or so, and doesn't on plain term 
> query.  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Call for MODERATORs on the dev and java-user mailing lists

[Steve Rowe]

Thanks Aurelian!

To be clear: are you volunteering to moderate both the dev@ and java-user@ 
mailing lists? Or only the java-user@ mailing list?

The only requirement is that you are a subscriber to each list you volunteer to 
moderate.

--
Steve
www.lucidworks.com

> On Feb 3, 2017, at 2:17 PM, aurelian rosca  wrote:
> 
> Seems to be an easy job. I am in.
> 
> On Feb 3, 2017 9:13 PM, "Steve Rowe"  wrote:
> 
>> Hello subscribers to dev@l.a.o and java-user@l.a.o:
>> 
>> We need to replace a moderator who no longer wishes to do the job on these
>> two mailing lists.
>> 
>> If anyone is interested in being a MODERATOR, please reply back to this
>> thread.  Being a moderator is really easy, the main chunk of the
>> responsibility is just hitting "reply-to all" if you get a message with the
>> subject MODERATE and the body of the message isn't spam.
>> 
>> More details can be found on the wiki: https://wiki.apache.org/solr/
>> MailingListModeratorInfo
>> 
>> --
>> Steve
>> www.lucidworks.com
>> 
>> 
>> -
>> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: java-user-h...@lucene.apache.org
>> 
>> 


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

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+153) - Build # 18898 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18898/
Java: 64bit/jdk-9-ea+153 -XX:+UseCompressedOops -XX:+UseSerialGC

3 tests failed.
FAILED:  org.apache.solr.handler.TestReqParamsAPI.test

Error Message:
Could not get expected value  'A val' for path 'response/params/x/a' full 
output: {   "responseHeader":{ "status":0, "QTime":0},   
"response":{"znodeVersion":-1}},  from server:  
http://127.0.0.1:39385/solr/collection1_shard1_replica1

Stack Trace:
java.lang.AssertionError: Could not get expected value  'A val' for path 
'response/params/x/a' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "response":{"znodeVersion":-1}},  from server:  
http://127.0.0.1:39385/solr/collection1_shard1_replica1
at 
__randomizedtesting.SeedInfo.seed([28FE3AF9060D05D1:A0AA0523A8F16829]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:556)
at 
org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:110)
at 
org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:69)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:543)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 
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 

[jira] [Updated] (SOLR-9912) SimpleFacets - support facet.excludeTerms parameter

[Jonny Marks (JIRA)]

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

Jonny Marks updated SOLR-9912:
--
Attachment: SOLR-9912.patch

Updated patch to use Predicate instead of BytesRefFilter

> SimpleFacets - support facet.excludeTerms parameter
> ---
>
> Key: SOLR-9912
> URL: https://issues.apache.org/jira/browse/SOLR-9912
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Jonny Marks
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9912.patch, SOLR-9912.patch
>
>
> This ticket is for supporting a new facet.excludeTerms parameter for removing 
> specific terms from the facet counts, without having to exclude the terms 
> from the index itself.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Call for MODERATORs on the dev and java-user mailing lists

[Steve Rowe]

Hello subscribers to dev@l.a.o and java-user@l.a.o:

We need to replace a moderator who no longer wishes to do the job on these two 
mailing lists.

If anyone is interested in being a MODERATOR, please reply back to this thread. 
 Being a moderator is really easy, the main chunk of the responsibility is just 
hitting "reply-to all" if you get a message with the subject MODERATE and the 
body of the message isn't spam.

More details can be found on the wiki: 
https://wiki.apache.org/solr/MailingListModeratorInfo

--
Steve
www.lucidworks.com


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

[jira] [Updated] (SOLR-9914) SimpleFacets: refactor "contains" check into "SubstringBytesRefMatcher" class

[Jonny Marks (JIRA)]

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

Jonny Marks updated SOLR-9914:
--
Attachment: SOLR-9914.patch

Thanks for the suggestion [~dsmiley], I've updated the patch to use Predicate.

> SimpleFacets: refactor "contains" check into "SubstringBytesRefMatcher" class
> -
>
> Key: SOLR-9914
> URL: https://issues.apache.org/jira/browse/SOLR-9914
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Jonny Marks
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9914.patch, SOLR-9914.patch
>
>
> This patch refactors the "contains" logic for only including constraints 
> which contain a given substring, into a "BytesRefMatcher" interface and 
> "SubstringBytesRefMatcher" implementation. 
> This allows users to have custom logic for including terms in the filter 
> counts, not only based on substring matches.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7674) java.lang.IllegalStateException: Child query must not match same docs with parent filter. Combine them as must clauses (+) to find a problem doc. docId=2147483647, cla

[Tim Underwood (JIRA)]

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

Tim Underwood commented on LUCENE-7674:
---

I also noticed that I have some deleteByQuery calls that target parents 
documents but not their children (my assumption being that Solr or Lucene would 
also delete the corresponding child documents).  Perhaps that is what is 
causing the orphan child documents.  I'll be sure to explicitly delete those 
also.

> java.lang.IllegalStateException: Child query must not match same docs with 
> parent filter. Combine them as must clauses (+) to find a problem doc. 
> docId=2147483647, class org.apache.lucene.search.ConjunctionScorer
> 
>
> Key: LUCENE-7674
> URL: https://issues.apache.org/jira/browse/LUCENE-7674
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.3
>Reporter: Tim Underwood
>
> Started seeing this error message on a production Solr 6.3.0 system today 
> making use of parent/child documents:
> {code}
> java.lang.IllegalStateException: Child query must not match same docs with 
> parent filter. Combine them as must clauses (+) to find a problem doc. 
> docId=2147483647, class org.apache.lucene.search.ConjunctionScorer
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.checkOrthogonal(ToParentBlockJoinQuery.java:403)
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.access$400(ToParentBlockJoinQuery.java:206)
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer$1.nextDoc(ToParentBlockJoinQuery.java:327)
> at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:219)
> at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:172)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:669)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:473)
> at 
> org.apache.solr.search.DocSetUtil.createDocSetGeneric(DocSetUtil.java:106)
> at org.apache.solr.search.DocSetUtil.createDocSet(DocSetUtil.java:95)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1379)
> at 
> org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:1057)
> at 
> org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1227)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListAndSetNC(SolrIndexSearcher.java:1842)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1616)
> at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:617)
> at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:531)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:153)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2213)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:303)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:254)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
> at 
> 

[jira] [Commented] (SOLR-10032) Create report to assess Solr test quality at a commit point.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-10032:


bq. but you seemed to have had no problems with that test

This test did actually fail .07% of the time in the previous report. In future 
reports I will include the previous fail rate as well.

> Create report to assess Solr test quality at a commit point.
> 
>
> Key: SOLR-10032
> URL: https://issues.apache.org/jira/browse/SOLR-10032
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: Lucene-Solr Master Test Beast Results 
> 01-24-2017-9899cbd031dc3fc37a384b1f9e2b379e90a9a3a6 Level Medium- Running 30 
> iterations, 12 at a time .pdf, Lucene-Solr Master Test Beasults 
> 02-01-2017-bbc455de195c83d9f807980b510fa46018f33b1b Level Medium- Running 30 
> iterations, 10 at a time.pdf
>
>
> We have many Jenkins instances blasting tests, some official, some policeman, 
> I and others have or had their own, and the email trail proves the power of 
> the Jenkins cluster to find test fails.
> However, I still have a very hard time with some basic questions:
> what tests are flakey right now? which test fails actually affect devs most? 
> did I break it? was that test already flakey? is that test still flakey? what 
> are our worst tests right now? is that test getting better or worse?
> We really need a way to see exactly what tests are the problem, not because 
> of OS or environmental issues, but more basic test quality issues. Which 
> tests are flakey and how flakey are they at any point in time.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10036) Revise jackson-core version from 2.5.4 to latest

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-10036:

Issue Type: Improvement  (was: Wish)

> Revise jackson-core version from 2.5.4 to latest
> 
>
> Key: SOLR-10036
> URL: https://issues.apache.org/jira/browse/SOLR-10036
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Shashank Pedamallu
>Priority: Blocker
>
> The current jackson-core dependency in Solr is not compatible with Amazon AWS 
> S3 dependency. AWS S3 requires jackson-core-2.6.6 while Solr uses 
> jackson-core-dependency-2.5.4. This is blocking the usage of latest updates 
> from S3.
> It would be greatly helpful if someone could revise the jackson-core jar in 
> Solr to the latest version. This is a ShowStopper for our Public company.
> Details of my Setup:
> Solr Version: 6.3
> AWS SDK version: 1.11.76



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10036) Revise jackson-core version from 2.5.4 to latest

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-10036:

Priority: Major  (was: Blocker)

> Revise jackson-core version from 2.5.4 to latest
> 
>
> Key: SOLR-10036
> URL: https://issues.apache.org/jira/browse/SOLR-10036
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Shashank Pedamallu
>
> The current jackson-core dependency in Solr is not compatible with Amazon AWS 
> S3 dependency. AWS S3 requires jackson-core-2.6.6 while Solr uses 
> jackson-core-dependency-2.5.4. This is blocking the usage of latest updates 
> from S3.
> It would be greatly helpful if someone could revise the jackson-core jar in 
> Solr to the latest version. This is a ShowStopper for our Public company.
> Details of my Setup:
> Solr Version: 6.3
> AWS SDK version: 1.11.76



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10036) Revise jackson-core version from 2.5.4 to latest

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-10036:
-

[~elyograg] - Are you planning to post a patch/commit the bump of jackson?

> Revise jackson-core version from 2.5.4 to latest
> 
>
> Key: SOLR-10036
> URL: https://issues.apache.org/jira/browse/SOLR-10036
> Project: Solr
>  Issue Type: Wish
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Shashank Pedamallu
>Priority: Blocker
>
> The current jackson-core dependency in Solr is not compatible with Amazon AWS 
> S3 dependency. AWS S3 requires jackson-core-2.6.6 while Solr uses 
> jackson-core-dependency-2.5.4. This is blocking the usage of latest updates 
> from S3.
> It would be greatly helpful if someone could revise the jackson-core jar in 
> Solr to the latest version. This is a ShowStopper for our Public company.
> Details of my Setup:
> Solr Version: 6.3
> AWS SDK version: 1.11.76



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: VOTE: Apache Solr Ref Guide for 6.4

[Tomás Fernández Löbbe]

+1 eyeballed all the pages and read some random sections.
Two minor things I caught (not for respin), some of the examples in LTR for
some reason are very narrow (pages 355 to 365).
We still talk about DismaxRequestHandler in "Overview of Searching in
Solr", and we even say it's the default. I'll go and change it now.



On Wed, Feb 1, 2017 at 7:11 AM, Joel Bernstein  wrote:

> +1. I reviewed the changes to the Streaming Expressions docs. They look
> good.
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> On Tue, Jan 31, 2017 at 11:40 PM, David Smiley 
> wrote:
>
>> +1 from me.  I reviewed the Highlighting section specifically and found a
>> small error (fixed in Confluence just now) but not enough to warrant a
>> respin IMO.
>>
>> On Tue, Jan 31, 2017 at 10:44 AM Cassandra Targett 
>> wrote:
>>
>>> Please vote to release the Apache Solr Ref Guide for Solr 6.4.
>>>
>>> Artifacts can be found at:
>>> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide
>>> /apache-solr-ref-guide-6.4-RC0/
>>>
>>> $ cat apache-solr-ref-guide-6.4-RC0/apache-solr-ref-guide-6.4.pdf.sha1
>>> 2e5f27c1aae36fde5717dd01a4495c5e299c9407  apache-solr-ref-guide-6.4.pdf
>>>
>>> I'm not a huge fan of releasing with issues found at the last minute
>>> such as the one Erick E filed last night (SOLR-10061, about issues
>>> with the CoreAdmin API docs), but in this case I have a bunch of other
>>> stuff to do this week & next at the day job, I don't know the
>>> CoreAdmin API that well, and when SOLR-8029 (v2 API) is backported to
>>> 6.x, we will likely revamp ALL of the API pages, including that one.
>>>
>>> So, that said, here's +1 from me.
>>>
>>> Cassandra
>>>
>>> -
>>> 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] [Comment Edited] (SOLR-8581) Integration tests for rolling upgrades

[Walter Underwood (JIRA)]

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

Walter Underwood edited comment on SOLR-8581 at 2/3/17 6:41 PM:


Leader election in a new/old two node cluster. Make sure it can go old->new and 
new->old.

Run some indexing after each election.


was (Author: wunder):
Leader election in a new/old two node cluster. Make sure it can go old->new and 
new->old.

>  Integration tests for rolling upgrades
> ---
>
> Key: SOLR-8581
> URL: https://issues.apache.org/jira/browse/SOLR-8581
> Project: Solr
>  Issue Type: Test
>Reporter: Vivek Narang
>
> I intend to work on an integration test suite for Solr, to test for issues to 
> deal with back compat, rolling upgrades etc.
> The interface for the test suite, as I'm planning, would be to have it accept 
> two versions of Solr (either released versions or trunk/branch).
> I work on SolrCloud, and we need something like this to enable us to upgrade 
> more frequently. I had a conversation with @Ishan Chattopadhyaya, who 
> emphasised to me the need to have something like this.
> If there's already any ongoing effort in doing this, I can help out there. 
> Please let me know.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-8581) Integration tests for rolling upgrades

[Walter Underwood (JIRA)]

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

Walter Underwood commented on SOLR-8581:


Distributed search with all variations of global IDF support.

>  Integration tests for rolling upgrades
> ---
>
> Key: SOLR-8581
> URL: https://issues.apache.org/jira/browse/SOLR-8581
> Project: Solr
>  Issue Type: Test
>Reporter: Vivek Narang
>
> I intend to work on an integration test suite for Solr, to test for issues to 
> deal with back compat, rolling upgrades etc.
> The interface for the test suite, as I'm planning, would be to have it accept 
> two versions of Solr (either released versions or trunk/branch).
> I work on SolrCloud, and we need something like this to enable us to upgrade 
> more frequently. I had a conversation with @Ishan Chattopadhyaya, who 
> emphasised to me the need to have something like this.
> If there's already any ongoing effort in doing this, I can help out there. 
> Please let me know.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-8581) Integration tests for rolling upgrades

[Walter Underwood (JIRA)]

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

Walter Underwood commented on SOLR-8581:


Leader election in a new/old two node cluster. Make sure it can go old->new and 
new->old.

>  Integration tests for rolling upgrades
> ---
>
> Key: SOLR-8581
> URL: https://issues.apache.org/jira/browse/SOLR-8581
> Project: Solr
>  Issue Type: Test
>Reporter: Vivek Narang
>
> I intend to work on an integration test suite for Solr, to test for issues to 
> deal with back compat, rolling upgrades etc.
> The interface for the test suite, as I'm planning, would be to have it accept 
> two versions of Solr (either released versions or trunk/branch).
> I work on SolrCloud, and we need something like this to enable us to upgrade 
> more frequently. I had a conversation with @Ishan Chattopadhyaya, who 
> emphasised to me the need to have something like this.
> If there's already any ongoing effort in doing this, I can help out there. 
> Please let me know.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7674) java.lang.IllegalStateException: Child query must not match same docs with parent filter. Combine them as must clauses (+) to find a problem doc. docId=2147483647, cla

[Tim Underwood (JIRA)]

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

Tim Underwood commented on LUCENE-7674:
---

Thanks [~mkhludnev]!  Running CheckJoinIndex on my bad index (assuming I got my 
parentsFilter right) says:

{code}
java.lang.IllegalStateException: Parent doc 3324040 of segment 
_vfo(6.3.0):C28035360/10475131:delGen=86 is deleted but has a live child 
document 3323449
{code}

Running CheckJoinIndex on the optimized version of the index doesn't complain.

So... that leaves me wondering where the bug is.  I am frequently (via Solr) 
re-indexing parent/child documents that duplicate existing documents based on 
my unique key field but my understanding is that Solr should automatically 
delete the old parent and child documents for me.  Maybe thats a bad assumption.

It looks like maybe I'm running into one or more of these issues: SOLR-5211, 
SOLR-5772, SOLR-6096, SOLR-6596, SOLR-6700

Sounds like I should probably just make sure I explicitly delete any old 
parent/child documents that I'm replacing to be on the safe side.

> java.lang.IllegalStateException: Child query must not match same docs with 
> parent filter. Combine them as must clauses (+) to find a problem doc. 
> docId=2147483647, class org.apache.lucene.search.ConjunctionScorer
> 
>
> Key: LUCENE-7674
> URL: https://issues.apache.org/jira/browse/LUCENE-7674
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.3
>Reporter: Tim Underwood
>
> Started seeing this error message on a production Solr 6.3.0 system today 
> making use of parent/child documents:
> {code}
> java.lang.IllegalStateException: Child query must not match same docs with 
> parent filter. Combine them as must clauses (+) to find a problem doc. 
> docId=2147483647, class org.apache.lucene.search.ConjunctionScorer
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.checkOrthogonal(ToParentBlockJoinQuery.java:403)
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.access$400(ToParentBlockJoinQuery.java:206)
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer$1.nextDoc(ToParentBlockJoinQuery.java:327)
> at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:219)
> at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:172)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:669)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:473)
> at 
> org.apache.solr.search.DocSetUtil.createDocSetGeneric(DocSetUtil.java:106)
> at org.apache.solr.search.DocSetUtil.createDocSet(DocSetUtil.java:95)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1379)
> at 
> org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:1057)
> at 
> org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1227)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListAndSetNC(SolrIndexSearcher.java:1842)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1616)
> at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:617)
> at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:531)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:153)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2213)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:303)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:254)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
> at 
> 

[jira] [Commented] (SOLR-8581) Integration tests for rolling upgrades

[Walter Underwood (JIRA)]

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

Walter Underwood commented on SOLR-8581:


How about a test that covers a rolling version upgrade replacing nodes.

1. Add new live node to cluster.
2. Add replica to new node.
3. Delete replica from old node.
4. Shut down old node.

Probably should run that with commands sent to an old node and a new node.

>  Integration tests for rolling upgrades
> ---
>
> Key: SOLR-8581
> URL: https://issues.apache.org/jira/browse/SOLR-8581
> Project: Solr
>  Issue Type: Test
>Reporter: Vivek Narang
>
> I intend to work on an integration test suite for Solr, to test for issues to 
> deal with back compat, rolling upgrades etc.
> The interface for the test suite, as I'm planning, would be to have it accept 
> two versions of Solr (either released versions or trunk/branch).
> I work on SolrCloud, and we need something like this to enable us to upgrade 
> more frequently. I had a conversation with @Ishan Chattopadhyaya, who 
> emphasised to me the need to have something like this.
> If there's already any ongoing effort in doing this, I can help out there. 
> Please let me know.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Assigned] (SOLR-9997) Enable configuring SolrHttpClientBuilder via java system property

[Mark Miller (JIRA)]

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

Mark Miller reassigned SOLR-9997:
-

Assignee: Mark Miller

> Enable configuring SolrHttpClientBuilder via java system property
> -
>
> Key: SOLR-9997
> URL: https://issues.apache.org/jira/browse/SOLR-9997
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.3
>Reporter: Hrishikesh Gadre
>Assignee: Mark Miller
>
> Currently SolrHttpClientBuilder needs to be configured via invoking 
> HttpClientUtil#setHttpClientBuilder(...) API. On the other hand SolrCLI 
> attempts to support configuring SolrHttpClientBuilder via Java system 
> property.  
> https://github.com/apache/lucene-solr/blob/9f58b6cd177f72b226c83adbb965cfe08d61d2fb/solr/core/src/java/org/apache/solr/util/SolrCLI.java#L265
> But after changes for SOLR-4509, this is no longer working. This is because 
> we need to configure HttpClientBuilderFactory which can provide appropriate 
> SolrHttpClientBuilder instance (e.g. Krb5HttpClientBuilder). I verified that 
> SolrCLI does not work in a kerberos enabled cluster. During the testing I 
> also found that SolrCLI is hardcoded to use basic authentication,
> https://github.com/apache/lucene-solr/blob/9f58b6cd177f72b226c83adbb965cfe08d61d2fb/solr/core/src/java/org/apache/solr/util/SolrCLI.java#L156
> This jira is to add support for configuring HttpClientBuilderFactory as a 
> java system property so that SolrCLI as well as other Solr clients can also 
> benefit this. Also we should provide a HttpClientBuilderFactory which support 
> configuring preemptive basic authentication so that we can remove the 
> hardcoded basic auth usage in SolrCLI (and enable it work with kerberos). 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10032) Create report to assess Solr test quality at a commit point.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-10032:


In other words: I am looking for tests that fail in a medium challenging but 
resource plentiful scenario first. Once we have a handle on those tests, there 
are steps we can take to improve hunting for deeper issues.

> Create report to assess Solr test quality at a commit point.
> 
>
> Key: SOLR-10032
> URL: https://issues.apache.org/jira/browse/SOLR-10032
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: Lucene-Solr Master Test Beast Results 
> 01-24-2017-9899cbd031dc3fc37a384b1f9e2b379e90a9a3a6 Level Medium- Running 30 
> iterations, 12 at a time .pdf, Lucene-Solr Master Test Beasults 
> 02-01-2017-bbc455de195c83d9f807980b510fa46018f33b1b Level Medium- Running 30 
> iterations, 10 at a time.pdf
>
>
> We have many Jenkins instances blasting tests, some official, some policeman, 
> I and others have or had their own, and the email trail proves the power of 
> the Jenkins cluster to find test fails.
> However, I still have a very hard time with some basic questions:
> what tests are flakey right now? which test fails actually affect devs most? 
> did I break it? was that test already flakey? is that test still flakey? what 
> are our worst tests right now? is that test getting better or worse?
> We really need a way to see exactly what tests are the problem, not because 
> of OS or environmental issues, but more basic test quality issues. Which 
> tests are flakey and how flakey are they at any point in time.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: [VOTE] Release Lucene/Solr 6.4.1 RC1

[Steve Rowe]

+1

Docs, changes (with one minor exception - see below) and javadocs look good, 
and the smoke tester is happy: SUCCESS! [0:39:49.329802]

One minor problem with both Changes.html files: there is no release date on the 
6.4.0 release section.  The 6.4.0 release section was never added to the DOAP 
files under dev-tools/doap/ on branch_6_4.  I’ll think about a way of 
automating a test to prevent this in the future.  In the meantime, I’ll add a 
reminder to sanity check the DOAP files before a release to the ReleaseToDo.

--
Steve
www.lucidworks.com

> On Feb 1, 2017, at 12:07 PM, Adrien Grand  wrote:
> 
> Please vote for release candidate 1 for Lucene/Solr 6.4.1.
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.4.1-RC1-rev72f75b2503fa0aa4f0aff76d439874feb923bb0e/
> 
> You can run the smoke tester directly with this command:
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.4.1-RC1-rev72f75b2503fa0aa4f0aff76d439874feb923bb0e/
> 
> Here's my +1 SUCCESS! [0:34:51.203607]


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

[jira] [Commented] (SOLR-7452) json facet api returning inconsistent counts in cloud set up

[Abhishek Umarjikar (JIRA)]

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

Abhishek Umarjikar commented on SOLR-7452:
--

Any progress on this..?

> json facet api returning inconsistent counts in cloud set up
> 
>
> Key: SOLR-7452
> URL: https://issues.apache.org/jira/browse/SOLR-7452
> Project: Solr
>  Issue Type: Bug
>  Components: Facet Module
>Affects Versions: 5.1
>Reporter: Vamsi Krishna D
>  Labels: count, facet, sort
> Attachments: SOLR-7452.patch
>
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> While using the newly added feature of json term facet api 
> (http://yonik.com/json-facet-api/#TermsFacet) I am encountering inconsistent 
> returns of counts of faceted value ( Note I am running on a cloud mode of 
> solr). For example consider that i have txns_id(unique field or key), 
> consumer_number and amount. Now for a 10 million such records , lets say i 
> query for 
> q=*:*=0&
>  json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
>   sort : {y:desc},
>   numBuckets : true,
>   facet:{
>y : "sum(amount)"
>}
>}
>  }
> the results are as follows ( some are omitted ):
> "facets":{
> "count":6641277,
> "biskatoo":{
>   "numBuckets":3112708,
>   "buckets":[{
>   "val":"surya",
>   "count":4,
>   "y":2.264506},
>   {
>   "val":"raghu",
>   "COUNT":3,   // capitalised for recognition 
>   "y":1.8},
> {
>   "val":"malli",
>   "count":4,
>   "y":1.78}]}}}
> but if i restrict the query to 
> q=consumer_number:raghu=0&
>  json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
>   sort : {y:desc},
>   numBuckets : true,
>   facet:{
>y : "sum(amount)"
>}
>}
>  }
> i get :
>   "facets":{
> "count":4,
> "biskatoo":{
>   "numBuckets":1,
>   "buckets":[{
>   "val":"raghu",
>   "COUNT":4,
>   "y":2429708.24}]}}}
> One can see the count results are inconsistent ( and I found many occasions 
> of inconsistencies).
> I have tried the patch https://issues.apache.org/jira/browse/SOLR-7412 but 
> still the issue seems not resolved



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10093) Possibility to change SOLR stop and RMI ports

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-10093:
---

Patches welcome! It might be worth waiting a bit to see if anyone else replies 
with any reasons that it was originally written this way, but I suspect it 
would be an uncontroversial change.

> Possibility to change SOLR stop and RMI ports
> -
>
> Key: SOLR-10093
> URL: https://issues.apache.org/jira/browse/SOLR-10093
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 6.4
>Reporter: Christian Brönnimann
>Priority: Minor
>  Labels: features, port, scripts
>
> My SOLR start port is 10443.
> I've found hard coded rules (-1000 and +1) for stop and RMI ports in file 
> /opt/solr/bin/solr.
> I've set the three variables in /etc/default/solr.in.sh for all 3 ports:
> SOLR_PORT="10443"
> STOP_PORT="10442"
> RMI_PORT="10444"
> SOLR has bound to these ports, but with this setting I could not stop SOLR 
> anymore.
> I had to edit the rules in /opt/solr/bin/solr by replacing 1000 and 1 by 
> the value 1.
> Could you please change the scripts, that the ports may be configured in 
> /etc/default/solr.in.sh ?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-8593) Integrate Apache Calcite into the SQLHandler

[Julian Hyde (JIRA)]

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

Julian Hyde commented on SOLR-8593:
---

This shouldn't be due to cost differences. The plan without the sort (limit) is 
incorrect, so should never be chosen, regardless of cost.

> Integrate Apache Calcite into the SQLHandler
> 
>
> Key: SOLR-8593
> URL: https://issues.apache.org/jira/browse/SOLR-8593
> Project: Solr
>  Issue Type: Improvement
>  Components: Parallel SQL
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-8593.patch, SOLR-8593.patch, SOLR-8593.patch
>
>
>The Presto SQL Parser was perfect for phase one of the SQLHandler. It was 
> nicely split off from the larger Presto project and it did everything that 
> was needed for the initial implementation.
> Phase two of the SQL work though will require an optimizer. Here is where 
> Apache Calcite comes into play. It has a battle tested cost based optimizer 
> and has been integrated into Apache Drill and Hive.
> This work can begin in trunk following the 6.0 release. The final query plans 
> will continue to be translated to Streaming API objects (TupleStreams), so 
> continued work on the JDBC driver should plug in nicely with the Calcite work.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-8593) Integrate Apache Calcite into the SQLHandler

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8593:
--

I was able to get the SolrSort to be pushed down with no ORDER BY, by changing 
the SolrSort.computeSelfCost to:

{code}
public RelOptCost computeSelfCost(RelOptPlanner planner, RelMetadataQuery mq) {
return planner.getCostFactory().makeZeroCost();
 }
{code}

It originally was:

{code}
 public RelOptCost computeSelfCost(RelOptPlanner planner, RelMetadataQuery mq) {
return super.computeSelfCost(planner, mq).multiplyBy(0.05);
  }
{code}

[~julianhyde], it appears that the planner was finding a lower cost option 
before the computeSelfCost was changed. Does it appear that this is a problem 
with how we were originally computing the cost? Or does this appear to be a bug 
in the planner. If it's a bug in the planner I'll log a ticket with the Calcite 
project.

In either case I think the problem with LIMIT being pushed down is solved for 
this ticket. So I will move on and continue testing in preparation to commit.

> Integrate Apache Calcite into the SQLHandler
> 
>
> Key: SOLR-8593
> URL: https://issues.apache.org/jira/browse/SOLR-8593
> Project: Solr
>  Issue Type: Improvement
>  Components: Parallel SQL
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-8593.patch, SOLR-8593.patch, SOLR-8593.patch
>
>
>The Presto SQL Parser was perfect for phase one of the SQLHandler. It was 
> nicely split off from the larger Presto project and it did everything that 
> was needed for the initial implementation.
> Phase two of the SQL work though will require an optimizer. Here is where 
> Apache Calcite comes into play. It has a battle tested cost based optimizer 
> and has been integrated into Apache Drill and Hive.
> This work can begin in trunk following the 6.0 release. The final query plans 
> will continue to be translated to Streaming API objects (TupleStreams), so 
> continued work on the JDBC driver should plug in nicely with the Calcite work.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-9217) {!join score=..}.. should delay join to createWeight

[Shashank Tyagi (JIRA)]

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

Shashank Tyagi edited comment on SOLR-9217 at 2/3/17 4:25 PM:
--

Is this fixed?Where is good place for starting this.


was (Author: shanky_ty):
Is this fixed?Where is good place tom start this.

> {!join score=..}.. should delay join to createWeight
> 
>
> Key: SOLR-9217
> URL: https://issues.apache.org/jira/browse/SOLR-9217
> Project: Solr
>  Issue Type: Improvement
>  Components: query parsers
>Affects Versions: 6.1
>Reporter: Mikhail Khludnev
>Priority: Minor
>  Labels: newbie, newdev
>
> {{ScoreJoinQParserPlugin.XxxCoreJoinQuery}} executes 
> {{JoinUtil.createJoinQuery}} on {{rewrite()}}, but it makes less effective in 
> {{filter(...)}} syntax. It's better to do that in {{createWeigh()}} as it's 
> done in classic Solr {{JoinQuery}}.
> All existing tests is enough, we just need to assert rewrite behavior - it 
> should rewrite on enclosing range query or so, and doesn't on plain term 
> query.  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-9217) {!join score=..}.. should delay join to createWeight

[Shashank Tyagi (JIRA)]

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

Shashank Tyagi edited comment on SOLR-9217 at 2/3/17 4:17 PM:
--

Is this fixed?Where is good place tom start this.


was (Author: shanky_ty):
Is this fixed?

> {!join score=..}.. should delay join to createWeight
> 
>
> Key: SOLR-9217
> URL: https://issues.apache.org/jira/browse/SOLR-9217
> Project: Solr
>  Issue Type: Improvement
>  Components: query parsers
>Affects Versions: 6.1
>Reporter: Mikhail Khludnev
>Priority: Minor
>  Labels: newbie, newdev
>
> {{ScoreJoinQParserPlugin.XxxCoreJoinQuery}} executes 
> {{JoinUtil.createJoinQuery}} on {{rewrite()}}, but it makes less effective in 
> {{filter(...)}} syntax. It's better to do that in {{createWeigh()}} as it's 
> done in classic Solr {{JoinQuery}}.
> All existing tests is enough, we just need to assert rewrite behavior - it 
> should rewrite on enclosing range query or so, and doesn't on plain term 
> query.  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9217) {!join score=..}.. should delay join to createWeight

[Shashank Tyagi (JIRA)]

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

Shashank Tyagi commented on SOLR-9217:
--

Is this fixed?

> {!join score=..}.. should delay join to createWeight
> 
>
> Key: SOLR-9217
> URL: https://issues.apache.org/jira/browse/SOLR-9217
> Project: Solr
>  Issue Type: Improvement
>  Components: query parsers
>Affects Versions: 6.1
>Reporter: Mikhail Khludnev
>Priority: Minor
>  Labels: newbie, newdev
>
> {{ScoreJoinQParserPlugin.XxxCoreJoinQuery}} executes 
> {{JoinUtil.createJoinQuery}} on {{rewrite()}}, but it makes less effective in 
> {{filter(...)}} syntax. It's better to do that in {{createWeigh()}} as it's 
> done in classic Solr {{JoinQuery}}.
> All existing tests is enough, we just need to assert rewrite behavior - it 
> should rewrite on enclosing range query or so, and doesn't on plain term 
> query.  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: [VOTE] Release Lucene/Solr 6.4.1 RC1

[Kevin Risden]

+1

SUCCESS! [1:08:03.938222]

Kevin Risden

On Fri, Feb 3, 2017 at 5:05 AM, Adrien Grand  wrote:

> Thank you for confirming Andrzej.
>
> Le ven. 3 févr. 2017 à 08:22, Andrzej Białecki <
> andrzej.biale...@lucidworks.com> a écrit :
>
>> On 2 Feb 2017, at 23:24, Adrien Grand  wrote:
>>
>> The current consensus seems to be to pursue the release process since the
>> failure appears to be a test bug. But I'm good with including this change
>> in case we had to do a respin.
>>
>>
>> SOLR-10090 indeed is a test bug, it’s triggered by a particular execution
>> order of test methods.
>>
>>
>> Le jeu. 2 févr. 2017 à 11:02, Christine Poerschke (BLOOMBERG/ LONDON) <
>> cpoersc...@bloomberg.net> a écrit :
>>
>> If there were to be a respin (and I understand that is an 'if' at this
>> point) then I'd like to propose for the small (unrelated)
>> https://issues.apache.org/jira/browse/SOLR-10083 fix to be included.
>>
>> Christine
>>
>> - Original Message -
>> From: dev@lucene.apache.org
>> To: dev@lucene.apache.org
>> At: 02/02/17 08:18:55
>>
>> It's the same failure. Don't know whether this should be a release
>> blocker qualified for respin; perhaps yes?
>>
>> Dawid
>>
>> On Wed, Feb 1, 2017 at 11:20 PM, Kevin Risden 
>> wrote:
>> > https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2780/
>> >
>> > Looks like the same failure is happening on Jenkins.
>> >
>> > Kevin Risden
>> >
>> > On Wed, Feb 1, 2017 at 4:27 PM, Dawid Weiss 
>> wrote:
>> >>
>> >> This test failed for me during the first smoketester run:
>> >>
>> >>[junit4] FAILURE 0.05s J1 | MBeansHandlerTest.testDiff <<<
>> >>[junit4]> Throwable #1: org.junit.ComparisonFailure:
>> >> expected: but was:> >> Delta: 1>
>> >>[junit4]>at
>> >> __randomizedtesting.SeedInfo.seed([8B5954CB0E2B8501:
>> 4E4F90501E9DBD61]:0)
>> >>[junit4]>at
>> >>
>> >> org.apache.solr.handler.admin.MBeansHandlerTest.testDiff(
>> MBeansHandlerTest.java:63)
>> >>
>> >> Repro line (didn't try): ant test  -Dtestcase=MBeansHandlerTest
>> >> -Dtests.method=testDiff -Dtest
>> >> s.seed=8B5954CB0E2B8501 -Dtests.locale=th -Dtests.timezone=US/Arizona
>> >> -Dtests.asserts=true -Dtests.file.enco
>> >> ding=UTF-8
>> >>
>> >> The second time it was ok, so could be something intermittent.
>> >>
>> >> SUCCESS! [0:58:03.206234]
>> >>
>> >> Dawid
>> >>
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> >> For additional commands, e-mail: dev-h...@lucene.apache.org
>> >>
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>>

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+153) - Build # 18897 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18897/
Java: 32bit/jdk-9-ea+153 -server -XX:+UseSerialGC

5 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.util.TestSolrCLIRunExample

Error Message:
ObjectTracker found 5 object(s) that were not released!!! 
[MockDirectoryWrapper, TransactionLog, MDCAwareThreadPoolExecutor, 
MockDirectoryWrapper, MockDirectoryWrapper] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:43)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at 
org.apache.solr.core.MetricsDirectoryFactory.get(MetricsDirectoryFactory.java:195)
  at 
org.apache.solr.core.SolrCore.initSnapshotMetaDataManager(SolrCore.java:479)  
at org.apache.solr.core.SolrCore.(SolrCore.java:902)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:825)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:928)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:864)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:88)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:378)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:388)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:174)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:171)
  at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:747)  
at 
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:728)  
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:509)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:347)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:298)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582) 
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)  
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:395)  
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) 
 at org.eclipse.jetty.server.Server.handle(Server.java:534)  at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)  at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)  at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)  at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) 
 at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
  at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
  at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) 
 at java.base/java.lang.Thread.run(Thread.java:844)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:43)
  at org.apache.solr.update.TransactionLog.(TransactionLog.java:188)  at 
org.apache.solr.update.UpdateLog.newTransactionLog(UpdateLog.java:442)  at 
org.apache.solr.update.UpdateLog.ensureLog(UpdateLog.java:1101)  at 
org.apache.solr.update.UpdateLog.add(UpdateLog.java:528)  at 
org.apache.solr.update.UpdateLog.add(UpdateLog.java:513)  at 
org.apache.solr.update.DirectUpdateHandler2.doNormalUpdate(DirectUpdateHandler2.java:299)
  at 
org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:213)
  at 
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:168)
  at 
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:67)
  at 

[jira] [Updated] (SOLR-7383) DIH rss example is broken again

[JIRA]

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

Jan Høydahl updated SOLR-7383:
--
Attachment: rss-data-config.xml

In the meantime I fixed the SlashDot paths (mainly replacing {{s/rss/RDF/g}}). 
Attached.

> DIH rss example is broken again
> ---
>
> Key: SOLR-7383
> URL: https://issues.apache.org/jira/browse/SOLR-7383
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 5.0, 6.0
>Reporter: Upayavira
>Assignee: Alexandre Rafalovitch
>Priority: Minor
> Attachments: rss-data-config.xml
>
>
> The DIH example (solr/example/example-DIH/solr/rss/conf/rss-data-config.xml) 
> is broken again. See associated issues.
> Below is a config that should work.
> This is caused by Slashdot seemingly oscillating between RDF/RSS and pure 
> RSS. Perhaps we should depend upon something more static, rather than an 
> external service that is free to change as it desires.
> 
> 
> 
>  pk="link"
> url="http://rss.slashdot.org/Slashdot/slashdot;
> processor="XPathEntityProcessor"
> forEach="/RDF/item"
> transformer="DateFormatTransformer">
>   
>  commonField="true" />
>  commonField="true" />
>  commonField="true" />
>   
> 
> 
> 
> 
> 
>  dateTimeFormat="-MM-dd'T'HH:mm:ss" />
> 
> 
> 
> 
> 
> 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-10032) Create report to assess Solr test quality at a commit point.

[Mark Miller (JIRA)]

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

Mark Miller edited comment on SOLR-10032 at 2/3/17 3:36 PM:


This report is not made to reproduce all fails.

Some tests will fail for a variety of reasons. Resources are too low, Java/OS 
version, which tests they happen to run against, etc, etc.

So this will not exhaustively produce all flakey tests, nor is it trying to. In 
fact, I've tried to make sure there are *plenty* of resources to the run the 
tests reasonably. My goal is to find flakey tests that pop out easily, and not 
due to very specific conditions. This should target and find obvious problems 
and then help clamp down on minor flakey tests in time. Jenkins and individual 
devs will still play an important role in outliers and other, hopefully much 
less common, fails.

That said, most things still end up popping out if you beast long enough in my 
experience. Beasting for 100 runs would probably surface even more flakey 
tests. Producing this test with 30 is already quite time expensive though ;) 
I'll eventually do some longer reports as we whittle down the obvious issues. 
It's really a judgment call of time vs coverage, and in these early reports 30 
seemed like a reasonable condition to pass.

The other tests are not all cleared, but here is a very reasonable list of 
tests we should focus on - that even in a good clean env appear to fail too 
much.

I will also focus 100 run or more beasting on the tests that this report 
surfaces as flakey, and likely some tests will enter and drop off the report 
from one to the next. Those tests will end up needing more extensive individual 
beasting to pass as 100% clean.

rock-solid is not really a definitive judgment, just the rating for no fails. 
If you did a single run and it passed it would be rock-solid. I can change that 
to something a little less confusing.

If you do have a specific test that seems to fail for you, I'm happy to beast 
it more extensively and let you know if fails pop out. I'll try ShardSplitTest. 
It may be that it has more severe resource problems when it ends up running 
against some other intensive tests in ant test.

It does give us some more info when looking at ShardSplitTest - we know it 
fails fairly often for you and Jenkins, but that in a clean, resource friendly 
env, it can pass for 30 runs, 10 run at a time. That gives some clues hardening 
that test.


was (Author: markrmil...@gmail.com):
This report is not made to reproduce all fails.

Some tests will fail for a variety of resources. Resources are too low, Java/OS 
version, which tests they happen to run against, etc, etc.

So this will not exhaustively produce all flakey tests, nor is it trying to. In 
fact, I've tried to make sure there are *plenty* of resources to the run the 
tests reasonably. My goal is to find flakey tests that pop out easily, and not 
due to very specific conditions. This should target and find obvious problems 
and then help clamp down on minor flakey tests in time. Jenkins and individual 
devs will still play an important role in outliers and other, hopefully much 
less common, fails.

That said, most things still end up popping out if you beast long enough in my 
experience. Beasting for 100 runs would probably surface even more flakey 
tests. Producing this test with 30 is already quite time expensive though ;) 
I'll eventually do some longer reports as we whittle down the obvious issues. 
It's really a judgment call of time vs coverage, and in these early reports 30 
seemed like a reasonable condition to pass.

The other tests are not all cleared, but here is a very reasonable list of 
tests we should focus on - that even in a good clean evn appear to fail too 
much.

I will also focus 100 run or more beasting on the tests that this report 
surfaces as flakey, and likely some tests will enter and drop off the report 
from one to the next. Those tests will end up needing more extensive individual 
beasting to pass as 100% clean.

rock-solid is not really a definitive judgment, just the rating for no fails. 
If you did a single run and it passed it would be rock-solid. I can change that 
to something a little less confusing.

If you do have a specific test that seems to fail for you, I'm happy to beast 
it more extensively and let you know if fails pop out. I'll try ShardSplitTest. 
It may be that it has more severe resource problems when it ends up running 
against some other intensive tests in ant test.

> Create report to assess Solr test quality at a commit point.
> 
>
> Key: SOLR-10032
> URL: https://issues.apache.org/jira/browse/SOLR-10032
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 

[jira] [Commented] (SOLR-10032) Create report to assess Solr test quality at a commit point.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-10032:


This report is not made to reproduce all fails.

Some tests will fail for a variety of resources. Resources are too low, Java/OS 
version, which tests they happen to run against, etc, etc.

So this will not exhaustively produce all flakey tests, nor is it trying to. In 
fact, I've tried to make sure there are *plenty* of resources to the run the 
tests reasonably. My goal is to find flakey tests that pop out easily, and not 
due to very specific conditions. This should target and find obvious problems 
and then help clamp down on minor flakey tests in time. Jenkins and individual 
devs will still play an important role in outliers and other, hopefully much 
less common, fails.

That said, most things still end up popping out if you beast long enough in my 
experience. Beasting for 100 runs would probably surface even more flakey 
tests. Producing this test with 30 is already quite time expensive though ;) 
I'll eventually do some longer reports as we whittle down the obvious issues. 
It's really a judgment call of time vs coverage, and in these early reports 30 
seemed like a reasonable condition to pass.

The other tests are not all cleared, but here is a very reasonable list of 
tests we should focus on - that even in a good clean evn appear to fail too 
much.

I will also focus 100 run or more beasting on the tests that this report 
surfaces as flakey, and likely some tests will enter and drop off the report 
from one to the next. Those tests will end up needing more extensive individual 
beasting to pass as 100% clean.

rock-solid is not really a definitive judgment, just the rating for no fails. 
If you did a single run and it passed it would be rock-solid. I can change that 
to something a little less confusing.

If you do have a specific test that seems to fail for you, I'm happy to beast 
it more extensively and let you know if fails pop out. I'll try ShardSplitTest. 
It may be that it has more severe resource problems when it ends up running 
against some other intensive tests in ant test.

> Create report to assess Solr test quality at a commit point.
> 
>
> Key: SOLR-10032
> URL: https://issues.apache.org/jira/browse/SOLR-10032
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: Lucene-Solr Master Test Beast Results 
> 01-24-2017-9899cbd031dc3fc37a384b1f9e2b379e90a9a3a6 Level Medium- Running 30 
> iterations, 12 at a time .pdf, Lucene-Solr Master Test Beasults 
> 02-01-2017-bbc455de195c83d9f807980b510fa46018f33b1b Level Medium- Running 30 
> iterations, 10 at a time.pdf
>
>
> We have many Jenkins instances blasting tests, some official, some policeman, 
> I and others have or had their own, and the email trail proves the power of 
> the Jenkins cluster to find test fails.
> However, I still have a very hard time with some basic questions:
> what tests are flakey right now? which test fails actually affect devs most? 
> did I break it? was that test already flakey? is that test still flakey? what 
> are our worst tests right now? is that test getting better or worse?
> We really need a way to see exactly what tests are the problem, not because 
> of OS or environmental issues, but more basic test quality issues. Which 
> tests are flakey and how flakey are they at any point in time.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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