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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2000/
Java: 32bit/jdk-9-ea+140 -server -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.solr.handler.component.SpellCheckComponentTest.testNumericQuery

Error Message:
List size mismatch @ spellcheck/suggestions

Stack Trace:
java.lang.RuntimeException: List size mismatch @ spellcheck/suggestions
at 
__randomizedtesting.SeedInfo.seed([BE676B5E04B31237:B54B3C9E9B7AAE98]:0)
at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:901)
at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:848)
at 
org.apache.solr.handler.component.SpellCheckComponentTest.testNumericQuery(SpellCheckComponentTest.java:154)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(java.base@9-ea/Thread.java:843)




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

[jira] [Commented] (SOLR-2087) Dismax handler not handling +/- correctly

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat commented on SOLR-2087:


Erick Erickson : That make sense :)

> Dismax handler not handling +/- correctly
> -
>
> Key: SOLR-2087
> URL: https://issues.apache.org/jira/browse/SOLR-2087
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Affects Versions: 1.4
>Reporter: Gabriel Weinberg
>
> If I do a query like: i'm a walking contradiction it matches pf as 
> text:"i'm_a a_walking walking contradiction"^2.0, and it matches fine.
> If I do a query like: i'm a +walking contradiction it matches pf as 
> text:"i'm_a a_+walking +walking contradiction"^2.0 and doesn't match at all.



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

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

[jira] [Updated] (SOLR-2094) When using a XPathEntityProcessor nested within a SQLEntityProcessor, the xpathReader isn't reinitilized for each new document

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat updated SOLR-2094:
---
Attachment: SOLR-2094.patch

In this patch, I solved the problem by resolve & cached variables when read 
rows (not resolve variables on the init of XPathRecordReader like before).

> When using a XPathEntityProcessor nested within a SQLEntityProcessor, the 
> xpathReader isn't reinitilized for each new document 
> ---
>
> Key: SOLR-2094
> URL: https://issues.apache.org/jira/browse/SOLR-2094
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 1.4.1
> Environment: Solr 1.4
>Reporter: Niall O'Connor
>Assignee: Alexandre Rafalovitch
> Attachments: SOLR-2094.patch
>
>
> I have a dih config with a SqlEntityProcessor that retrives a table. I then 
> have a sub-entity with the XPathEntityProcessor type, this takes a value from 
> the table as input to parse through an xml doc. 
> I find that the first document is created correctly, but then the xpathReader 
> of the XPathEntityProcessor does not reinitialize for the following documents 
> so the initial documents input is used. 
>   url="l"
>user="hivseqdb" password="hivseqdb" batchSize="1"/>
>
> 
> 
>query="SELECT * FROM hivseqdb.sequenceentry where se_id != '1'">
>   
>dataSource="xmlFile"
>   pk="fma-id"
>   forEach="/tissue-samples" 
>   processor="XPathEntityProcessor" 
>   
> url="/opt/hivseqdb/solr/conf/sub_ontology_translated.xml" 
>   stream="true">
>  xpath="/tissue-samples/tissue[@fma-id='${Sequence.sampleTissueCode}']/parent-path"/>
> 
> DocBuilder dose call init on the XPathEntityProcessor but there is a 
> conditional in the init method to check if the xpathReader is null:
>   public void init(Context context) {
> super.init(context);
> if (xpathReader == null)
>   initXpathReader();
> pk = context.getEntityAttribute("pk");
> dataSource = context.getDataSource();
> rowIterator = null;
>   }
> So the xPathReader is used again and again. Is there away to reinitialize the 
> xPathReader for every document? Or what is the specific design reason for 
> preserving it?
>   
>   



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

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

Re: [jira] [Commented] (SOLR-9399) Delete requests do not send credentials & fails for Basic Authentication

[Susheel Kumar]

Hi Jan, Alan,

I am having same issue, unable to make the delete/update/query tests fails
for basic authentication. Interestingly after setting up cluster,
collection and upload of security.json within the test and putting a
breakpoint, if i open the URL
"http://127.0.0.1:/solr/admin/authentication
thru browser / rest client it asks for credential but somehow the
HttpClient returns 200 even though with incorrect credential.

I thought HttpClient may be caching but it doesn't look like.  Here is the
updated pull request https://github.com/apache/lucene-solr/pull/69/files

Also the same code works if I point to my dev solr cluster/instance but
within test it doesn't.

HttpSolrClient.java

---

 final HttpResponse response = httpClient.execute(method,
httpClientRequestContext);

 int httpStatus = response.getStatusLine().getStatusCode();

On Thu, Oct 20, 2016 at 11:09 AM, Susheel Kumar (JIRA) 
wrote:

>
> [ https://issues.apache.org/jira/browse/SOLR-9399?page=
> com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel=15592078#comment-15592078 ]
>
> Susheel Kumar commented on SOLR-9399:
> -
>
> I recall something similar experience but let me again look after test has
> been refactored to make it fail first.
>
>
>
>
> > Delete requests do not send credentials & fails for Basic Authentication
> > 
> >
> > Key: SOLR-9399
> > URL: https://issues.apache.org/jira/browse/SOLR-9399
> > Project: Solr
> >  Issue Type: Bug
> >  Security Level: Public(Default Security Level. Issues are Public)
> >  Components: SolrJ
> >Affects Versions: 6.0, 6.0.1, 6.x
> >Reporter: Susheel Kumar
> >  Labels: security
> >
> > The getRoutes(..) func of UpdateRequest do not pass credentials to
> LBHttpSolrClient when deleteById is set while for updates it passes the
> credentials.  See below code snippet
> >   if (deleteById != null) {
> >
> >   Iterator>> entries =
> deleteById.entrySet()
> >   .iterator();
> >   while (entries.hasNext()) {
> >
> > Map.Entry> entry = entries.next();
> >
> > String deleteId = entry.getKey();
> > Map map = entry.getValue();
> > Long version = null;
> > if (map != null) {
> >   version = (Long) map.get(VER);
> > }
> > Slice slice = router.getTargetSlice(deleteId, null, null, null,
> col);
> > if (slice == null) {
> >   return null;
> > }
> > List urls = urlMap.get(slice.getName());
> > if (urls == null) {
> >   return null;
> > }
> > String leaderUrl = urls.get(0);
> > LBHttpSolrClient.Req request = routes.get(leaderUrl);
> > if (request != null) {
> >   UpdateRequest urequest = (UpdateRequest) request.getRequest();
> >   urequest.deleteById(deleteId, version);
> > } else {
> >   UpdateRequest urequest = new UpdateRequest();
> >   urequest.setParams(params);
> >   urequest.deleteById(deleteId, version);
> >   urequest.setCommitWithin(getCommitWithin());
> >   request = new LBHttpSolrClient.Req(urequest, urls);
> >   routes.put(leaderUrl, request);
> > }
> >   }
> > }
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 181 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/181/

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

Error Message:
Captured an uncaught exception in thread: Thread[id=26637, name=collection4, 
state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=26637, name=collection4, state=RUNNABLE, 
group=TGRP-CollectionsAPIDistributedZkTest]
Caused by: java.lang.RuntimeException: 
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: https://127.0.0.1:41100
at __randomizedtesting.SeedInfo.seed([DCAD7898587F04D9]:0)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:997)
Caused by: org.apache.solr.client.solrj.SolrServerException: Timeout occured 
while waiting response from server at: https://127.0.0.1:41100
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:604)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:251)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:435)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:387)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1292)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1062)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1004)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1599)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1620)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:987)
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:170)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
at sun.security.ssl.InputRecord.read(InputRecord.java:503)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:930)
at sun.security.ssl.AppInputStream.read(AppInputStream.java:105)
at 
org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:160)
at 
org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:84)
at 
org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:273)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
at 
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
at 
org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:283)
at 
org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:251)
at 
org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:197)
at 
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
at 
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
at 
org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:685)
at 
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:487)
at 
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:498)
... 11 more




Build Log:
[...truncated 12218 lines...]
   [junit4] Suite: org.apache.solr.cloud.CollectionsAPIDistributedZkTest
   [junit4]   2> Creating dataDir: 

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_102) - Build # 18101 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18101/
Java: 64bit/jdk1.8.0_102 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.solr.cloud.DeleteReplicaTest.deleteReplicaAndVerifyDirectoryCleanup

Error Message:
No registered leader was found after waiting for 4000ms , collection: 
deletereplica_test slice: shard1

Stack Trace:
org.apache.solr.common.SolrException: No registered leader was found after 
waiting for 4000ms , collection: deletereplica_test slice: shard1
at 
__randomizedtesting.SeedInfo.seed([6E99110C3B8EB057:1E7995B6BFC1195C]:0)
at 
org.apache.solr.common.cloud.ZkStateReader.getLeaderRetry(ZkStateReader.java:747)
at 
org.apache.solr.common.cloud.ZkStateReader.getLeaderRetry(ZkStateReader.java:733)
at 
org.apache.solr.cloud.DeleteReplicaTest.deleteReplicaAndVerifyDirectoryCleanup(DeleteReplicaTest.java:91)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:

[jira] [Commented] (SOLR-9510) child level facet exclusions

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-9510:


OK, here's the way I'm currently thinking about things (hopefully it will add 
further clarity rather than more confusion ;-)

First, let's leave aside "exclusions" and just look at domain changes in the 
JSON Facet API for the moment.

Example:
I find books I've reviewed highly (search for reviews and use block join to get 
to parent documents):
{code}
q={!parent which=type_s:book}user_s:yonik AND rating_i:5
{code}
Now I want to facet on *my* review dates.  Since the root domain consists of 
books, we'll need to map back to reviews (children):

{code}
json.facet={
  review_dates : {
type: range,
field: review_dt,
domain: { blockChild : "type_s:book" },
// additional params start, end, etc.
  }
}
{code}

Now there's a problem... when I map back to children, it maps to *all* of the 
children (reviews) for each book, when I really want just those reviews that 
originally mached user_s:yonik AND rating_i:5
I could perhaps hack it in with multiple levels of query facets (the first to 
switch the domain, and the second to filter again) but that seems really 
unfriendly.
What we really need is a way to specify additional filters for *any* facet.

Proposal:
{code}
json.facet={
  review_dates : {
type: range,
field: review_dt,
domain: { blockChild : "type_s:book" },
filter : [ "user_s:yonik AND rating_i:5" ],  // a list of filters... if 
there is a domain change, they will be applied *after*
// additional params start, end, etc.
  }
}
{code}

I started with this because we can't really exclude filters from child facets 
when we don't currently apply any at all!
I'll split my further thoughts into separate messages to try and keep things 
manageable.

> child level facet exclusions
> 
>
> Key: SOLR-9510
> URL: https://issues.apache.org/jira/browse/SOLR-9510
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module, faceting, query parsers
>Reporter: Mikhail Khludnev
>
> h2. Challenge
> * Since SOLR-5743 achieved block join child level facets with counts roll-up 
> to parents, there is a demand for filter exclusions. 
> h2. Context
> * Then, it's worth to consider JSON Facets as an engine for this 
> functionality rather than support a separate component. 
> * During a discussion in SOLR-8998 [a solution for block join with child 
> level 
> exclusion|https://issues.apache.org/jira/browse/SOLR-8998?focusedCommentId=15487095=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15487095]
>  has been found.  
>
> h2. Proposal
> It's proposed to provide a bit of syntax sugar to make it user friendly, 
> believe it or not.
> h2. List of improvements
> * introducing a local parameter {{filters}} for {{\{!parent}} query parser 
> referring to _multiple_ filters queries via parameter name: {{\{!parent 
> filters=$child.fq ..}..=color:Red=size:XL}} 
> these _filters_ are intersected with a child query supplied as a subordinate 
> clause.
> * introducing {{\{!filters params=$child.fq excludeTags=color 
> v=$subq}=text:word={!tag=color}color:Red=size:XL}} it 
> intersects a subordinate clause (here it's {{subq}} param, and the trick is 
> to refer to the same query from {{\{!parent}}}), with multiple filters 
> supplied via parameter name {{params=$child.fq}}, it also supports 
> {{excludeTags}}.
> h2. Notes
> Regarding the latter parser, the alternative approach might be to move into 
> {{domain:\{..}}} instruction of json facet. From the implementation 
> perspective, it's desired to optimize with bitset processing, however I 
> suppose it's might be deferred until some initial level of maturity. 
> h2. Example
> {code}
> q={!parent which=type_s:book filters=$child.fq 
> v=$childquery}=comment_t:good={!tag=author}author_s:yonik={!tag=stars}stars_i:(5
>  3)=json=on={
> comments_for_author:{
>   type:query,
>   q:"{!filters params=$child.fq excludeTags=author v=$childquery}",
>   "//note":"author filter is excluded",
>   domain:{
>  blockChildren:"type_s:book",
>  "//":"applying filters here might be more promising"
>}, facet:{
>authors:{
>   type:terms,
>   field:author_s,
>   facet: {
>   in_books: "unique(_root_)"
> }
> }
>}
> } ,
> comments_for_stars:{
>   type:query,
>  q:"{!filters params=$child.fq excludeTags=stars v=$childquery}",
>   "//note":"stars_i filter is excluded",
>   domain:{
>  blockChildren:"type_s:book"
>}, facet:{
>stars:{
>   type:terms,
>   field:stars_i,
>   facet: {
>   in_books: "unique(_root_)"
> }
> }
>   }
> }
> }
> {code} 
> 

[jira] [Updated] (SOLR-9676) FastVectorHighligher log message could be improved

[Mike (JIRA)]

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

Mike updated SOLR-9676:
---
Description: 
If you try to use the FastVectorHighlighter on a field that doesn't have 
TermPositions and TermOffsets enabled, you get an ok error message:

{{WARN  org.apache.solr.highlight.DefaultSolrHighlighter  – Solr will use 
Highlighter instead of FastVectorHighlighter because assignedTo field does not 
store TermPositions and TermOffsets.}}

If you heed that message, and dutifully add TermPositions and TermOffsets to 
your schema, you get a crashing message that says:

{code:txt}
Blah, blah, stacktrace

Caused by: java.lang.IllegalArgumentException: cannot index term vector offsets 
when term vectors are not indexed (field="court")
...
{code}

Can we update the first message to say:

{{Solr will use Highlighter instead of FastVectorHighlighter because assignedTo 
field does not store TermPositions, TermOffsets, and TermVectors.}}

That'd save at least one headache next time I screw this up...

  was:
If you try to use the FastVectorHighlighter on a field that doesn't have 
TermPositions and TermOffsets enabled, you get an ok error message:

{{WARN  org.apache.solr.highlight.DefaultSolrHighlighter  – Solr will use 
Highlighter instead of FastVectorHighlighter because assignedTo field does not 
store TermPositions and TermOffsets.}}

If you heed that message, and dutifully add TermPositions and TermOffsets to 
your schema, you get a crashing message that says:

{{
Blah, blah, stacktrace

Caused by: java.lang.IllegalArgumentException: cannot index term vector offsets 
when term vectors are not indexed (field="court")
...
}}

Can we update the first message to say:

{{Solr will use Highlighter instead of FastVectorHighlighter because assignedTo 
field does not store TermPositions, TermOffsets, and TermVectors.}}

That'd save at least one headache next time I screw this up...


> FastVectorHighligher log message could be improved
> --
>
> Key: SOLR-9676
> URL: https://issues.apache.org/jira/browse/SOLR-9676
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Affects Versions: 4.10.4
>Reporter: Mike
>Priority: Minor
>
> If you try to use the FastVectorHighlighter on a field that doesn't have 
> TermPositions and TermOffsets enabled, you get an ok error message:
> {{WARN  org.apache.solr.highlight.DefaultSolrHighlighter  – Solr will use 
> Highlighter instead of FastVectorHighlighter because assignedTo field does 
> not store TermPositions and TermOffsets.}}
> If you heed that message, and dutifully add TermPositions and TermOffsets to 
> your schema, you get a crashing message that says:
> {code:txt}
> Blah, blah, stacktrace
> 
> Caused by: java.lang.IllegalArgumentException: cannot index term vector 
> offsets when term vectors are not indexed (field="court")
> ...
> {code}
> Can we update the first message to say:
> {{Solr will use Highlighter instead of FastVectorHighlighter because 
> assignedTo field does not store TermPositions, TermOffsets, and TermVectors.}}
> That'd save at least one headache next time I screw this up...



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

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

[jira] [Updated] (SOLR-9676) FastVectorHighligher log message could be improved

[Mike (JIRA)]

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

Mike updated SOLR-9676:
---
Description: 
If you try to use the FastVectorHighlighter on a field that doesn't have 
TermPositions and TermOffsets enabled, you get an ok error message:

{{WARN  org.apache.solr.highlight.DefaultSolrHighlighter  – Solr will use 
Highlighter instead of FastVectorHighlighter because assignedTo field does not 
store TermPositions and TermOffsets.}}

If you heed that message, and dutifully add TermPositions and TermOffsets to 
your schema, you get a crashing message that says:

{code:none}
Blah, blah, stacktrace

Caused by: java.lang.IllegalArgumentException: cannot index term vector offsets 
when term vectors are not indexed (field="court")
...
{code}

Can we update the first message to say:

{{Solr will use Highlighter instead of FastVectorHighlighter because assignedTo 
field does not store TermPositions, TermOffsets, and TermVectors.}}

That'd save at least one headache next time I screw this up...

  was:
If you try to use the FastVectorHighlighter on a field that doesn't have 
TermPositions and TermOffsets enabled, you get an ok error message:

{{WARN  org.apache.solr.highlight.DefaultSolrHighlighter  – Solr will use 
Highlighter instead of FastVectorHighlighter because assignedTo field does not 
store TermPositions and TermOffsets.}}

If you heed that message, and dutifully add TermPositions and TermOffsets to 
your schema, you get a crashing message that says:

{code:txt}
Blah, blah, stacktrace

Caused by: java.lang.IllegalArgumentException: cannot index term vector offsets 
when term vectors are not indexed (field="court")
...
{code}

Can we update the first message to say:

{{Solr will use Highlighter instead of FastVectorHighlighter because assignedTo 
field does not store TermPositions, TermOffsets, and TermVectors.}}

That'd save at least one headache next time I screw this up...


> FastVectorHighligher log message could be improved
> --
>
> Key: SOLR-9676
> URL: https://issues.apache.org/jira/browse/SOLR-9676
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Affects Versions: 4.10.4
>Reporter: Mike
>Priority: Minor
>
> If you try to use the FastVectorHighlighter on a field that doesn't have 
> TermPositions and TermOffsets enabled, you get an ok error message:
> {{WARN  org.apache.solr.highlight.DefaultSolrHighlighter  – Solr will use 
> Highlighter instead of FastVectorHighlighter because assignedTo field does 
> not store TermPositions and TermOffsets.}}
> If you heed that message, and dutifully add TermPositions and TermOffsets to 
> your schema, you get a crashing message that says:
> {code:none}
> Blah, blah, stacktrace
> 
> Caused by: java.lang.IllegalArgumentException: cannot index term vector 
> offsets when term vectors are not indexed (field="court")
> ...
> {code}
> Can we update the first message to say:
> {{Solr will use Highlighter instead of FastVectorHighlighter because 
> assignedTo field does not store TermPositions, TermOffsets, and TermVectors.}}
> That'd save at least one headache next time I screw this up...



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

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

[jira] [Updated] (SOLR-9676) FastVectorHighligher log message could be improved

[Mike (JIRA)]

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

Mike updated SOLR-9676:
---
Description: 
If you try to use the FastVectorHighlighter on a field that doesn't have 
TermPositions and TermOffsets enabled, you get an ok error message:

{{WARN  org.apache.solr.highlight.DefaultSolrHighlighter  – Solr will use 
Highlighter instead of FastVectorHighlighter because assignedTo field does not 
store TermPositions and TermOffsets.}}

If you heed that message, and dutifully add TermPositions and TermOffsets to 
your schema, you get a crashing message that says:

{{
Blah, blah, stacktrace

Caused by: java.lang.IllegalArgumentException: cannot index term vector offsets 
when term vectors are not indexed (field="court")
...
}}

Can we update the first message to say:

{{Solr will use Highlighter instead of FastVectorHighlighter because assignedTo 
field does not store TermPositions, TermOffsets, and TermVectors.}}

That'd save at least one headache next time I screw this up...

  was:
If you try to use the FastVectorHighlighter on a field that doesn't have 
TermPositions and TermOffsets enabled, you get an ok error message:

{{WARN  org.apache.solr.highlight.DefaultSolrHighlighter  – Solr will use 
Highlighter instead of FastVectorHighlighter because assignedTo field does not 
store TermPositions and TermOffsets.}}

If you heed that message, and dutifully add TermPositions and TermOffsets to 
your schema, you get a crashing message that says:

{{Blah, blah, stacktrace

Caused by: java.lang.IllegalArgumentException: cannot index term vector offsets 
when term vectors are not indexed (field="court")
...}}

Can we update the first message to say:

{{Solr will use Highlighter instead of FastVectorHighlighter because assignedTo 
field does not store TermPositions, TermOffsets, and TermVectors.}}

That'd save at least one headache next time I screw this up...


> FastVectorHighligher log message could be improved
> --
>
> Key: SOLR-9676
> URL: https://issues.apache.org/jira/browse/SOLR-9676
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Affects Versions: 4.10.4
>Reporter: Mike
>Priority: Minor
>
> If you try to use the FastVectorHighlighter on a field that doesn't have 
> TermPositions and TermOffsets enabled, you get an ok error message:
> {{WARN  org.apache.solr.highlight.DefaultSolrHighlighter  – Solr will use 
> Highlighter instead of FastVectorHighlighter because assignedTo field does 
> not store TermPositions and TermOffsets.}}
> If you heed that message, and dutifully add TermPositions and TermOffsets to 
> your schema, you get a crashing message that says:
> {{
> Blah, blah, stacktrace
> 
> Caused by: java.lang.IllegalArgumentException: cannot index term vector 
> offsets when term vectors are not indexed (field="court")
> ...
> }}
> Can we update the first message to say:
> {{Solr will use Highlighter instead of FastVectorHighlighter because 
> assignedTo field does not store TermPositions, TermOffsets, and TermVectors.}}
> That'd save at least one headache next time I screw this up...



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

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

[jira] [Created] (SOLR-9676) FastVectorHighligher log message could be improved

[Mike (JIRA)]

Mike created SOLR-9676:
--

 Summary: FastVectorHighligher log message could be improved
 Key: SOLR-9676
 URL: https://issues.apache.org/jira/browse/SOLR-9676
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: highlighter
Affects Versions: 4.10.4
Reporter: Mike
Priority: Minor


If you try to use the FastVectorHighlighter on a field that doesn't have 
TermPositions and TermOffsets enabled, you get an ok error message:

{{WARN  org.apache.solr.highlight.DefaultSolrHighlighter  – Solr will use 
Highlighter instead of FastVectorHighlighter because assignedTo field does not 
store TermPositions and TermOffsets.}}

If you heed that message, and dutifully add TermPositions and TermOffsets to 
your schema, you get a crashing message that says:

{{Blah, blah, stacktrace

Caused by: java.lang.IllegalArgumentException: cannot index term vector offsets 
when term vectors are not indexed (field="court")
...}}

Can we update the first message to say:

{{Solr will use Highlighter instead of FastVectorHighlighter because assignedTo 
field does not store TermPositions, TermOffsets, and TermVectors.}}

That'd save at least one headache next time I screw this up...



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

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

[jira] [Commented] (SOLR-9666) Extract dynamic fields in LukeResponse

[Fengtan (JIRA)]

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

Fengtan commented on SOLR-9666:
---

Sounds good, thanks [~risdenk].
[SchemaRequest|https://lucene.apache.org/solr/6_2_1/solr-solrj/org/apache/solr/client/solrj/request/schema/SchemaRequest.html]
 is marked as experimental but I guess the existing API will not change much.

> Extract dynamic fields in LukeResponse
> --
>
> Key: SOLR-9666
> URL: https://issues.apache.org/jira/browse/SOLR-9666
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 6.2.1
>Reporter: Fengtan
>Priority: Minor
> Attachments: SOLR-9666.patch
>
>
> LukeRequestHandler (/admin/luke), when invoked with the show=schema 
> parameter, returns a list static fields and dynamic fields.
> For instance on my local machine 
> http://localhost:8983/solr/collection1/admin/luke?show=schema returns 
> something like this:
> {code:xml}
> 
>   ...
>   
> 
>   
> string
> I-S-OF-l
>   
>   ...
> 
> 
>   
> string
> I---OF--
>   
>   ...
> 
>   
>   ...
> 
> {code}
> However, when processing a LukeRequest in SolrJ, only static fields are 
> parsed and made available to the client application through 
> lukeResponse.getFieldInfo(). There does not seem to be a way for the client 
> application to get the dynamic fields.
> Maybe we could parse dynamic fields and make them accessible ? Possibly 
> something like this:
> {code}
> public class MyClass {
>   public static void main(String[] args) throws Exception {
> SolrClient client = new 
> HttpSolrClient("http://localhost:8983/solr/collection1;);
> LukeRequest request = new LukeRequest();
> request.setShowSchema(true);
> LukeResponse response = request.process(client);
> Map staticFields = response.getFieldInfo(); // SolrJ 
> already provides this.
> Map dynamicFields = response.getDynamicFieldInfo(); // 
> Proposed improvement.
>   }
> }
> {code}



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

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

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 3617 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3617/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication

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

Stack Trace:
java.lang.AssertionError: expected:<1> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([DBF6D87FFD10FC77:2C8536273BF85391]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1329)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




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

Re: [DISCUSS] JIRA maintenance and response times

[Alexandre Rafalovitch]

Progress update,

I had pinged Mike McCandless and he - very kindly - implemented some
new facets for the Jirasearch that - I think - would help for this
discussion. The full list of changes is at
http://blog.mikemccandless.com/2016/10/jiraseseach-20-dog-food-using-lucene-to.html

The summary relevant right now is that we can now ALSO filter issues
by the last person who updated it as well as the time that passed
since that last update. And - that was his idea - who actually
committed within that issue. None of these were possible with Jira JQL
queries, however smart.

Which means I can run the queries such as:
http://jirasearch.mikemccandless.com/search.py?chg=dds==updatedOld=%3E+1+week+ago=0=938=recentlyUpdated=list=r3zft095hlwr=project%3ASolr=status%3AOpen%2CReopened=lastContributor%3AAlexandre+Rafalovitch=

(Opened/Reopened Solr issues in which the last comment was mine and
it's been longer than a week) - which means follow-up time.

Or
http://jirasearch.mikemccandless.com/search.py?chg=dds==hasCommits=0=0=938=recentlyUpdated=list=qkprrewu1d2r=project%3ASolr=status%3AOpen%2CReopened=allUsers%3AAlexandre+Rafalovitch=updatedOld%3A%3E+3+months+ago=

(Discussions I participated in that has gone dark without outcome
(commit) for more than 3 months.)

I think that's a great step forward both for interactive exploration
as well as for this specific discussion on whether something like that
should be an automatic report for individuals. Because, as part of the
upgrade, Mike also open-sourced the tools to download JIRAs into a
form where we could run the tools, summary reports,visualizations,
etc.

Nothing is stopping us now but the consensus on what exactly the next
step should be (the hard part, I know).

Regards,
   Alex.

Solr Example reading group is starting November 2016, join us at
http://j.mp/SolrERG



On 5 October 2016 at 16:53, Jeff Wartes  wrote:
> I was thinking about this some more last night, and since I’m in software, 
> here’s the software I think I’d want:
>
> Create a list of Alerts, each of which know how to do two things: 1) 
> Determine whether a given jira issue matches the alert 2) Determine an 
> Alertee for a matching issue.
> One of Alexandre’s examples in this context: 1) If the issue hasn’t had an 
> update in a week, and the last update was by a committer, it’s a match. 2) 
> The committer with the last comment is the Alertee.
> Another example: 1) If the issue has a patch file or a github pull request 
> comment, but isn’t assigned to anyone, it’s a match. 2) This dev mailing list 
> is the Alertee
>
> Every week, iterate through all unresolved issues, and give every Alert 
> definition the chance to gather the list of matching tickets.
> Then:
> 1. Dump each Alert’s list of issues on a web page someplace. Include diffs vs 
> the last run, so you can see if a given Alert’s list is growing over time.
> 2. Get the distinct list of Alertee for all issues that matched any Alerts, 
> and send each Alertee one email with the list of issues mapped to that 
> Alertee, grouped by Alert type.
>
> So you give periodic reminders to exactly the people who should get them, and 
> you also have a place you can see this week’s status for everything. For 
> bonus points, people could squelch getting the email if it only contained 
> issues derived from certain Alerts.
>
>
> On 10/5/16, 10:42 AM, "Alexandre Rafalovitch"  wrote:
>
>  I believe the first 3 dashboards can be done in JIRA itself. I have
> something similar, but unfortunately cannot share the dashboard (no
> permission it seems).
>
> The last one (breakdown of creation date? by year) is something that
> JIRA does not seem to be able to give.
>
> In terms of pulling data, I was able to build an API to pull up to 200
> issues from JIRA at a time with full case information in the - as
> Cassandra discovered - rather convoluted XML. So, it would not be too
> hard to run several APIs and merge the results to get full export. And
> then maybe run daily/weekly export and merge/override. Then, it is
> pre-process and distribute.
>
> It is totally doable. We just need to firm up the business
> requirements. What kind of reports people feel would be useful for
> _them_ to be more proactive. I've listed my ideas earlier, but not
> sure if they would be useful to others.
>
> Regards,
>Alex.
> P.s. Do we need a JIRA for this?
> 
> Newsletter and resources for Solr beginners and intermediates:
> http://www.solr-start.com/
>
>
> On 6 October 2016 at 00:06, Cassandra Targett  
> wrote:
> > In terms of a report, I found a template that uses JIRA's API to
> > import issues to a Google Sheet:
> > 
> http://www.littlebluemonkey.com/blog/automatically-import-jira-backlog-into-google-spreadsheet
> >
> > I made some modifications to the original and have shared it for
> 

[jira] [Commented] (SOLR-9672) When using a mutilvalued field(fieldname) in fl an error appears

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-9672:
-

This would have been better asked on the User Mailing list. Because, as far as 
I can tell, you have multivalued docvalues and the field documentation says for 
those cases:
{noformat}
In it's simplest (single argument) form, this function can only be used on 
single valued fields. For multivalued docValues fields: 
field(myMultiValuedFloatField,min)
{noformat}

But that's for numerics. I am not sure whether docValues support for 
multiValued strings would work here. But on mailing list, more people would see 
your question.

> When using a mutilvalued field(fieldname) in fl an error appears
> 
>
> Key: SOLR-9672
> URL: https://issues.apache.org/jira/browse/SOLR-9672
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5, 6.2.1
> Environment: Using Docker Hubs Solr:6.2 
>Reporter: Matthew Wilcoxson
>Priority: Minor
>
> When using a schema.xml with a field marked as multiValued, e.g.:
>  multiValued="true"  />
> this error occurs:
> "an not use FieldCache on multivalued field: frbr_Image-image",
> when the field is requested in the fl parameter and wrapped in the field() 
> syntax, i.e.:
> fl=field(frbr_Image-image)
> Full url:   
> http://localhost:8983/solr/manifestations_stage/select?fl=field(frbr_Image-image)=*:*
> When you remove the field() syntax the error doesn't occur and the correct 
> values are returned. This occurs even if the fieldname doesn't need to be 
> wrapped.
> I'm mostly using the default solrconfig.xml file (with a few lines taken out)



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

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

Re: Test framework security manager

[Joel Bernstein]

Ok, this makes sense. I'll check to see if SolrCoreTest is doing this, and
I'm somehow getting the wrong instance dir.

Thanks!

Joel Bernstein
http://joelsolr.blogspot.com/

On Thu, Oct 20, 2016 at 4:40 PM, Uwe Schindler  wrote:

> Hi,
>
> On test startup you clone the instance dir. Most tests do this.
>
> Uwe
>
>
> Am 20. Oktober 2016 22:29:32 MESZ schrieb Joel Bernstein <
> joels...@gmail.com>:
>>
>> I'm working on a test case for SOLR-9533, which requires writing and
>> reloading the solrcore.properties file in the instance dir of the test
>> framework. The test was being added to SolrCoreTest.java.
>>
>> I'm getting the following error when writing the file:
>>
>> java.security.AccessControlException: access denied
>> ("java.io.FilePermission"
>>
>> It makes sense to forbid writing to this directory but for this test case
>> it seems to be required.
>>
>> Wondering if anyone has any suggestions for how to deal with this?
>>
>> Joel Bernstein
>> http://joelsolr.blogspot.com/
>>
>
> --
> Uwe Schindler
> H.-H.-Meier-Allee 63, 28213 Bremen
> http://www.thetaphi.de
>

Re: Test framework security manager

[Uwe Schindler]

Hi,

On test startup you clone the instance dir. Most tests do this.

Uwe

Am 20. Oktober 2016 22:29:32 MESZ schrieb Joel Bernstein :
>I'm working on a test case for SOLR-9533, which requires writing and
>reloading the solrcore.properties file in the instance dir of the test
>framework. The test was being added to SolrCoreTest.java.
>
>I'm getting the following error when writing the file:
>
>java.security.AccessControlException: access denied
>("java.io.FilePermission"
>
>It makes sense to forbid writing to this directory but for this test
>case
>it seems to be required.
>
>Wondering if anyone has any suggestions for how to deal with this?
>
>Joel Bernstein
>http://joelsolr.blogspot.com/

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

Test framework security manager

[Joel Bernstein]

I'm working on a test case for SOLR-9533, which requires writing and
reloading the solrcore.properties file in the instance dir of the test
framework. The test was being added to SolrCoreTest.java.

I'm getting the following error when writing the file:

java.security.AccessControlException: access denied
("java.io.FilePermission"

It makes sense to forbid writing to this directory but for this test case
it seems to be required.

Wondering if anyone has any suggestions for how to deal with this?

Joel Bernstein
http://joelsolr.blogspot.com/

[jira] [Created] (SOLR-9675) Sorting on field in JSON Facet API which is not part of JSON Facet.

[AMRIT SARKAR (JIRA)]

AMRIT SARKAR created SOLR-9675:
--

 Summary: Sorting on field in JSON Facet API which is not part of 
JSON Facet.
 Key: SOLR-9675
 URL: https://issues.apache.org/jira/browse/SOLR-9675
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: AMRIT SARKAR
Priority: Minor


Here's a sample example:

There is a requirement to facet on a particular field but sort on another field 
which is not part of json facet.

For example, consider schema with fields : sl1, sl2, product_bkgs, gc_2

Solr query & facet : q=sl1:("abc") AND sl2:("xyz")=sl1 desc=0

& json.facet={

"group_column_level" :

{

"type" : "terms",

"field" : "gc_2",

"offset" : 0,

"limit" :25,

"sort" : { "product_bkgs" : "desc"},

"facet" :

{

"product_bkgs" :"sum(product_bkgs)"

}

}

}

Sort on product_bkgs is possible but not on sl1 in the facet.

Let me know if anything can be done to achieve the same.

Thanks in advance.



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

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

[jira] [Closed] (SOLR-153) Facet Index

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch closed SOLR-153.
--
Resolution: Implemented

> Facet Index
> ---
>
> Key: SOLR-153
> URL: https://issues.apache.org/jira/browse/SOLR-153
> Project: Solr
>  Issue Type: New Feature
>Reporter: Yonik Seeley
> Attachments: facettree.patch, facettree.patch
>
>
> A facet index, initially for non-hierarchical facets.
> Start with all terms, and a set of documents for each term.  Group lower 
> level nodes by taking the union of the sets, but keep track of the largest 
> set going back all the way to the leaves (the max doc-freq for that node).



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

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

[JENKINS] Lucene-Solr-6.x-Windows (32bit/jdk1.8.0_102) - Build # 529 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/529/
Java: 32bit/jdk1.8.0_102 -server -XX:+UseSerialGC

7 tests failed.
FAILED:  org.apache.solr.util.UtilsToolTest.testNonexisting

Error Message:
Logs directory must be an absolute path, or -s must be supplied

Stack Trace:
java.lang.Exception: Logs directory must be an absolute path, or -s must be 
supplied
at 
org.apache.solr.util.SolrCLI$UtilsTool.prepareLogsPath(SolrCLI.java:3577)
at 
org.apache.solr.util.SolrCLI$UtilsTool.removeOldSolrLogs(SolrCLI.java:3544)
at org.apache.solr.util.SolrCLI$UtilsTool.runTool(SolrCLI.java:3422)
at org.apache.solr.util.UtilsToolTest.runTool(UtilsToolTest.java:183)
at 
org.apache.solr.util.UtilsToolTest.testNonexisting(UtilsToolTest.java:98)
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 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:243)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:354)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:10)


FAILED:  org.apache.solr.util.UtilsToolTest.testRelativePath

Error Message:
Logs directory must be an absolute path, or -s must be supplied

Stack Trace:
java.lang.Exception: Logs directory must be an absolute path, or -s must be 
supplied
at 
org.apache.solr.util.SolrCLI$UtilsTool.prepareLogsPath(SolrCLI.java:3577)
at 
org.apache.solr.util.SolrCLI$UtilsTool.removeOldSolrLogs(SolrCLI.java:3544)
at org.apache.solr.util.SolrCLI$UtilsTool.runTool(SolrCLI.java:3422)
at org.apache.solr.util.UtilsToolTest.runTool(UtilsToolTest.java:183)
at 
org.apache.solr.util.UtilsToolTest.testRelativePath(UtilsToolTest.java:119)
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 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:243)
at 

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1997/
Java: 32bit/jdk-9-ea+140 -server -XX:+UseParallelGC

8 tests failed.
FAILED:  org.apache.solr.cloud.ShardSplitTest.testSplitAfterFailedSplit

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

Stack Trace:
java.lang.AssertionError: expected:<1> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([E571810644908A22:1C3C12A978E5C7A8]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.ShardSplitTest.testSplitAfterFailedSplit(ShardSplitTest.java:279)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[JENKINS] Lucene-Solr-Tests-6.x - Build # 492 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.x/492/

7 tests failed.
FAILED:  org.apache.solr.util.UtilsToolTest.testEmptyAndQuiet

Error Message:
Logs directory must be an absolute path, or -s must be supplied

Stack Trace:
java.lang.Exception: Logs directory must be an absolute path, or -s must be 
supplied
at 
org.apache.solr.util.SolrCLI$UtilsTool.prepareLogsPath(SolrCLI.java:3577)
at 
org.apache.solr.util.SolrCLI$UtilsTool.removeOldSolrLogs(SolrCLI.java:3544)
at org.apache.solr.util.SolrCLI$UtilsTool.runTool(SolrCLI.java:3422)
at org.apache.solr.util.UtilsToolTest.runTool(UtilsToolTest.java:183)
at 
org.apache.solr.util.UtilsToolTest.testEmptyAndQuiet(UtilsToolTest.java:87)
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 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:243)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:354)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:10)


FAILED:  org.apache.solr.util.UtilsToolTest.testNonexisting

Error Message:
Logs directory must be an absolute path, or -s must be supplied

Stack Trace:
java.lang.Exception: Logs directory must be an absolute path, or -s must be 
supplied
at 
org.apache.solr.util.SolrCLI$UtilsTool.prepareLogsPath(SolrCLI.java:3577)
at 
org.apache.solr.util.SolrCLI$UtilsTool.removeOldSolrLogs(SolrCLI.java:3544)
at org.apache.solr.util.SolrCLI$UtilsTool.runTool(SolrCLI.java:3422)
at org.apache.solr.util.UtilsToolTest.runTool(UtilsToolTest.java:183)
at 
org.apache.solr.util.UtilsToolTest.testNonexisting(UtilsToolTest.java:98)
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 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:243)
at 

[jira] [Updated] (SOLR-9077) Streaming expressions should support collection alias

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-9077:
---
Summary: Streaming expressions should support collection alias  (was: 
Streaming expression in solr doesnot support collection alias)

> Streaming expressions should support collection alias
> -
>
> Key: SOLR-9077
> URL: https://issues.apache.org/jira/browse/SOLR-9077
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.5.1
>Reporter: Suds
>Priority: Minor
>
> Streaming expression in solr does not support collection alias
> when I tried to access collection alias I get null pointer exception 
> issue seems to be related to following code , clusterState.getActiveSlices 
> returns null 
>  Collection slices = clusterState.getActiveSlices(this.collection);
>  for(Slice slice : slices) {
> }
> fix seems to fairly simple , clusterState.getActiveSlices can be made aware 
> of collection alias. I am not sure what will happen when we have large alias 
> which has hundred of slices.



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

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

[jira] [Commented] (SOLR-8029) Modernize and standardize Solr APIs

[ASF subversion and git services (JIRA)]

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

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

Commit c482b339e7813e3b39593bda7c498ecefc547e05 in lucene-solr's branch 
refs/heads/apiv2 from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c482b33 ]

SOLR-8029: Added more details to config API


> Modernize and standardize Solr APIs
> ---
>
> Key: SOLR-8029
> URL: https://issues.apache.org/jira/browse/SOLR-8029
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.0
>Reporter: Noble Paul
>Assignee: Noble Paul
>  Labels: API, EaseOfUse
> Fix For: 6.0
>
> Attachments: SOLR-8029.patch, SOLR-8029.patch, SOLR-8029.patch, 
> SOLR-8029.patch
>
>
> Solr APIs have organically evolved and they are sometimes inconsistent with 
> each other or not in sync with the widely followed conventions of HTTP 
> protocol. Trying to make incremental changes to make them modern is like 
> applying band-aid. So, we have done a complete rethink of what the APIs 
> should be. The most notable aspects of the API are as follows:
> The new set of APIs will be placed under a new path {{/solr2}}. The legacy 
> APIs will continue to work under the {{/solr}} path as they used to and they 
> will be eventually deprecated.
> There are 4 types of requests in the new API 
> * {{/v2//*}} : Hit a collection directly or manage 
> collections/shards/replicas 
> * {{/v2//*}} : Hit a core directly or manage cores 
> * {{/v2/cluster/*}} : Operations on cluster not pertaining to any collection 
> or core. e.g: security, overseer ops etc
> This will be released as part of a major release. Check the link given below 
> for the full specification.  Your comments are welcome
> [Solr API version 2 Specification | http://bit.ly/1JYsBMQ]



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

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

[jira] [Commented] (SOLR-9570) Logs backed up on restart are kept forever

[ASF subversion and git services (JIRA)]

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

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

Commit 1b626fa0ca0152a024cd68fbf17e042469e6e3a2 in lucene-solr's branch 
refs/heads/branch_6x from [~janhoy]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1b626fa ]

SOLR-9570: Fix test failures and start using SolrTestCaseJ4's createTempDir mm

(cherry picked from commit af88e7f)


> Logs backed up on restart are kept forever
> --
>
> Key: SOLR-9570
> URL: https://issues.apache.org/jira/browse/SOLR-9570
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>  Labels: logging
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-8370.patch
>
>
> When (re)starting Solr, the start script will backup any existing 
> {{solr.log}} or {{solr_gc.log}} to a file {{solr_log_}} and 
> {{solr_gc_log_}} respectively. That may be all good, but these old 
> copies are never cleaned up, as they are not under the control of log4j.
> This issue will instead rotate solr.log properly on startup, delete old 
> time-stamped files taking up place, back up (one generation only) of 
> console-log and solr_gc.log in $SOLR_LOGS_DIR/archived/.



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

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

[jira] [Comment Edited] (SOLR-9570) Logs backed up on restart are kept forever

[JIRA]

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

Jan Høydahl edited comment on SOLR-9570 at 10/20/16 7:02 PM:
-

Sorry, commit log had wrong issue-number.

Committed master (97761966f30557c33b3bbb131ce64ea7905ae213)
https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=commit;h=97761966f30557c33b3bbb131ce64ea7905ae213

Branch_6x (ed3b268d62f23e212c410cb35aa4318afa088f55)
https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=commit;h=ed3b268d62f23e212c410cb35aa4318afa088f55


was (Author: janhoy):
Sorry, commit log had wrong issue-number.

Committed master (ed3b268d62f23e212c410cb35aa4318afa088f55)
https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=commit;h=97761966f30557c33b3bbb131ce64ea7905ae213

Branch_6x (ed3b268d62f23e212c410cb35aa4318afa088f55)
https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=commit;h=ed3b268d62f23e212c410cb35aa4318afa088f55

> Logs backed up on restart are kept forever
> --
>
> Key: SOLR-9570
> URL: https://issues.apache.org/jira/browse/SOLR-9570
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>  Labels: logging
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-8370.patch
>
>
> When (re)starting Solr, the start script will backup any existing 
> {{solr.log}} or {{solr_gc.log}} to a file {{solr_log_}} and 
> {{solr_gc_log_}} respectively. That may be all good, but these old 
> copies are never cleaned up, as they are not under the control of log4j.
> This issue will instead rotate solr.log properly on startup, delete old 
> time-stamped files taking up place, back up (one generation only) of 
> console-log and solr_gc.log in $SOLR_LOGS_DIR/archived/.



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

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

[jira] [Commented] (SOLR-9570) Logs backed up on restart are kept forever

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9570: Fix test failures and start using SolrTestCaseJ4's createTempDir mm


> Logs backed up on restart are kept forever
> --
>
> Key: SOLR-9570
> URL: https://issues.apache.org/jira/browse/SOLR-9570
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>  Labels: logging
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-8370.patch
>
>
> When (re)starting Solr, the start script will backup any existing 
> {{solr.log}} or {{solr_gc.log}} to a file {{solr_log_}} and 
> {{solr_gc_log_}} respectively. That may be all good, but these old 
> copies are never cleaned up, as they are not under the control of log4j.
> This issue will instead rotate solr.log properly on startup, delete old 
> time-stamped files taking up place, back up (one generation only) of 
> console-log and solr_gc.log in $SOLR_LOGS_DIR/archived/.



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

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18099/
Java: 64bit/jdk-9-ea+140 -XX:-UseCompressedOops -XX:+UseParallelGC

8 tests failed.
FAILED:  
org.apache.lucene.index.TestIndexWriterExceptions.testMergeExceptionIsTragic

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([FB309CF497ACFE38:84FF0CBE67736812]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertFalse(Assert.java:68)
at org.junit.Assert.assertFalse(Assert.java:79)
at 
org.apache.lucene.index.TestIndexWriterExceptions.testMergeExceptionIsTragic(TestIndexWriterExceptions.java:2319)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(java.base@9-ea/Thread.java:843)


FAILED:  org.apache.solr.util.UtilsToolTest.testRemoveOldGcLogs

Error Message:
Logs directory must be an absolute path, or -s must be supplied

Stack Trace:
java.lang.Exception: Logs directory must be an absolute path, or -s must be 
supplied
at 
org.apache.solr.util.SolrCLI$UtilsTool.prepareLogsPath(SolrCLI.java:3576)
at 
org.apache.solr.util.SolrCLI$UtilsTool.archiveGcLogs(SolrCLI.java:3441)
at 

[jira] [Updated] (SOLR-9533) Reload core config when a core is reloaded

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-9533:
-
Attachment: SOLR-9533.patch

Small patch that handles the reload.

This is just for review. If people are ok with this approach I'll work on a 
test case.

> Reload core config when a core is reloaded
> --
>
> Key: SOLR-9533
> URL: https://issues.apache.org/jira/browse/SOLR-9533
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Gethin James
>Assignee: Joel Bernstein
> Attachments: SOLR-9533.patch
>
>
> I am reloading a core using {{coreContainer.reload(coreName)}}.  However it 
> doesn't seem to reload the configuration.  I have changed solrcore.properties 
> on the file system but the change doesn't get picked up.
> The coreContainer.reload method seems to call:
> {code}
> CoreDescriptor cd = core.getCoreDescriptor();
> {code}
> I can't see a way to reload CoreDescriptor, so it isn't picking up my 
> changes.  It simply reuses the existing CoreDescriptor.



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

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

[jira] [Reopened] (SOLR-9570) Logs backed up on restart are kept forever

[JIRA]

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

Jan Høydahl reopened SOLR-9570:
---

Reopening to fix a test failure

> Logs backed up on restart are kept forever
> --
>
> Key: SOLR-9570
> URL: https://issues.apache.org/jira/browse/SOLR-9570
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>  Labels: logging
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-8370.patch
>
>
> When (re)starting Solr, the start script will backup any existing 
> {{solr.log}} or {{solr_gc.log}} to a file {{solr_log_}} and 
> {{solr_gc_log_}} respectively. That may be all good, but these old 
> copies are never cleaned up, as they are not under the control of log4j.
> This issue will instead rotate solr.log properly on startup, delete old 
> time-stamped files taking up place, back up (one generation only) of 
> console-log and solr_gc.log in $SOLR_LOGS_DIR/archived/.



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

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

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1134 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1134/

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.ConcurrentDeleteAndCreateCollectionTest

Error Message:
ObjectTracker found 10 object(s) that were not released!!! [InternalHttpClient, 
InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, 
InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, 
InternalHttpClient] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:43)
  at 
org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:267)
  at 
org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:214)
  at 
org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:201)
  at 
org.apache.solr.client.solrj.impl.HttpSolrClient.(HttpSolrClient.java:210)
  at 
org.apache.solr.client.solrj.impl.HttpSolrClient.(HttpSolrClient.java:183)
  at 
org.apache.solr.client.solrj.impl.HttpSolrClient.(HttpSolrClient.java:167)
  at org.apache.solr.SolrTestCaseJ4.getHttpSolrClient(SolrTestCaseJ4.java:2251) 
 at 
org.apache.solr.cloud.ConcurrentDeleteAndCreateCollectionTest.testConcurrentCreateAndDeleteDoesNotFail(ConcurrentDeleteAndCreateCollectionTest.java:62)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)  at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)  
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:498)  at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
  at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
  at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
  at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
  at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
  at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
  at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
  at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
  at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
  at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
  at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
  at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
  at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
  at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
  at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
  at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
  at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
  at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
  at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
  at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
  at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
  at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
  at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
  at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
  at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
  at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
  at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
  at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
  at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
  at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
  at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
  at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
  at 

[jira] [Created] (SOLR-9674) Facet Values Sort Order: Index should ignore casing

[Luke P Warwick (JIRA)]

Luke P Warwick created SOLR-9674:


 Summary: Facet Values Sort Order: Index should ignore casing
 Key: SOLR-9674
 URL: https://issues.apache.org/jira/browse/SOLR-9674
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Facet Module, faceting
Reporter: Luke P Warwick


Index facet value sorting puts all values that start with a capital letter 
before all values that start with a lower case letter.  

Since users often don't know this pattern, nor that the value they are looking 
for might start with a lower case letter, it leads to confusion and bad 
experiences, in particular in E-commerce with the 'Brand' Facet.

Desired behavior is that the order ignore case. If two values are otherwise 
equal (Patagonia,patagonia), put the capital first.

Example:
Current Order: Anon,Marmot,Patagonia,Smith,Zoot,maloja,prAna
Desired Order: Anon,Marmot,maloja,Patagonia,prAna,Smith,Zoot





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

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

[jira] [Moved] (LUCENE-7513) Update to randomizedtesting 2.4.0

[Dawid Weiss (JIRA)]

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

Dawid Weiss moved SOLR-9673 to LUCENE-7513:
---

Fix Version/s: (was: 6.x)
   (was: master (7.0))
   master (7.0)
   6.x
 Security: (was: Public)
Lucene Fields: New
  Key: LUCENE-7513  (was: SOLR-9673)
  Project: Lucene - Core  (was: Solr)

> Update to randomizedtesting 2.4.0
> -
>
> Key: LUCENE-7513
> URL: https://issues.apache.org/jira/browse/LUCENE-7513
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 6.x, master (7.0)
>
>
> Update to randomizedtesting 2.4.0. Should help us diagnose issues with 
> hanging JVMs (SOLR-9618). 
> There's also an addition of "biased" (evil) random number generation 
> routines. Perhaps they'll be interesting to some of you.
> https://github.com/randomizedtesting/randomizedtesting/releases/tag/release%2F2.4.0



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

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

[jira] [Created] (SOLR-9673) Update to randomizedtesting 2.4.0

[Dawid Weiss (JIRA)]

Dawid Weiss created SOLR-9673:
-

 Summary: Update to randomizedtesting 2.4.0
 Key: SOLR-9673
 URL: https://issues.apache.org/jira/browse/SOLR-9673
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
 Fix For: 6.x, master (7.0)


Update to randomizedtesting 2.4.0. Should help us diagnose issues with hanging 
JVMs (SOLR-9618). 

There's also an addition of "biased" (evil) random number generation routines. 
Perhaps they'll be interesting to some of you.

https://github.com/randomizedtesting/randomizedtesting/releases/tag/release%2F2.4.0



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

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

[jira] [Commented] (SOLR-9641) Emit distributed tracing information from Solr

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9641:


Yes.  Perhaps the default solr.xml might have a commented trace section -- 
brief.

> Emit distributed tracing information from Solr
> --
>
> Key: SOLR-9641
> URL: https://issues.apache.org/jira/browse/SOLR-9641
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mike Drob
> Fix For: master (7.0)
>
> Attachments: SOLR-9641.patch
>
>
> While Solr already offers a few tools for exposing timing, this information 
> can be difficult to aggregate and analyze. By integrating distributed tracing 
> into Solr operations, we can gain new performance and behaviour insights.
> One such solution can be accomplished via Apache HTrace (incubating).
> (More rationale to follow.)



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

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

[jira] [Commented] (SOLR-9570) Logs backed up on restart are kept forever

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-9570:
--

is this causing the failure 
https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1996/

> Logs backed up on restart are kept forever
> --
>
> Key: SOLR-9570
> URL: https://issues.apache.org/jira/browse/SOLR-9570
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>  Labels: logging
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-8370.patch
>
>
> When (re)starting Solr, the start script will backup any existing 
> {{solr.log}} or {{solr_gc.log}} to a file {{solr_log_}} and 
> {{solr_gc_log_}} respectively. That may be all good, but these old 
> copies are never cleaned up, as they are not under the control of log4j.
> This issue will instead rotate solr.log properly on startup, delete old 
> time-stamped files taking up place, back up (one generation only) of 
> console-log and solr_gc.log in $SOLR_LOGS_DIR/archived/.



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

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/461/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC

7 tests failed.
FAILED:  org.apache.solr.util.UtilsToolTest.testNonexisting

Error Message:
Logs directory must be an absolute path, or -s must be supplied

Stack Trace:
java.lang.Exception: Logs directory must be an absolute path, or -s must be 
supplied
at 
org.apache.solr.util.SolrCLI$UtilsTool.prepareLogsPath(SolrCLI.java:3577)
at 
org.apache.solr.util.SolrCLI$UtilsTool.removeOldSolrLogs(SolrCLI.java:3544)
at org.apache.solr.util.SolrCLI$UtilsTool.runTool(SolrCLI.java:3422)
at org.apache.solr.util.UtilsToolTest.runTool(UtilsToolTest.java:183)
at 
org.apache.solr.util.UtilsToolTest.testNonexisting(UtilsToolTest.java:98)
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 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:243)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:354)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:10)


FAILED:  org.apache.solr.util.UtilsToolTest.testArchiveConsoleLogs

Error Message:
Logs directory must be an absolute path, or -s must be supplied

Stack Trace:
java.lang.Exception: Logs directory must be an absolute path, or -s must be 
supplied
at 
org.apache.solr.util.SolrCLI$UtilsTool.prepareLogsPath(SolrCLI.java:3577)
at 
org.apache.solr.util.SolrCLI$UtilsTool.archiveConsoleLogs(SolrCLI.java:3471)
at org.apache.solr.util.SolrCLI$UtilsTool.runTool(SolrCLI.java:3431)
at org.apache.solr.util.UtilsToolTest.runTool(UtilsToolTest.java:183)
at 
org.apache.solr.util.UtilsToolTest.testArchiveConsoleLogs(UtilsToolTest.java:150)
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 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at 

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1996/
Java: 32bit/jdk-9-ea+140 -server -XX:+UseConcMarkSweepGC

8 tests failed.
FAILED:  
org.apache.solr.handler.component.SpellCheckComponentTest.testThresholdTokenFrequency

Error Message:
Path not found: /spellcheck/suggestions/[1]/suggestion

Stack Trace:
java.lang.RuntimeException: Path not found: 
/spellcheck/suggestions/[1]/suggestion
at 
__randomizedtesting.SeedInfo.seed([4FA949C6AA330951:C50EC63725D8302A]:0)
at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:901)
at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:848)
at 
org.apache.solr.handler.component.SpellCheckComponentTest.testThresholdTokenFrequency(SpellCheckComponentTest.java:277)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(java.base@9-ea/Thread.java:843)


FAILED:  

[jira] [Updated] (SOLR-9626) Admin UI (new) does not include highlighting indicating match in Analysis View

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-9626:

Summary: Admin UI (new) does not include highlighting indicating match in 
Analysis View  (was: Admin UI (new) does not include highlighting incidating 
match in Analysis View)

> Admin UI (new) does not include highlighting indicating match in Analysis View
> --
>
> Key: SOLR-9626
> URL: https://issues.apache.org/jira/browse/SOLR-9626
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UI
>Affects Versions: 6.2
>Reporter: Esther Quansah
>Priority: Minor
>
> When using the analysis view in the new Solr Admin UI, an index-query time 
> match should be indicated by highlighting the final result in the chain. This 
> works in the old UI but not the new UI. 



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

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

[jira] [Commented] (SOLR-9641) Emit distributed tracing information from Solr

[Mike Drob (JIRA)]

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

Mike Drob commented on SOLR-9641:
-

Documenting what goes in the {{trace}} section in solr.xml would also be 
ref-guide, yes?

> Emit distributed tracing information from Solr
> --
>
> Key: SOLR-9641
> URL: https://issues.apache.org/jira/browse/SOLR-9641
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mike Drob
> Fix For: master (7.0)
>
> Attachments: SOLR-9641.patch
>
>
> While Solr already offers a few tools for exposing timing, this information 
> can be difficult to aggregate and analyze. By integrating distributed tracing 
> into Solr operations, we can gain new performance and behaviour insights.
> One such solution can be accomplished via Apache HTrace (incubating).
> (More rationale to follow.)



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

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

[jira] [Created] (SOLR-9672) When using a mutilvalued field(fieldname) in fl an error appears

[Matthew Wilcoxson (JIRA)]

Matthew Wilcoxson created SOLR-9672:
---

 Summary: When using a mutilvalued field(fieldname) in fl an error 
appears
 Key: SOLR-9672
 URL: https://issues.apache.org/jira/browse/SOLR-9672
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.2.1, 5.5
 Environment: Using Docker Hubs Solr:6.2 
Reporter: Matthew Wilcoxson
Priority: Minor


When using a schema.xml with a field marked as multiValued, e.g.:


this error occurs:
"an not use FieldCache on multivalued field: frbr_Image-image",
when the field is requested in the fl parameter and wrapped in the field() 
syntax, i.e.:
fl=field(frbr_Image-image)
Full url:   
http://localhost:8983/solr/manifestations_stage/select?fl=field(frbr_Image-image)=*:*

When you remove the field() syntax the error doesn't occur and the correct 
values are returned. This occurs even if the fieldname doesn't need to be 
wrapped.

I'm mostly using the default solrconfig.xml file (with a few lines taken out)



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

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

[jira] [Assigned] (SOLR-9326) Ability to create/delete/list snapshots for a solr collection

[Yonik Seeley (JIRA)]

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

Yonik Seeley reassigned SOLR-9326:
--

Assignee: Yonik Seeley

> Ability to create/delete/list snapshots for a solr collection
> -
>
> Key: SOLR-9326
> URL: https://issues.apache.org/jira/browse/SOLR-9326
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Hrishikesh Gadre
>Assignee: Yonik Seeley
>




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

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

[jira] [Updated] (SOLR-9506) cache IndexFingerprint for each segment

[Pushkar Raste (JIRA)]

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

Pushkar Raste updated SOLR-9506:

Attachment: SOLR-9506.patch

Patch with parallalized computation 

> cache IndexFingerprint for each segment
> ---
>
> Key: SOLR-9506
> URL: https://issues.apache.org/jira/browse/SOLR-9506
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
> Attachments: SOLR-9506.patch, SOLR-9506.patch, SOLR-9506.patch, 
> SOLR-9506.patch, SOLR-9506_POC.patch
>
>
> The IndexFingerprint is cached per index searcher. it is quite useless during 
> high throughput indexing. If the fingerprint is cached per segment it will 
> make it vastly more efficient to compute the fingerprint



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

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

[jira] [Commented] (SOLR-9326) Ability to create/delete/list snapshots for a solr collection

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-9326:


[~yo...@apache.org] I have updated the PR with all the changes. Please take a 
look.

> Ability to create/delete/list snapshots for a solr collection
> -
>
> Key: SOLR-9326
> URL: https://issues.apache.org/jira/browse/SOLR-9326
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Hrishikesh Gadre
>




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

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

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_102) - Build # 18098 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18098/
Java: 32bit/jdk1.8.0_102 -client -XX:+UseG1GC

7 tests failed.
FAILED:  org.apache.solr.util.UtilsToolTest.testEmptyAndQuiet

Error Message:
Logs directory must be an absolute path, or -s must be supplied

Stack Trace:
java.lang.Exception: Logs directory must be an absolute path, or -s must be 
supplied
at 
org.apache.solr.util.SolrCLI$UtilsTool.prepareLogsPath(SolrCLI.java:3576)
at 
org.apache.solr.util.SolrCLI$UtilsTool.removeOldSolrLogs(SolrCLI.java:3543)
at org.apache.solr.util.SolrCLI$UtilsTool.runTool(SolrCLI.java:3421)
at org.apache.solr.util.UtilsToolTest.runTool(UtilsToolTest.java:183)
at 
org.apache.solr.util.UtilsToolTest.testEmptyAndQuiet(UtilsToolTest.java:87)
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 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:243)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:354)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:10)


FAILED:  org.apache.solr.util.UtilsToolTest.testRemoveOldSolrLogs

Error Message:
Logs directory must be an absolute path, or -s must be supplied

Stack Trace:
java.lang.Exception: Logs directory must be an absolute path, or -s must be 
supplied
at 
org.apache.solr.util.SolrCLI$UtilsTool.prepareLogsPath(SolrCLI.java:3576)
at 
org.apache.solr.util.SolrCLI$UtilsTool.removeOldSolrLogs(SolrCLI.java:3543)
at org.apache.solr.util.SolrCLI$UtilsTool.runTool(SolrCLI.java:3421)
at org.apache.solr.util.UtilsToolTest.runTool(UtilsToolTest.java:183)
at 
org.apache.solr.util.UtilsToolTest.testRemoveOldSolrLogs(UtilsToolTest.java:105)
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 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:243)

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 918 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/918/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

8 tests failed.
FAILED:  
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail

Error Message:
expected:<200> but was:<404>

Stack Trace:
java.lang.AssertionError: expected:<200> but was:<404>
at 
__randomizedtesting.SeedInfo.seed([6AFB35260FA94A54:244000CDF3358B8]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.cancelDelegationToken(TestSolrCloudWithDelegationTokens.java:140)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail(TestSolrCloudWithDelegationTokens.java:294)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Updated] (SOLR-9671) TestMiniSolrCloudCluster blowup jvm with remote /get requests

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-9671:
---
Attachment: TestMiniSolrCloudCluster-epic-fail.zip

when TestMiniSolrCloudCluster.testCollectionCreateSearchDelete() tries to 
create collection last time. we have wait loop 
bq. (qtp1915946497-3004) [] o.a.s.h.a.CoreAdminOperation Checking request 
status for : a4310491-abb0-4d8d-a290-2f8d2a909be7241809864829983
and
bq.(parallelCoreAdminExecutor-1329-thread-1) [] o.a.s.u.PeerSync PeerSync: 
core=testcollection_shard2_replica2 url=http://127.0.0.1:42320/solr DONE.  We 
have no versions.  sync failed.
 and then it just 
bq. java.lang.OutOfMemoryError: Java heap space

Do you have any clues to troubleshoot? 

> TestMiniSolrCloudCluster blowup jvm with remote /get requests
> -
>
> Key: SOLR-9671
> URL: https://issues.apache.org/jira/browse/SOLR-9671
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
>  Labels: cloud
> Attachments: TestMiniSolrCloudCluster-epic-fail.zip
>
>
> this is epic https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1994/
> There is no many cores, I checked. It seems like cluster blow up when tries 
> to launch after collection remove. Haven't tried to reproduce it locally 



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

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

[jira] [Commented] (SOLR-9665) Facet Values Sort Order: Add 3rd choice: Numeric Sort

[Luke P Warwick (JIRA)]

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

Luke P Warwick commented on SOLR-9665:
--

The desire is to have dynamic ordering since the values are dynamic. The 
examples I gave were just small subsets of much larger lists of values.  
Attributes like Size and Brand can actually have 100s or even 1000s of values 
and there are always new values being added (and old values dropping off) so 
manually maintaining a list would be very cumbersome.

For smaller,fixed lists the EnumField probably will work though. Thanks David.

> Facet Values Sort Order: Add 3rd choice: Numeric Sort
> -
>
> Key: SOLR-9665
> URL: https://issues.apache.org/jira/browse/SOLR-9665
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: faceting
>Reporter: Luke P Warwick
>
> As a person, I need facet values to be in predictable, intuitive spots so 
> that I can quickly and easily find the values that are appropriate to me.
> Problem Statement: Today Solr has two default facet sort orders, neither of 
> which provides predictable, intuitive facet value orders for people when the 
> values start with numbers.  
> Goal: Address the problem where index sorts facet values how a computer would 
> rather than how a human would.  This is very problematic for E-commerce 
> facets like 'size' and 'tire width'
> Acceptance Criteria:
> 1. Sorts facet values numerically from lowest to highest
> 2. Works with both numeric and string fields (thus working on values that 
> include letters... 25 mm, 30 waist, 32 Waist, 4 Petite)
> 3. If facet values don't start with a number, they are sorted alphabetically, 
> after all values that do start with a number
> 4. If facet values are equal numerically, sort the numerically equal values 
> alphabetically. Example: 10,10 Petite,10 Tall,12, Petite, 12 Tall
> 5. Integers and Floats are supported (even if string field)
> Examples:
> Women's Pants Sizes:
> 8
> 8 Tall
> 10
> 10 Petite
> 10 Tall
> 12
> 12 Tall
> 14 Petite
> 26 Waist
> 28 Waist
> 30 Waist
> One Size
> Bike Wheel Sizes:
> 20 Inches
> 24 Inches
> 26 Inches
> 27 Inches
> 27.5 Inches
> 27.5+ Inches
> 29 Inches
> 650c
> 700c



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

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

[jira] [Created] (SOLR-9671) TestMiniSolrCloudCluster blowup jvm with remote /get requests

[Mikhail Khludnev (JIRA)]

Mikhail Khludnev created SOLR-9671:
--

 Summary: TestMiniSolrCloudCluster blowup jvm with remote /get 
requests
 Key: SOLR-9671
 URL: https://issues.apache.org/jira/browse/SOLR-9671
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Mikhail Khludnev


this is epic https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1994/
There is no many cores, I checked. It seems like cluster blow up when tries to 
launch after collection remove. Haven't tried to reproduce it locally 




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

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

[jira] [Commented] (SOLR-9399) Delete requests do not send credentials & fails for Basic Authentication

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-9399:
-

I recall something similar experience but let me again look after test has
been refactored to make it fail first.




> Delete requests do not send credentials & fails for Basic Authentication
> 
>
> Key: SOLR-9399
> URL: https://issues.apache.org/jira/browse/SOLR-9399
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 6.0, 6.0.1, 6.x
>Reporter: Susheel Kumar
>  Labels: security
>
> The getRoutes(..) func of UpdateRequest do not pass credentials to 
> LBHttpSolrClient when deleteById is set while for updates it passes the 
> credentials.  See below code snippet
>   if (deleteById != null) {
>   
>   Iterator>> entries = 
> deleteById.entrySet()
>   .iterator();
>   while (entries.hasNext()) {
> 
> Map.Entry> entry = entries.next();
> 
> String deleteId = entry.getKey();
> Map map = entry.getValue();
> Long version = null;
> if (map != null) {
>   version = (Long) map.get(VER);
> }
> Slice slice = router.getTargetSlice(deleteId, null, null, null, col);
> if (slice == null) {
>   return null;
> }
> List urls = urlMap.get(slice.getName());
> if (urls == null) {
>   return null;
> }
> String leaderUrl = urls.get(0);
> LBHttpSolrClient.Req request = routes.get(leaderUrl);
> if (request != null) {
>   UpdateRequest urequest = (UpdateRequest) request.getRequest();
>   urequest.deleteById(deleteId, version);
> } else {
>   UpdateRequest urequest = new UpdateRequest();
>   urequest.setParams(params);
>   urequest.deleteById(deleteId, version);
>   urequest.setCommitWithin(getCommitWithin());
>   request = new LBHttpSolrClient.Req(urequest, urls);
>   routes.put(leaderUrl, request);
> }
>   }
> }



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

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

[jira] [Commented] (SOLR-9399) Delete requests do not send credentials & fails for Basic Authentication

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-9399:
-

I recall something similar experience but let me again look after test has
been refactored to make it fail first.




> Delete requests do not send credentials & fails for Basic Authentication
> 
>
> Key: SOLR-9399
> URL: https://issues.apache.org/jira/browse/SOLR-9399
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 6.0, 6.0.1, 6.x
>Reporter: Susheel Kumar
>  Labels: security
>
> The getRoutes(..) func of UpdateRequest do not pass credentials to 
> LBHttpSolrClient when deleteById is set while for updates it passes the 
> credentials.  See below code snippet
>   if (deleteById != null) {
>   
>   Iterator>> entries = 
> deleteById.entrySet()
>   .iterator();
>   while (entries.hasNext()) {
> 
> Map.Entry> entry = entries.next();
> 
> String deleteId = entry.getKey();
> Map map = entry.getValue();
> Long version = null;
> if (map != null) {
>   version = (Long) map.get(VER);
> }
> Slice slice = router.getTargetSlice(deleteId, null, null, null, col);
> if (slice == null) {
>   return null;
> }
> List urls = urlMap.get(slice.getName());
> if (urls == null) {
>   return null;
> }
> String leaderUrl = urls.get(0);
> LBHttpSolrClient.Req request = routes.get(leaderUrl);
> if (request != null) {
>   UpdateRequest urequest = (UpdateRequest) request.getRequest();
>   urequest.deleteById(deleteId, version);
> } else {
>   UpdateRequest urequest = new UpdateRequest();
>   urequest.setParams(params);
>   urequest.deleteById(deleteId, version);
>   urequest.setCommitWithin(getCommitWithin());
>   request = new LBHttpSolrClient.Req(urequest, urls);
>   routes.put(leaderUrl, request);
> }
>   }
> }



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

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

[jira] [Commented] (SOLR-9657) Create a new TemplateUpdateRequestProcessorFactory

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-9657:
-

The Javadoc comment format is not correct for the class and does not build the 
description into the resulting Javadoc.

Basically, you have to use the correct multi-line comment delimiters, as per 
[the 
rules|http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#format].
 Or see the parent or any other class that have them.

> Create a new TemplateUpdateRequestProcessorFactory
> --
>
> Key: SOLR-9657
> URL: https://issues.apache.org/jira/browse/SOLR-9657
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9657.patch
>
>
> Unlike other URPs, this will operate on request parameters
> example:
> {code}
> processor=Template=fname:${somefield}some_string${someotherfield}
> {code}
> The actual name of the class is {{TemplateUpdateProcessorFactory}} and it is 
> possible to optionally drop the {{UpdateProcessorfactory}} part.  The 
> {{Template.field}} specifies a field name as well as a template. The 
> {{Template.field}} parameter is multivalued , so , it is possible to add 
> multiple fields or a multivalued field with same name



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

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

[jira] [Commented] (SOLR-9533) Reload core config when a core is reloaded

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-9533:
--

I think this was more of an oversight to not reload the properties. If you 
reload the core it would seem that picking up the properties changes would be 
the right thing to do.



> Reload core config when a core is reloaded
> --
>
> Key: SOLR-9533
> URL: https://issues.apache.org/jira/browse/SOLR-9533
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Gethin James
>Assignee: Joel Bernstein
>
> I am reloading a core using {{coreContainer.reload(coreName)}}.  However it 
> doesn't seem to reload the configuration.  I have changed solrcore.properties 
> on the file system but the change doesn't get picked up.
> The coreContainer.reload method seems to call:
> {code}
> CoreDescriptor cd = core.getCoreDescriptor();
> {code}
> I can't see a way to reload CoreDescriptor, so it isn't picking up my 
> changes.  It simply reuses the existing CoreDescriptor.



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

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

[jira] [Commented] (SOLR-9533) Reload core config when a core is reloaded

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-9533:


but it might not be intended to do so 
https://cwiki.apache.org/confluence/display/solr/CoreAdmin+API#CoreAdminAPI-RELOAD
bq. RELOAD performs "live" reloads of SolrCore, reusing some existing objects. 
Some configuration options, such as the dataDir location and 
IndexWriter-related settings in solrconfig.xml can not be changed and made 
active with a simple RELOAD action.
I'm just concerting that there is some feature behind this limitation 

> Reload core config when a core is reloaded
> --
>
> Key: SOLR-9533
> URL: https://issues.apache.org/jira/browse/SOLR-9533
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Gethin James
>Assignee: Joel Bernstein
>
> I am reloading a core using {{coreContainer.reload(coreName)}}.  However it 
> doesn't seem to reload the configuration.  I have changed solrcore.properties 
> on the file system but the change doesn't get picked up.
> The coreContainer.reload method seems to call:
> {code}
> CoreDescriptor cd = core.getCoreDescriptor();
> {code}
> I can't see a way to reload CoreDescriptor, so it isn't picking up my 
> changes.  It simply reuses the existing CoreDescriptor.



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

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

[jira] [Commented] (SOLR-9533) Reload core config when a core is reloaded

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-9533:
--

I've been reviewing the code around the core reload and it looks like the 
easiest approach to loading the properties would be the following:

1) In the SolrCore.reload method create a new CoreDescriptor from the old 
CoreDescriptor. We can do this easily because there is a constructor in the 
CoreDescriptor already that takes an existing CoreDescriptor and deep clones it.

2) Then call CoreDescriptor.loadExtraProperties before passing it to the 
constructor of the new core.

I'll put a patch together for this. I'll also investigate the existing test 
cases for a core reload and see how easy it is to test the properties reload.



> Reload core config when a core is reloaded
> --
>
> Key: SOLR-9533
> URL: https://issues.apache.org/jira/browse/SOLR-9533
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Gethin James
>Assignee: Joel Bernstein
>
> I am reloading a core using {{coreContainer.reload(coreName)}}.  However it 
> doesn't seem to reload the configuration.  I have changed solrcore.properties 
> on the file system but the change doesn't get picked up.
> The coreContainer.reload method seems to call:
> {code}
> CoreDescriptor cd = core.getCoreDescriptor();
> {code}
> I can't see a way to reload CoreDescriptor, so it isn't picking up my 
> changes.  It simply reuses the existing CoreDescriptor.



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

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

[jira] [Commented] (SOLR-9641) Emit distributed tracing information from Solr

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9641:


Docs:
* javadocs: probably on the Tracer field you added to core container. 
TracerUtils.java should refer to that so people know where it's placed in Solr.
* user docs: we'll probably want to add this to the ref guide... at least 
something very brief that can demonstrate the simplest useful way to see it in 
action, and then we refer users to other possibilities (i.e. ZipKin).  There 
ought to be a reference to this feature in the vicinity of where 
debugQuery/debug=timing is so people know of this more sophisticated option.

> Emit distributed tracing information from Solr
> --
>
> Key: SOLR-9641
> URL: https://issues.apache.org/jira/browse/SOLR-9641
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mike Drob
> Fix For: master (7.0)
>
> Attachments: SOLR-9641.patch
>
>
> While Solr already offers a few tools for exposing timing, this information 
> can be difficult to aggregate and analyze. By integrating distributed tracing 
> into Solr operations, we can gain new performance and behaviour insights.
> One such solution can be accomplished via Apache HTrace (incubating).
> (More rationale to follow.)



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

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

[jira] [Assigned] (SOLR-9533) Reload core config when a core is reloaded

[Joel Bernstein (JIRA)]

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

Joel Bernstein reassigned SOLR-9533:


Assignee: Joel Bernstein

> Reload core config when a core is reloaded
> --
>
> Key: SOLR-9533
> URL: https://issues.apache.org/jira/browse/SOLR-9533
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Gethin James
>Assignee: Joel Bernstein
>
> I am reloading a core using {{coreContainer.reload(coreName)}}.  However it 
> doesn't seem to reload the configuration.  I have changed solrcore.properties 
> on the file system but the change doesn't get picked up.
> The coreContainer.reload method seems to call:
> {code}
> CoreDescriptor cd = core.getCoreDescriptor();
> {code}
> I can't see a way to reload CoreDescriptor, so it isn't picking up my 
> changes.  It simply reuses the existing CoreDescriptor.



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

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

[jira] [Commented] (SOLR-9641) Emit distributed tracing information from Solr

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9641:


See HttpSolrCall.call around line 469 (writeResponse)

> Emit distributed tracing information from Solr
> --
>
> Key: SOLR-9641
> URL: https://issues.apache.org/jira/browse/SOLR-9641
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mike Drob
> Fix For: master (7.0)
>
> Attachments: SOLR-9641.patch
>
>
> While Solr already offers a few tools for exposing timing, this information 
> can be difficult to aggregate and analyze. By integrating distributed tracing 
> into Solr operations, we can gain new performance and behaviour insights.
> One such solution can be accomplished via Apache HTrace (incubating).
> (More rationale to follow.)



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

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

[jira] [Resolved] (SOLR-9657) Create a new TemplateUpdateRequestProcessorFactory

[Noble Paul (JIRA)]

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

Noble Paul resolved SOLR-9657.
--
   Resolution: Fixed
Fix Version/s: master (7.0)
   6.3

> Create a new TemplateUpdateRequestProcessorFactory
> --
>
> Key: SOLR-9657
> URL: https://issues.apache.org/jira/browse/SOLR-9657
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9657.patch
>
>
> Unlike other URPs, this will operate on request parameters
> example:
> {code}
> processor=Template=fname:${somefield}some_string${someotherfield}
> {code}
> The actual name of the class is {{TemplateUpdateProcessorFactory}} and it is 
> possible to optionally drop the {{UpdateProcessorfactory}} part.  The 
> {{Template.field}} specifies a field name as well as a template. The 
> {{Template.field}} parameter is multivalued , so , it is possible to add 
> multiple fields or a multivalued field with same name



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

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

[jira] [Commented] (SOLR-9657) Create a new TemplateUpdateRequestProcessorFactory

[ASF subversion and git services (JIRA)]

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

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

Commit b1e2d02ec3e2d87bd406190f1600dccd679901f9 in lucene-solr's branch 
refs/heads/branch_6x from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b1e2d02 ]

SOLR-9657: Use cache for templates


> Create a new TemplateUpdateRequestProcessorFactory
> --
>
> Key: SOLR-9657
> URL: https://issues.apache.org/jira/browse/SOLR-9657
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9657.patch
>
>
> Unlike other URPs, this will operate on request parameters
> example:
> {code}
> processor=Template=fname:${somefield}some_string${someotherfield}
> {code}
> The actual name of the class is {{TemplateUpdateProcessorFactory}} and it is 
> possible to optionally drop the {{UpdateProcessorfactory}} part.  The 
> {{Template.field}} specifies a field name as well as a template. The 
> {{Template.field}} parameter is multivalued , so , it is possible to add 
> multiple fields or a multivalued field with same name



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

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

[jira] [Commented] (SOLR-9657) Create a new TemplateUpdateRequestProcessorFactory

[ASF subversion and git services (JIRA)]

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

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

Commit 127bf9f772468cbc94478ad67d54652001b175e0 in lucene-solr's branch 
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=127bf9f ]

SOLR-9657: Use cache for templates


> Create a new TemplateUpdateRequestProcessorFactory
> --
>
> Key: SOLR-9657
> URL: https://issues.apache.org/jira/browse/SOLR-9657
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9657.patch
>
>
> Unlike other URPs, this will operate on request parameters
> example:
> {code}
> processor=Template=fname:${somefield}some_string${someotherfield}
> {code}
> The actual name of the class is {{TemplateUpdateProcessorFactory}} and it is 
> possible to optionally drop the {{UpdateProcessorfactory}} part.  The 
> {{Template.field}} specifies a field name as well as a template. The 
> {{Template.field}} parameter is multivalued , so , it is possible to add 
> multiple fields or a multivalued field with same name



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

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

[jira] [Commented] (SOLR-9641) Emit distributed tracing information from Solr

[Mike Drob (JIRA)]

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

Mike Drob commented on SOLR-9641:
-

[~tomasflobbe] - we were talking last week about adding a trace around the 
response writer, but I'm struggling to find where that logic is. Can you give 
me a pointer?

> Emit distributed tracing information from Solr
> --
>
> Key: SOLR-9641
> URL: https://issues.apache.org/jira/browse/SOLR-9641
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mike Drob
> Fix For: master (7.0)
>
> Attachments: SOLR-9641.patch
>
>
> While Solr already offers a few tools for exposing timing, this information 
> can be difficult to aggregate and analyze. By integrating distributed tracing 
> into Solr operations, we can gain new performance and behaviour insights.
> One such solution can be accomplished via Apache HTrace (incubating).
> (More rationale to follow.)



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

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

[jira] [Commented] (SOLR-9641) Emit distributed tracing information from Solr

[Mike Drob (JIRA)]

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

Mike Drob commented on SOLR-9641:
-

Thanks for taking a look, [~dsmiley]!

bq. Can you recommend a tool that can be used with Solr after this patch is 
applied to visualize or otherwise make use of it to help us analyze Solr 
performance?
The built in HTrace viewer is reasonable for some purposes, but probably not 
ideal for all purposes. There is also a Zipkin bridge, so you could use that as 
your visualizer. Both are configured by setting the {{span.receiver.classes}} 
configuration to the appropriate value.

My docs are pretty sparse at the moment, where would you suggest placing them? 
We can have a short description and then refer to the full HTrace docs for 
completeness.

{quote}
* SolrCore.newScope: guard log.debug with log.isDebugEnabled to avoid toString
* HttpShardHandler: maybe instead of always wrapping task with traceTask we 
instead conditionally replace task with a tracing one? This way we conveniently 
avoid the wrapping if there is no tracing.
* CommonParams.java:TRACE_ID: a one-liner comment referencing "HTrace" would be 
useful.
{quote}
Done. I'm not going to upload a new patch yet, since the changes are relatively 
minimal and I don't want to clutter the issue.

{quote}
* loadTraceConfig: could you use NamedList.asMap(1) or perhaps not because 
"String" type?
{quote}
I tried this and it worked, but something about it feels incredibly fragile. 
I'll leave it in for now, however.

{quote}
* TracerUtils: I like this. Question: should newScope(SolrQueryRequest request, 
String description) also look in the request params to see if there is a 
parent, and if so conditionally call tracer.newScope with that parent?
{quote}
Hmm, maybe. I know that it is possible to have multiple parents per span, but I 
think the APIs around it are a little clunky. Will need to think on this more.

Actually, no. I don't think we need to pull the parent from the request params 
here, since we already do that in {{SolrCore.newScope}}, which should be 
handling most things. The method in {{TracerUtils}} is more of a convenience 
thing to get at the core container so we can get the tracer.

> Emit distributed tracing information from Solr
> --
>
> Key: SOLR-9641
> URL: https://issues.apache.org/jira/browse/SOLR-9641
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mike Drob
> Fix For: master (7.0)
>
> Attachments: SOLR-9641.patch
>
>
> While Solr already offers a few tools for exposing timing, this information 
> can be difficult to aggregate and analyze. By integrating distributed tracing 
> into Solr operations, we can gain new performance and behaviour insights.
> One such solution can be accomplished via Apache HTrace (incubating).
> (More rationale to follow.)



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

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

[jira] [Commented] (SOLR-9418) Probabilistic-Query-Parser RequestHandler

[Doug Turnbull (JIRA)]

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

Doug Turnbull commented on SOLR-9418:
-

Looking at your patch (I'm not a committer just curious about the patch). A few 
things jump out in a shallow reading that would probably need to change for 
this to be accepted:

- Field names and thresholds likely need to be configurable, as most folks 
won't nescesarilly have a field named exactly "title" or "content." 
- Can this be a qparser plugin instead of a request handler? It's likely I'd 
want to use it alongside other qparsers and SearchComponents (like highlighting 
or facets).
- Can you provide some documentation on how the thresholds work/can be 
configured?

> Probabilistic-Query-Parser RequestHandler
> -
>
> Key: SOLR-9418
> URL: https://issues.apache.org/jira/browse/SOLR-9418
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Akash Mehta
> Attachments: SOLR-9418.zip
>
>
> The main aim of this requestHandler is to get the best parsing for a given 
> query. This basically means recognizing different phrases within the query. 
> We need some kind of training data to generate these phrases. The way this 
> project works is:
> 1.)Generate all possible parsings for the given query
> 2.)For each possible parsing, a naive-bayes like score is calculated.
> 3.)The main scoring is done by going through all the documents in the 
> training set and finding the probability of bunch of words occurring together 
> as a phrase as compared to them occurring randomly in the same document. Then 
> the score is normalized. Some higher importance is given to the title field 
> as compared to content field which is configurable.
> 4.)Finally after scoring each of the possible parsing, the one with the 
> highest score is returned.



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

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

[JENKINS] Lucene-Solr-6.x-MacOSX (64bit/jdk1.8.0) - Build # 483 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/483/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.core.TestDynamicLoading.testDynamicLoading

Error Message:
Could not get expected value  'X val' for path 'x' full output: {   
"responseHeader":{ "status":0, "QTime":0},   "params":{"wt":"json"},   
"context":{ "webapp":"/yko/rw", "path":"/test1", 
"httpMethod":"GET"},   
"class":"org.apache.solr.core.BlobStoreTestRequestHandler",   "x":null},  from 
server:  null

Stack Trace:
java.lang.AssertionError: Could not get expected value  'X val' for path 'x' 
full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "params":{"wt":"json"},
  "context":{
"webapp":"/yko/rw",
"path":"/test1",
"httpMethod":"GET"},
  "class":"org.apache.solr.core.BlobStoreTestRequestHandler",
  "x":null},  from server:  null
at 
__randomizedtesting.SeedInfo.seed([D8E80658C64D:EB7EF5BFF18563ED]: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:535)
at 
org.apache.solr.core.TestDynamicLoading.testDynamicLoading(TestDynamicLoading.java:232)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
   

[jira] [Updated] (LUCENE-7512) supress ecj-lint warinings on precommit

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated LUCENE-7512:
-
Attachment: LUCENE-7512-solr-core-src.patch

[^LUCENE-7512-solr-core-src.patch] shrinks WARNINGs to 
{quote}
-ecj-javadoc-lint-src:
[mkdir] Created dir: C:\Users\MIKHAI~1\AppData\Local\Temp\ecj1760646687
 [ecj-lint] Compiling 990 source files to 
C:\Users\MIKHAI~1\AppData\Local\Temp\ecj1760646687
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
C:\Users\Mikhail_Khludnev\git\lucene-solr\solr\core\lib\org.restlet-2.3.0.jar
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
C:\Users\Mikhail_Khludnev\git\lucene-solr\solr\core\lib\org.restlet.ext.servlet-2.3.0.jar
   [delete] Deleting directory 
C:\Users\MIKHAI~1\AppData\Local\Temp\ecj1760646687
{quote}
however, some changes scary me..  

> supress ecj-lint warinings on precommit
> ---
>
> Key: LUCENE-7512
> URL: https://issues.apache.org/jira/browse/LUCENE-7512
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Mikhail Khludnev
>  Labels: build
> Attachments: LUCENE-7512-solr-core-src.patch
>
>
> Turns out the subj noise too much and people miss significant ERRORs.



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

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1995/
Java: 32bit/jdk-9-ea+140 -server -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.handler.component.SpellCheckComponentTest.test

Error Message:
List size mismatch @ spellcheck/suggestions

Stack Trace:
java.lang.RuntimeException: List size mismatch @ spellcheck/suggestions
at 
__randomizedtesting.SeedInfo.seed([A3EA69290C5E0FCA:2BBE56F3A2A26232]:0)
at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:901)
at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:848)
at 
org.apache.solr.handler.component.SpellCheckComponentTest.test(SpellCheckComponentTest.java:147)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(java.base@9-ea/Thread.java:843)




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

[jira] [Commented] (SOLR-9399) Delete requests do not send credentials & fails for Basic Authentication

[JIRA]

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

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

I tested manually that your fix works, and started carving out a test case, but 
failed to have the deleteById test fail :(
Here was my work-in-progress 
https://github.com/cominvent/lucene-solr/commit/740c8248fe3ad879b290a97d798468c64ceb68ec
 I could not even get the add document command to fail

> Delete requests do not send credentials & fails for Basic Authentication
> 
>
> Key: SOLR-9399
> URL: https://issues.apache.org/jira/browse/SOLR-9399
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 6.0, 6.0.1, 6.x
>Reporter: Susheel Kumar
>  Labels: security
>
> The getRoutes(..) func of UpdateRequest do not pass credentials to 
> LBHttpSolrClient when deleteById is set while for updates it passes the 
> credentials.  See below code snippet
>   if (deleteById != null) {
>   
>   Iterator>> entries = 
> deleteById.entrySet()
>   .iterator();
>   while (entries.hasNext()) {
> 
> Map.Entry> entry = entries.next();
> 
> String deleteId = entry.getKey();
> Map map = entry.getValue();
> Long version = null;
> if (map != null) {
>   version = (Long) map.get(VER);
> }
> Slice slice = router.getTargetSlice(deleteId, null, null, null, col);
> if (slice == null) {
>   return null;
> }
> List urls = urlMap.get(slice.getName());
> if (urls == null) {
>   return null;
> }
> String leaderUrl = urls.get(0);
> LBHttpSolrClient.Req request = routes.get(leaderUrl);
> if (request != null) {
>   UpdateRequest urequest = (UpdateRequest) request.getRequest();
>   urequest.deleteById(deleteId, version);
> } else {
>   UpdateRequest urequest = new UpdateRequest();
>   urequest.setParams(params);
>   urequest.deleteById(deleteId, version);
>   urequest.setCommitWithin(getCommitWithin());
>   request = new LBHttpSolrClient.Req(urequest, urls);
>   routes.put(leaderUrl, request);
> }
>   }
> }



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

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

[jira] [Created] (LUCENE-7512) supress ecj-lint warinings on precommit

[Mikhail Khludnev (JIRA)]

Mikhail Khludnev created LUCENE-7512:


 Summary: supress ecj-lint warinings on precommit
 Key: LUCENE-7512
 URL: https://issues.apache.org/jira/browse/LUCENE-7512
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Mikhail Khludnev


Turns out the subj noise too much and people miss significant ERRORs.



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

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

[jira] [Commented] (SOLR-9666) Extract dynamic fields in LukeResponse

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-9666:


Since it seems like you are just looking for schema information, maybe the 
schema api would be useful?

https://cwiki.apache.org/confluence/display/solr/Schema+API#SchemaAPI-RetrieveSchemaInformation

> Extract dynamic fields in LukeResponse
> --
>
> Key: SOLR-9666
> URL: https://issues.apache.org/jira/browse/SOLR-9666
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 6.2.1
>Reporter: Fengtan
>Priority: Minor
> Attachments: SOLR-9666.patch
>
>
> LukeRequestHandler (/admin/luke), when invoked with the show=schema 
> parameter, returns a list static fields and dynamic fields.
> For instance on my local machine 
> http://localhost:8983/solr/collection1/admin/luke?show=schema returns 
> something like this:
> {code:xml}
> 
>   ...
>   
> 
>   
> string
> I-S-OF-l
>   
>   ...
> 
> 
>   
> string
> I---OF--
>   
>   ...
> 
>   
>   ...
> 
> {code}
> However, when processing a LukeRequest in SolrJ, only static fields are 
> parsed and made available to the client application through 
> lukeResponse.getFieldInfo(). There does not seem to be a way for the client 
> application to get the dynamic fields.
> Maybe we could parse dynamic fields and make them accessible ? Possibly 
> something like this:
> {code}
> public class MyClass {
>   public static void main(String[] args) throws Exception {
> SolrClient client = new 
> HttpSolrClient("http://localhost:8983/solr/collection1;);
> LukeRequest request = new LukeRequest();
> request.setShowSchema(true);
> LukeResponse response = request.process(client);
> Map staticFields = response.getFieldInfo(); // SolrJ 
> already provides this.
> Map dynamicFields = response.getDynamicFieldInfo(); // 
> Proposed improvement.
>   }
> }
> {code}



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

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

[jira] [Created] (SOLR-9670) Support SOLR_AUTHENTICATION_OPTS in solr.cmd

[JIRA]

Jan Høydahl created SOLR-9670:
-

 Summary: Support SOLR_AUTHENTICATION_OPTS in solr.cmd
 Key: SOLR-9670
 URL: https://issues.apache.org/jira/browse/SOLR-9670
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: scripts and tools
Reporter: Jan Høydahl


Add support for SOLR_AUTHENTICATION_OPTS for basic authentication in solr.cmd 
and solr.in.cmd



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

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

[jira] [Resolved] (SOLR-9570) Logs backed up on restart are kept forever

[JIRA]

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

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

> Logs backed up on restart are kept forever
> --
>
> Key: SOLR-9570
> URL: https://issues.apache.org/jira/browse/SOLR-9570
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>  Labels: logging
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-8370.patch
>
>
> When (re)starting Solr, the start script will backup any existing 
> {{solr.log}} or {{solr_gc.log}} to a file {{solr_log_}} and 
> {{solr_gc_log_}} respectively. That may be all good, but these old 
> copies are never cleaned up, as they are not under the control of log4j.
> This issue will instead rotate solr.log properly on startup, delete old 
> time-stamped files taking up place, back up (one generation only) of 
> console-log and solr_gc.log in $SOLR_LOGS_DIR/archived/.



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

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

[jira] [Commented] (SOLR-9570) Logs backed up on restart are kept forever

[JIRA]

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

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

Resolving this. If you discover issues around the new log cleanup/move tasks, 
please reopen this, or create a new issue.

> Logs backed up on restart are kept forever
> --
>
> Key: SOLR-9570
> URL: https://issues.apache.org/jira/browse/SOLR-9570
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>  Labels: logging
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-8370.patch
>
>
> When (re)starting Solr, the start script will backup any existing 
> {{solr.log}} or {{solr_gc.log}} to a file {{solr_log_}} and 
> {{solr_gc_log_}} respectively. That may be all good, but these old 
> copies are never cleaned up, as they are not under the control of log4j.
> This issue will instead rotate solr.log properly on startup, delete old 
> time-stamped files taking up place, back up (one generation only) of 
> console-log and solr_gc.log in $SOLR_LOGS_DIR/archived/.



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

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

[jira] [Commented] (SOLR-7252) Need to sort the facet field values for a particular field in my custom order

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-7252:


Solr's EnumField can address this requirement as-stated.  The limitation is 
that you have to know up-front what the values are and the order -- this 
explicitly goes in the Solr config.  It's not dynamic.  If you modify it, you 
have to re-index.

> Need to sort the facet field values for a particular field in my custom order
> -
>
> Key: SOLR-7252
> URL: https://issues.apache.org/jira/browse/SOLR-7252
> Project: Solr
>  Issue Type: Improvement
>Reporter: Lewin Joy
>
> Hi,
> I have a requirement where a list of values from a facet field needs to be 
> ordered on custom values. The only option i found was to order by the count 
> for that facet field.
> I need something like this:
> Facet: Brand
>Nike (21)
>Reebok (100)
>asics (45)
>Fila (84)
> Notice that the facet values are not sorted by count. But instead, sorted by 
> my custom sorting requirement.
> We want this sorting done in the solr layer rather than the Front end as the 
> requirement keeps changing and we don't want to hard code this sorting in 
> front end.
> Please help. Is this possible to do? 



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

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

[jira] [Commented] (SOLR-9570) Logs backed up on restart are kept forever

[JIRA]

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

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

Sorry, commit log had wrong issue-number.

Committed master (ed3b268d62f23e212c410cb35aa4318afa088f55)
https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=commit;h=97761966f30557c33b3bbb131ce64ea7905ae213

Branch_6x (ed3b268d62f23e212c410cb35aa4318afa088f55)
https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=commit;h=ed3b268d62f23e212c410cb35aa4318afa088f55

> Logs backed up on restart are kept forever
> --
>
> Key: SOLR-9570
> URL: https://issues.apache.org/jira/browse/SOLR-9570
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>  Labels: logging
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-8370.patch
>
>
> When (re)starting Solr, the start script will backup any existing 
> {{solr.log}} or {{solr_gc.log}} to a file {{solr_log_}} and 
> {{solr_gc_log_}} respectively. That may be all good, but these old 
> copies are never cleaned up, as they are not under the control of log4j.
> This issue will instead rotate solr.log properly on startup, delete old 
> time-stamped files taking up place, back up (one generation only) of 
> console-log and solr_gc.log in $SOLR_LOGS_DIR/archived/.



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

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

Re: [jira] [Commented] (SOLR-9399) Delete requests do not send credentials & fails for Basic Authentication

[Susheel Kumar]

Sure, let me look into the tests.

On Thu, Oct 20, 2016 at 9:06 AM, ASF GitHub Bot (JIRA) 
wrote:

>
> [ https://issues.apache.org/jira/browse/SOLR-9399?page=
> com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel=15591769#comment-15591769 ]
>
> ASF GitHub Bot commented on SOLR-9399:
> --
>
> Github user romseygeek commented on the issue:
>
> https://github.com/apache/lucene-solr/pull/69
>
> Hi,
>
> BasicAuthIntegrationTest has been refactored since you opened this
> request, do you think you could try adding a test case in there now?
>
>
> > Delete requests do not send credentials & fails for Basic Authentication
> > 
> >
> > Key: SOLR-9399
> > URL: https://issues.apache.org/jira/browse/SOLR-9399
> > Project: Solr
> >  Issue Type: Bug
> >  Security Level: Public(Default Security Level. Issues are Public)
> >  Components: SolrJ
> >Affects Versions: 6.0, 6.0.1, 6.x
> >Reporter: Susheel Kumar
> >  Labels: security
> >
> > The getRoutes(..) func of UpdateRequest do not pass credentials to
> LBHttpSolrClient when deleteById is set while for updates it passes the
> credentials.  See below code snippet
> >   if (deleteById != null) {
> >
> >   Iterator>> entries =
> deleteById.entrySet()
> >   .iterator();
> >   while (entries.hasNext()) {
> >
> > Map.Entry> entry = entries.next();
> >
> > String deleteId = entry.getKey();
> > Map map = entry.getValue();
> > Long version = null;
> > if (map != null) {
> >   version = (Long) map.get(VER);
> > }
> > Slice slice = router.getTargetSlice(deleteId, null, null, null,
> col);
> > if (slice == null) {
> >   return null;
> > }
> > List urls = urlMap.get(slice.getName());
> > if (urls == null) {
> >   return null;
> > }
> > String leaderUrl = urls.get(0);
> > LBHttpSolrClient.Req request = routes.get(leaderUrl);
> > if (request != null) {
> >   UpdateRequest urequest = (UpdateRequest) request.getRequest();
> >   urequest.deleteById(deleteId, version);
> > } else {
> >   UpdateRequest urequest = new UpdateRequest();
> >   urequest.setParams(params);
> >   urequest.deleteById(deleteId, version);
> >   urequest.setCommitWithin(getCommitWithin());
> >   request = new LBHttpSolrClient.Req(urequest, urls);
> >   routes.put(leaderUrl, request);
> > }
> >   }
> > }
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Comment Edited] (SOLR-9665) Facet Values Sort Order: Add 3rd choice: Numeric Sort

[David Smiley (JIRA)]

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

David Smiley edited comment on SOLR-9665 at 10/20/16 1:30 PM:
--

Can you use Solr's EnumField?  If so; that'd do it.  But it's a solution that 
requires declaring manually up front what the values are -- it's not 
dynamic/automatic.


was (Author: dsmiley):
Can you use Solr's EnumField?  If so; that'd do it.  But it's a solution that 
requires declaring manually up front what the values are -- it's not generic.

> Facet Values Sort Order: Add 3rd choice: Numeric Sort
> -
>
> Key: SOLR-9665
> URL: https://issues.apache.org/jira/browse/SOLR-9665
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: faceting
>Reporter: Luke P Warwick
>
> As a person, I need facet values to be in predictable, intuitive spots so 
> that I can quickly and easily find the values that are appropriate to me.
> Problem Statement: Today Solr has two default facet sort orders, neither of 
> which provides predictable, intuitive facet value orders for people when the 
> values start with numbers.  
> Goal: Address the problem where index sorts facet values how a computer would 
> rather than how a human would.  This is very problematic for E-commerce 
> facets like 'size' and 'tire width'
> Acceptance Criteria:
> 1. Sorts facet values numerically from lowest to highest
> 2. Works with both numeric and string fields (thus working on values that 
> include letters... 25 mm, 30 waist, 32 Waist, 4 Petite)
> 3. If facet values don't start with a number, they are sorted alphabetically, 
> after all values that do start with a number
> 4. If facet values are equal numerically, sort the numerically equal values 
> alphabetically. Example: 10,10 Petite,10 Tall,12, Petite, 12 Tall
> 5. Integers and Floats are supported (even if string field)
> Examples:
> Women's Pants Sizes:
> 8
> 8 Tall
> 10
> 10 Petite
> 10 Tall
> 12
> 12 Tall
> 14 Petite
> 26 Waist
> 28 Waist
> 30 Waist
> One Size
> Bike Wheel Sizes:
> 20 Inches
> 24 Inches
> 26 Inches
> 27 Inches
> 27.5 Inches
> 27.5+ Inches
> 29 Inches
> 650c
> 700c



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

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

[jira] [Commented] (SOLR-9665) Facet Values Sort Order: Add 3rd choice: Numeric Sort

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9665:


Can you use Solr's EnumField?  If so; that'd do it.  But it's a solution that 
requires declaring manually up front what the values are -- it's not generic.

> Facet Values Sort Order: Add 3rd choice: Numeric Sort
> -
>
> Key: SOLR-9665
> URL: https://issues.apache.org/jira/browse/SOLR-9665
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: faceting
>Reporter: Luke P Warwick
>
> As a person, I need facet values to be in predictable, intuitive spots so 
> that I can quickly and easily find the values that are appropriate to me.
> Problem Statement: Today Solr has two default facet sort orders, neither of 
> which provides predictable, intuitive facet value orders for people when the 
> values start with numbers.  
> Goal: Address the problem where index sorts facet values how a computer would 
> rather than how a human would.  This is very problematic for E-commerce 
> facets like 'size' and 'tire width'
> Acceptance Criteria:
> 1. Sorts facet values numerically from lowest to highest
> 2. Works with both numeric and string fields (thus working on values that 
> include letters... 25 mm, 30 waist, 32 Waist, 4 Petite)
> 3. If facet values don't start with a number, they are sorted alphabetically, 
> after all values that do start with a number
> 4. If facet values are equal numerically, sort the numerically equal values 
> alphabetically. Example: 10,10 Petite,10 Tall,12, Petite, 12 Tall
> 5. Integers and Floats are supported (even if string field)
> Examples:
> Women's Pants Sizes:
> 8
> 8 Tall
> 10
> 10 Petite
> 10 Tall
> 12
> 12 Tall
> 14 Petite
> 26 Waist
> 28 Waist
> 30 Waist
> One Size
> Bike Wheel Sizes:
> 20 Inches
> 24 Inches
> 26 Inches
> 27 Inches
> 27.5 Inches
> 27.5+ Inches
> 29 Inches
> 650c
> 700c



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

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

[jira] [Created] (LUCENE-7511) TestGeo3DPoint.testGeo3DRelations() failure: invalid hits for shape=GeoRectangle

[Steve Rowe (JIRA)]

Steve Rowe created LUCENE-7511:
--

 Summary: TestGeo3DPoint.testGeo3DRelations() failure: invalid hits 
for shape=GeoRectangle
 Key: LUCENE-7511
 URL: https://issues.apache.org/jira/browse/LUCENE-7511
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Steve Rowe


Policeman Jenkins found a seed 
[https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1989/], that reproduces 
for me with Java8 on Linux, both on master and on branch_6x:

{noformat}
   [junit4] Suite: org.apache.lucene.spatial3d.TestGeo3DPoint
   [junit4] IGNOR/A 0.01s J1 | TestGeo3DPoint.testRandomBig
   [junit4]> Assumption #1: 'nightly' test group is disabled (@Nightly())
   [junit4]   1> doc=23 should match but did not
   [junit4]   1>   point=[X=-0.3032237416849336, Y=2.3309121299774915E-10, 
Z=-0.9508945608073219]
   [junit4]   1>   mappedPoint=[lat=-1.2621073061661279, 
lon=3.141592653589793([X=-0.3032237417663322, Y=3.7134198477962236E-17, 
Z=-0.9508945610068391])]
   [junit4]   1> doc=30 should match but did not
   [junit4]   1>   point=[X=-0.19482888783564378, Y=2.3309121299774915E-10, 
Z=-0.9786855487622393]
   [junit4]   1>   mappedPoint=[lat=-1.3742932353673953, 
lon=3.141592653589793([X=-0.1948288878124478, Y=2.3859657384095297E-17, 
Z=-0.9786855486360273])]
   [junit4]   1> doc=83 should match but did not
   [junit4]   1>   point=[X=-0.2892999513665818, Y=2.3309121299774915E-10, 
Z=-0.9551939133132278]
   [junit4]   1>   mappedPoint=[lat=-1.2767082336466407, 
lon=3.141592653589793([X=-0.2892999511883776, Y=3.5429025921633215E-17, 
Z=-0.9551939133776381])]
   [junit4]   1> doc=204 should match but did not
   [junit4]   1>   point=[X=-0.2304883857492458, Y=-2.3309121299774915E-10, 
Z=-0.970958461302852]
   [junit4]   1>   mappedPoint=[lat=-1.3377279126209909, 
lon=-3.141592653589793([X=-0.23048838553642823, Y=-2.8226686358782794E-17, 
Z=-0.9709584613946622])]
   [junit4]   1> doc=295 should match but did not
   [junit4]   1>   point=[X=-0.38044050228897974, Y=2.3309121299774915E-10, 
Z=-0.9229103565532143]
   [junit4]   1>   mappedPoint=[lat=-1.1798015420947494, 
lon=3.141592653589793([X=-0.38044050220203357, Y=4.6590524328773195E-17, 
Z=-0.9229103567469498])]
   [junit4]   1> doc=335 should match but did not
   [junit4]   1>   point=[X=-0.34552679276447196, Y=-2.3309121299774915E-10, 
Z=-0.9364507784902717]
   [junit4]   1>   mappedPoint=[lat=-1.2173184081667363, 
lon=-3.141592653589793([X=-0.3455267925813584, Y=-4.2314828055441195E-17, 
Z=-0.9364507786023997])]
   [junit4]   1> doc=444 should match but did not
   [junit4]   1>   point=[X=-0.35565273191587166, Y=2.3309121299774915E-10, 
Z=-0.9326775916369318]
   [junit4]   1>   mappedPoint=[lat=-1.2064925301928429, 
lon=3.141592653589793([X=-0.35565273187036933, Y=4.355489796930597E-17, 
Z=-0.9326775917892445])]
   [junit4]   1> doc=456 should match but did not
   [junit4]   1>   point=[X=-0.24059621278103072, Y=2.3309121299774915E-10, 
Z=-0.9685197822476396]
   [junit4]   1>   mappedPoint=[lat=-1.3273086505286442, 
lon=3.141592653589793([X=-0.24059621266986583, Y=2.9464538173312706E-17, 
Z=-0.9685197820947206])]
   [junit4]   1> doc=749 should match but did not
   [junit4]   1>   point=[X=-0.27931563097728074, Y=2.3309121299774915E-10, 
Z=-0.9581412458781736]
   [junit4]   1>   mappedPoint=[lat=-1.2871390311991375, 
lon=3.141592653589793([X=-0.27931563076181104, Y=3.420629931642758E-17, 
Z=-0.9581412457046323])]
   [junit4]   1> doc=978 should match but did not
   [junit4]   1>   point=[X=-0.20014590305820745, Y=-2.3309121299774915E-10, 
Z=-0.9776192380446992]
   [junit4]   1>   mappedPoint=[lat=-1.3688589001639526, 
lon=-3.141592653589793([X=-0.20014590297436863, Y=-2.4510803944001724E-17, 
Z=-0.9776192382200114])]
   [junit4]   1> doc=1019 should match but did not
   [junit4]   1>   point=[X=-0.1895701514767011, Y=-2.3309121299774915E-10, 
Z=-0.9797108368248392]
   [junit4]   1>   mappedPoint=[lat=-1.3796623403968673, 
lon=-3.141592653589793([X=-0.18957015125823026, Y=-2.3215647895227127E-17, 
Z=-0.9797108369364872])]
   [junit4]   1> doc=1050 should match but did not
   [junit4]   1>   point=[X=-0.37669388969865125, Y=-2.3309121299774915E-10, 
Z=-0.9244356257338767]
   [junit4]   1>   mappedPoint=[lat=-1.1838538424170673, 
lon=-3.141592653589793([X=-0.37669388956862926, Y=-4.613169661185884E-17, 
Z=-0.9244356256615374])]
   [junit4]   1> doc=1077 should match but did not
   [junit4]   1>   point=[X=-0.281464835919801, Y=-2.3309121299774915E-10, 
Z=-0.9575163092226472]
   [junit4]   1>   mappedPoint=[lat=-1.2848963877296418, 
lon=-3.141592653589793([X=-0.2814648357291603, Y=-3.4469501014825175E-17, 
Z=-0.957516309437251])]
   [junit4]   1> doc=1087 should match but did not
   [junit4]   1>   point=[X=-0.22993880934761124, Y=-2.3309121299774915E-10, 
Z=-0.9710878847326866]
   [junit4]   1>   mappedPoint=[lat=-1.3382936874912785, 

[jira] [Updated] (LUCENE-7462) Faster search APIs for doc values

[Adrien Grand (JIRA)]

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

Adrien Grand updated LUCENE-7462:
-
Attachment: LUCENE-7462.patch

Here is a patch that tries to implement this advanceExact method on all codecs. 
Initially I wanted to require that the target is strictly greater than the 
current doc id but this caused issues with comparators that may need to get the 
value multiple times or with scorers that call Scorer.score() multiple times 
(which makes the norm be decoded twice). So the current patch only requires 
that the target is greater than or equal to the current document. I managed to 
get the whole test suite passing twice in a row and luceneutil still gives 
results that are similar to above.

> Faster search APIs for doc values
> -
>
> Key: LUCENE-7462
> URL: https://issues.apache.org/jira/browse/LUCENE-7462
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: master (7.0)
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7462-advanceExact.patch, LUCENE-7462.patch
>
>
> While the iterator API helps deal with sparse doc values more efficiently, it 
> also makes search-time operations more costly. For instance, the old 
> random-access API allowed to compute facets on a given segment without any 
> conditionals, by just incrementing the counter at index {{ordinal+1}} while 
> the new API requires to advance the iterator if necessary and then check 
> whether it is exactly on the right document or not.
> Since it is very common for fields to exist across most documents, I suspect 
> codecs will keep an internal structure that is similar to the current codec 
> in the dense case, by having a dense representation of the data and just 
> making the iterator skip over the minority of documents that do not have a 
> value.
> I suggest that we add APIs that make things cheaper at search time. For 
> instance in the case of SORTED doc values, it could look like 
> {{LegacySortedDocValues}} with the additional restriction that documents can 
> only be consumed in order. Codecs that can implement this API efficiently 
> would hide it behind a {{SortedDocValues}} adapter, and then at search time 
> facets and comparators (which liked the {{LegacySortedDocValues}} API better) 
> would either unwrap or hide the SortedDocValues they got behind a more 
> random-access API (which would only happen in the truly sparse case if the 
> codec optimizes the dense case).
> One challenge is that we already use the same idea for hiding single-valued 
> impls behind multi-valued impls, so we would need to enforce the order in 
> which the wrapping needs to happen. At first sight, it seems that it would be 
> best to do the single-value-behind-multi-value-API wrapping above the 
> random-access-behind-iterator-API wrapping. The complexity of 
> wrapping/unwrapping in the right order could be contained in the 
> {{DocValues}} helper class.
> I think this change would also simplify search-time consumption of doc 
> values, which currently needs to spend several lines of code positioning the 
> iterator everytime it needs to do something interesting with doc values.



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

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

[jira] [Updated] (SOLR-9570) Logs backed up on restart are kept forever

[JIRA]

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

Jan Høydahl updated SOLR-9570:
--
Description: 
When (re)starting Solr, the start script will backup any existing {{solr.log}} 
or {{solr_gc.log}} to a file {{solr_log_}} and {{solr_gc_log_}} 
respectively. That may be all good, but these old copies are never cleaned up, 
as they are not under the control of log4j.
This issue will instead rotate solr.log properly on startup, delete old 
time-stamped files taking up place, back up (one generation only) of 
console-log and solr_gc.log in $SOLR_LOGS_DIR/archived/.

  was:When (re)starting Solr, the start script will backup any existing 
{{solr.log}} or {{solr_gc.log}} to a file {{solr_log_}} and 
{{solr_gc_log_}} respectively. That may be all good, but these old copies 
are never cleaned up, as they are not under the control of log4j.


> Logs backed up on restart are kept forever
> --
>
> Key: SOLR-9570
> URL: https://issues.apache.org/jira/browse/SOLR-9570
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>  Labels: logging
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-8370.patch
>
>
> When (re)starting Solr, the start script will backup any existing 
> {{solr.log}} or {{solr_gc.log}} to a file {{solr_log_}} and 
> {{solr_gc_log_}} respectively. That may be all good, but these old 
> copies are never cleaned up, as they are not under the control of log4j.
> This issue will instead rotate solr.log properly on startup, delete old 
> time-stamped files taking up place, back up (one generation only) of 
> console-log and solr_gc.log in $SOLR_LOGS_DIR/archived/.



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

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

[jira] [Commented] (SOLR-9399) Delete requests do not send credentials & fails for Basic Authentication

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-9399:
--

Github user romseygeek commented on the issue:

https://github.com/apache/lucene-solr/pull/69
  
Hi,

BasicAuthIntegrationTest has been refactored since you opened this request, 
do you think you could try adding a test case in there now?


> Delete requests do not send credentials & fails for Basic Authentication
> 
>
> Key: SOLR-9399
> URL: https://issues.apache.org/jira/browse/SOLR-9399
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 6.0, 6.0.1, 6.x
>Reporter: Susheel Kumar
>  Labels: security
>
> The getRoutes(..) func of UpdateRequest do not pass credentials to 
> LBHttpSolrClient when deleteById is set while for updates it passes the 
> credentials.  See below code snippet
>   if (deleteById != null) {
>   
>   Iterator>> entries = 
> deleteById.entrySet()
>   .iterator();
>   while (entries.hasNext()) {
> 
> Map.Entry> entry = entries.next();
> 
> String deleteId = entry.getKey();
> Map map = entry.getValue();
> Long version = null;
> if (map != null) {
>   version = (Long) map.get(VER);
> }
> Slice slice = router.getTargetSlice(deleteId, null, null, null, col);
> if (slice == null) {
>   return null;
> }
> List urls = urlMap.get(slice.getName());
> if (urls == null) {
>   return null;
> }
> String leaderUrl = urls.get(0);
> LBHttpSolrClient.Req request = routes.get(leaderUrl);
> if (request != null) {
>   UpdateRequest urequest = (UpdateRequest) request.getRequest();
>   urequest.deleteById(deleteId, version);
> } else {
>   UpdateRequest urequest = new UpdateRequest();
>   urequest.setParams(params);
>   urequest.deleteById(deleteId, version);
>   urequest.setCommitWithin(getCommitWithin());
>   request = new LBHttpSolrClient.Req(urequest, urls);
>   routes.put(leaderUrl, request);
> }
>   }
> }



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

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

[GitHub] lucene-solr issue #69: SOLR-9399: Delete requests do not send credentials & ...

[romseygeek]

Github user romseygeek commented on the issue:

https://github.com/apache/lucene-solr/pull/69
  
Hi,

BasicAuthIntegrationTest has been refactored since you opened this request, 
do you think you could try adding a test case in there now?


---
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] (SOLR-9399) Delete requests do not send credentials & fails for Basic Authentication

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-9399:
--

Github user susheelks commented on the issue:

https://github.com/apache/lucene-solr/pull/69
  
Hello,

Can this pull request be merged and committed that it can be part of Solr 
6.3 release.  This is a simple one line addition to pass auth credentials 
during a delete request on SolrJ side. If this has already been merged, can we 
close this JIRA.

Thanks,
Susheel


> Delete requests do not send credentials & fails for Basic Authentication
> 
>
> Key: SOLR-9399
> URL: https://issues.apache.org/jira/browse/SOLR-9399
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 6.0, 6.0.1, 6.x
>Reporter: Susheel Kumar
>  Labels: security
>
> The getRoutes(..) func of UpdateRequest do not pass credentials to 
> LBHttpSolrClient when deleteById is set while for updates it passes the 
> credentials.  See below code snippet
>   if (deleteById != null) {
>   
>   Iterator>> entries = 
> deleteById.entrySet()
>   .iterator();
>   while (entries.hasNext()) {
> 
> Map.Entry> entry = entries.next();
> 
> String deleteId = entry.getKey();
> Map map = entry.getValue();
> Long version = null;
> if (map != null) {
>   version = (Long) map.get(VER);
> }
> Slice slice = router.getTargetSlice(deleteId, null, null, null, col);
> if (slice == null) {
>   return null;
> }
> List urls = urlMap.get(slice.getName());
> if (urls == null) {
>   return null;
> }
> String leaderUrl = urls.get(0);
> LBHttpSolrClient.Req request = routes.get(leaderUrl);
> if (request != null) {
>   UpdateRequest urequest = (UpdateRequest) request.getRequest();
>   urequest.deleteById(deleteId, version);
> } else {
>   UpdateRequest urequest = new UpdateRequest();
>   urequest.setParams(params);
>   urequest.deleteById(deleteId, version);
>   urequest.setCommitWithin(getCommitWithin());
>   request = new LBHttpSolrClient.Req(urequest, urls);
>   routes.put(leaderUrl, request);
> }
>   }
> }



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

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

[GitHub] lucene-solr issue #69: SOLR-9399: Delete requests do not send credentials & ...

[susheelks]

Github user susheelks commented on the issue:

https://github.com/apache/lucene-solr/pull/69
  
Hello,

Can this pull request be merged and committed that it can be part of Solr 
6.3 release.  This is a simple one line addition to pass auth credentials 
during a delete request on SolrJ side. If this has already been merged, can we 
close this JIRA.

Thanks,
Susheel


---
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-7496) Better toString for SweetSpotSimilarity

[ASF subversion and git services (JIRA)]

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

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

Commit 22b0d5f4d21acaa3a28da5dec0654ecf102198c3 in lucene-solr's branch 
refs/heads/branch_6x from [~janhoy]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=22b0d5f ]

LUCENE-7496: Better toString for SweetSpotSimilarity

(cherry picked from commit c4b4830)


> Better toString for SweetSpotSimilarity
> ---
>
> Key: LUCENE-7496
> URL: https://issues.apache.org/jira/browse/LUCENE-7496
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: master (7.0), 6.3
>
> Attachments: LUCENE-7496.patch
>
>
> Spinoff from SOLR-8370 where we display Similarity class in use in the Admin 
> UI.
> SweetSpotSimilarity does not provide a {{toString}} method, so it will 
> incorreclty print {{ClassicSimilarity}}.



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

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

[jira] [Resolved] (LUCENE-7496) Better toString for SweetSpotSimilarity

[JIRA]

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

Jan Høydahl resolved LUCENE-7496.
-
Resolution: Fixed

> Better toString for SweetSpotSimilarity
> ---
>
> Key: LUCENE-7496
> URL: https://issues.apache.org/jira/browse/LUCENE-7496
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: master (7.0), 6.3
>
> Attachments: LUCENE-7496.patch
>
>
> Spinoff from SOLR-8370 where we display Similarity class in use in the Admin 
> UI.
> SweetSpotSimilarity does not provide a {{toString}} method, so it will 
> incorreclty print {{ClassicSimilarity}}.



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

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

[jira] [Commented] (LUCENE-7496) Better toString for SweetSpotSimilarity

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7496: Better toString for SweetSpotSimilarity


> Better toString for SweetSpotSimilarity
> ---
>
> Key: LUCENE-7496
> URL: https://issues.apache.org/jira/browse/LUCENE-7496
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: master (7.0), 6.3
>
> Attachments: LUCENE-7496.patch
>
>
> Spinoff from SOLR-8370 where we display Similarity class in use in the Admin 
> UI.
> SweetSpotSimilarity does not provide a {{toString}} method, so it will 
> incorreclty print {{ClassicSimilarity}}.



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

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

[jira] [Resolved] (SOLR-8370) Display Similarity Factory in use in Schema-Browser

[JIRA]

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

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

> Display Similarity Factory in use in Schema-Browser
> ---
>
> Key: SOLR-8370
> URL: https://issues.apache.org/jira/browse/SOLR-8370
> Project: Solr
>  Issue Type: Improvement
>  Components: UI
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Trivial
>  Labels: newdev
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-8370.patch, SOLR-8370.patch, SOLR-8370.patch, 
> SOLR-8370.patch, SOLR-8370.patch, SOLR-8370.patch, SOLR-8370.patch, 
> SOLR-8370.patch, screenshot-1.png, screenshot-2.png, screenshot-3.png, 
> screenshot-4.png, screenshot-5.png, screenshot-6.png
>
>
> Perhaps the Admin UI Schema browser should also display which 
> {{}} that is in use in schema, like it does per-field.



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

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

[jira] [Commented] (SOLR-8370) Display Similarity Factory in use in Schema-Browser

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8370: Display configured Similarity in Schema-Browser

(cherry picked from commit 14b6d93)


> Display Similarity Factory in use in Schema-Browser
> ---
>
> Key: SOLR-8370
> URL: https://issues.apache.org/jira/browse/SOLR-8370
> Project: Solr
>  Issue Type: Improvement
>  Components: UI
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Trivial
>  Labels: newdev
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-8370.patch, SOLR-8370.patch, SOLR-8370.patch, 
> SOLR-8370.patch, SOLR-8370.patch, SOLR-8370.patch, SOLR-8370.patch, 
> SOLR-8370.patch, screenshot-1.png, screenshot-2.png, screenshot-3.png, 
> screenshot-4.png, screenshot-5.png, screenshot-6.png
>
>
> Perhaps the Admin UI Schema browser should also display which 
> {{}} that is in use in schema, like it does per-field.



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

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

[jira] [Commented] (SOLR-8370) Display Similarity Factory in use in Schema-Browser

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8370: Display configured Similarity in Schema-Browser


> Display Similarity Factory in use in Schema-Browser
> ---
>
> Key: SOLR-8370
> URL: https://issues.apache.org/jira/browse/SOLR-8370
> Project: Solr
>  Issue Type: Improvement
>  Components: UI
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Trivial
>  Labels: newdev
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-8370.patch, SOLR-8370.patch, SOLR-8370.patch, 
> SOLR-8370.patch, SOLR-8370.patch, SOLR-8370.patch, SOLR-8370.patch, 
> SOLR-8370.patch, screenshot-1.png, screenshot-2.png, screenshot-3.png, 
> screenshot-4.png, screenshot-5.png, screenshot-6.png
>
>
> Perhaps the Admin UI Schema browser should also display which 
> {{}} that is in use in schema, like it does per-field.



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

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

[JENKINS-EA] Lucene-Solr-6.x-Linux (64bit/jdk-9-ea+140) - Build # 1994 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1994/
Java: 64bit/jdk-9-ea+140 -XX:-UseCompressedOops -XX:+UseG1GC

5 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestMiniSolrCloudCluster

Error Message:
7441 threads leaked from SUITE scope at 
org.apache.solr.cloud.TestMiniSolrCloudCluster: 1) Thread[id=5855, 
name=qtp235364240-5855, state=TIMED_WAITING, 
group=TGRP-TestMiniSolrCloudCluster] at 
jdk.internal.misc.Unsafe.park(java.base@9-ea/Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(java.base@9-ea/LockSupport.java:232)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base@9-ea/AbstractQueuedSynchronizer.java:2104)
 at 
org.eclipse.jetty.util.BlockingArrayQueue.poll(BlockingArrayQueue.java:392) 
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.idleJobPoll(QueuedThreadPool.java:546)
 at 
org.eclipse.jetty.util.thread.QueuedThreadPool.access$800(QueuedThreadPool.java:47)
 at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:609) 
at java.lang.Thread.run(java.base@9-ea/Thread.java:843)2) 
Thread[id=3994, name=qtp1915946497-3994, state=WAITING, 
group=TGRP-TestMiniSolrCloudCluster] at 
jdk.internal.misc.Unsafe.park(java.base@9-ea/Native Method) at 
java.util.concurrent.locks.LockSupport.park(java.base@9-ea/LockSupport.java:192)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@9-ea/AbstractQueuedSynchronizer.java:871)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(java.base@9-ea/AbstractQueuedSynchronizer.java:903)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base@9-ea/AbstractQueuedSynchronizer.java:2109)
 at 
org.eclipse.jetty.util.BlockingArrayQueue.poll(BlockingArrayQueue.java:392) 
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.idleJobPoll(QueuedThreadPool.java:546)
 at 
org.eclipse.jetty.util.thread.QueuedThreadPool.access$800(QueuedThreadPool.java:47)
 at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:609) 
at java.lang.Thread.run(java.base@9-ea/Thread.java:843)3) 
Thread[id=4802, name=qtp1915946497-4802, state=WAITING, 
group=TGRP-TestMiniSolrCloudCluster] at 
jdk.internal.misc.Unsafe.park(java.base@9-ea/Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(java.base@9-ea/LockSupport.java:232)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base@9-ea/AbstractQueuedSynchronizer.java:2104)
 at 
org.eclipse.jetty.util.BlockingArrayQueue.poll(BlockingArrayQueue.java:392) 
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.idleJobPoll(QueuedThreadPool.java:546)
 at 
org.eclipse.jetty.util.thread.QueuedThreadPool.access$800(QueuedThreadPool.java:47)
 at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:609) 
at java.lang.Thread.run(java.base@9-ea/Thread.java:843)4) 
Thread[id=4457, name=qtp235364240-4457, state=WAITING, 
group=TGRP-TestMiniSolrCloudCluster] at 
jdk.internal.misc.Unsafe.park(java.base@9-ea/Native Method) at 
java.util.concurrent.locks.LockSupport.park(java.base@9-ea/LockSupport.java:192)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@9-ea/AbstractQueuedSynchronizer.java:871)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(java.base@9-ea/AbstractQueuedSynchronizer.java:903)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base@9-ea/AbstractQueuedSynchronizer.java:2109)
 at 
org.eclipse.jetty.util.BlockingArrayQueue.poll(BlockingArrayQueue.java:392) 
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.idleJobPoll(QueuedThreadPool.java:546)
 at 
org.eclipse.jetty.util.thread.QueuedThreadPool.access$800(QueuedThreadPool.java:47)
 at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:609) 
at java.lang.Thread.run(java.base@9-ea/Thread.java:843)5) 
Thread[id=9748, name=qtp1915946497-9748, state=WAITING, 
group=TGRP-TestMiniSolrCloudCluster] at 
jdk.internal.misc.Unsafe.park(java.base@9-ea/Native Method) at 
java.util.concurrent.locks.LockSupport.park(java.base@9-ea/LockSupport.java:192)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@9-ea/AbstractQueuedSynchronizer.java:871)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(java.base@9-ea/AbstractQueuedSynchronizer.java:903)
 at 

[JENKINS] Lucene-Solr-6.x-Windows (64bit/jdk1.8.0_102) - Build # 528 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/528/
Java: 64bit/jdk1.8.0_102 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

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

Error Message:
Captured an uncaught exception in thread: Thread[id=11700, 
name=SocketProxy-Request-55060:54538, state=RUNNABLE, 
group=TGRP-HttpPartitionTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=11700, name=SocketProxy-Request-55060:54538, 
state=RUNNABLE, group=TGRP-HttpPartitionTest]
Caused by: java.lang.RuntimeException: java.net.SocketException: Socket is 
closed
at __randomizedtesting.SeedInfo.seed([9A7382D364BDF91E]:0)
at 
org.apache.solr.cloud.SocketProxy$Bridge$Pump.run(SocketProxy.java:347)
Caused by: java.net.SocketException: Socket is closed
at java.net.Socket.setSoTimeout(Socket.java:1137)
at 
org.apache.solr.cloud.SocketProxy$Bridge$Pump.run(SocketProxy.java:344)




Build Log:
[...truncated 11635 lines...]
   [junit4] Suite: org.apache.solr.cloud.HttpPartitionTest
   [junit4]   2> Creating dataDir: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.HttpPartitionTest_9A7382D364BDF91E-001\init-core-data-001
   [junit4]   2> 1910639 INFO  
(SUITE-HttpPartitionTest-seed#[9A7382D364BDF91E]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: 
@org.apache.solr.SolrTestCaseJ4$SuppressSSL(bugUrl=https://issues.apache.org/jira/browse/SOLR-5776)
   [junit4]   2> 1910639 INFO  
(SUITE-HttpPartitionTest-seed#[9A7382D364BDF91E]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /ag/
   [junit4]   2> 1910642 INFO  
(TEST-HttpPartitionTest.test-seed#[9A7382D364BDF91E]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 1910642 INFO  (Thread-2963) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 1910642 INFO  (Thread-2963) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 1910743 INFO  
(TEST-HttpPartitionTest.test-seed#[9A7382D364BDF91E]) [] 
o.a.s.c.ZkTestServer start zk server on port:54425
   [junit4]   2> 1910769 INFO  
(TEST-HttpPartitionTest.test-seed#[9A7382D364BDF91E]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\core\src\test-files\solr\collection1\conf\solrconfig-tlog.xml
 to /configs/conf1/solrconfig.xml
   [junit4]   2> 1910772 INFO  
(TEST-HttpPartitionTest.test-seed#[9A7382D364BDF91E]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\core\src\test-files\solr\collection1\conf\schema.xml
 to /configs/conf1/schema.xml
   [junit4]   2> 1910774 INFO  
(TEST-HttpPartitionTest.test-seed#[9A7382D364BDF91E]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\core\src\test-files\solr\collection1\conf\solrconfig.snippet.randomindexconfig.xml
 to /configs/conf1/solrconfig.snippet.randomindexconfig.xml
   [junit4]   2> 1910777 INFO  
(TEST-HttpPartitionTest.test-seed#[9A7382D364BDF91E]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\core\src\test-files\solr\collection1\conf\stopwords.txt
 to /configs/conf1/stopwords.txt
   [junit4]   2> 1910779 INFO  
(TEST-HttpPartitionTest.test-seed#[9A7382D364BDF91E]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\core\src\test-files\solr\collection1\conf\protwords.txt
 to /configs/conf1/protwords.txt
   [junit4]   2> 1910781 INFO  
(TEST-HttpPartitionTest.test-seed#[9A7382D364BDF91E]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\core\src\test-files\solr\collection1\conf\currency.xml
 to /configs/conf1/currency.xml
   [junit4]   2> 1910784 INFO  
(TEST-HttpPartitionTest.test-seed#[9A7382D364BDF91E]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\core\src\test-files\solr\collection1\conf\enumsConfig.xml
 to /configs/conf1/enumsConfig.xml
   [junit4]   2> 1910786 INFO  
(TEST-HttpPartitionTest.test-seed#[9A7382D364BDF91E]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\core\src\test-files\solr\collection1\conf\open-exchange-rates.json
 to /configs/conf1/open-exchange-rates.json
   [junit4]   2> 1910789 INFO  
(TEST-HttpPartitionTest.test-seed#[9A7382D364BDF91E]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\core\src\test-files\solr\collection1\conf\mapping-ISOLatin1Accent.txt
 to /configs/conf1/mapping-ISOLatin1Accent.txt
   [junit4]   2> 1910791 INFO  
(TEST-HttpPartitionTest.test-seed#[9A7382D364BDF91E]) [] 
o.a.s.c.AbstractZkTestCase put 

[jira] [Resolved] (LUCENE-7510) New index directory

[Alan Woodward (JIRA)]

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

Alan Woodward resolved LUCENE-7510.
---
Resolution: Not A Problem

This is better dealt with on the mailing list, as JIRA is supposed to be for 
bug reports or implementations rather than support requests.

There are some distributed Directory implementations out there (Infinispan had 
one a few years back), or you can front your distributed cache behind a java 
FileSystemProvider and just use FSDirectory.

> New index directory
> ---
>
> Key: LUCENE-7510
> URL: https://issues.apache.org/jira/browse/LUCENE-7510
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: core/index
>Affects Versions: 6.2.1
>Reporter: Dhwanit Gupta
>Priority: Minor
>
> Hi
> Currently Lucene gives functionality to write index on RAMDirectory or 
> FSDirectory, but I want to write index in Cache.
> To support writing index in cache, how should I proceed. I want to know how 
> to implement my own Directory where I can write and read index ?
> Thanks
> Dhwanit



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

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

[jira] [Commented] (LUCENE-7510) New index directory

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on LUCENE-7510:
--

One guy went a long way like that already 
https://web.archive.org/web/20110614234722/http://www.kimchy.org/the_future_of_compass/
 

> New index directory
> ---
>
> Key: LUCENE-7510
> URL: https://issues.apache.org/jira/browse/LUCENE-7510
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: core/index
>Affects Versions: 6.2.1
>Reporter: Dhwanit Gupta
>Priority: Minor
>
> Hi
> Currently Lucene gives functionality to write index on RAMDirectory or 
> FSDirectory, but I want to write index in Cache.
> To support writing index in cache, how should I proceed. I want to know how 
> to implement my own Directory where I can write and read index ?
> Thanks
> Dhwanit



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

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

[jira] [Commented] (LUCENE-7510) New index directory

[Dhwanit Gupta (JIRA)]

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

Dhwanit Gupta commented on LUCENE-7510:
---

I have distributed cache so instead of writing index in FileSystem at one host, 
I want to write in distributed cache.

> New index directory
> ---
>
> Key: LUCENE-7510
> URL: https://issues.apache.org/jira/browse/LUCENE-7510
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: core/index
>Affects Versions: 6.2.1
>Reporter: Dhwanit Gupta
>Priority: Minor
>
> Hi
> Currently Lucene gives functionality to write index on RAMDirectory or 
> FSDirectory, but I want to write index in Cache.
> To support writing index in cache, how should I proceed. I want to know how 
> to implement my own Directory where I can write and read index ?
> Thanks
> Dhwanit



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

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

[jira] [Commented] (SOLR-9647) CollectionsAPIDistributedZkTest got stuck, reproduces failure

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-9647:


Ok got it. I'll check the same edge cases after SOLR-9132 come in. Let me know 
how if can help you with SOLR-9132 

> CollectionsAPIDistributedZkTest got stuck, reproduces failure
> -
>
> Key: SOLR-9647
> URL: https://issues.apache.org/jira/browse/SOLR-9647
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
> Attachments: SOLR-9647.patch
>
>
>  I have to shoot 
> https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1129/ just 
> because "Took 1 day 12 hr on lucene".
>[junit4] HEARTBEAT J0 PID(30506@lucene1-us-west): 2016-10-15T00:08:30, 
> stalled for 48990s at: CollectionsAPIDistributedZkTest.test
>[junit4] HEARTBEAT J0 PID(30506@lucene1-us-west): 2016-10-15T00:09:30, 
> stalled for 49050s at: CollectionsAPIDistributedZkTest.test
>  It's just got stuck. Then I run it locally, it passes from Eclipse, but 
> fails when I run from cmd>ant. 



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

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

[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_102) - Build # 6192 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6192/
Java: 32bit/jdk1.8.0_102 -client -XX:+UseSerialGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail

Error Message:
expected:<200> but was:<404>

Stack Trace:
java.lang.AssertionError: expected:<200> but was:<404>
at 
__randomizedtesting.SeedInfo.seed([D1911DDC7F9499B1:B92E28F6AF0E8B5D]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.cancelDelegationToken(TestSolrCloudWithDelegationTokens.java:140)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail(TestSolrCloudWithDelegationTokens.java:294)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-9668) Support cursor paging in SolrEntityProcessor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-9668:
--

GitHub user YegorKozlov opened a pull request:

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

SOLR-9668 Support cursor paging in SolrEntityProcessor

SolrEntityProcessor paginates using the start and rows parameters which can 
be very inefficient at large offsets. In fact, the current implementation is 
impracticable to import large amounts of data (10M+ documents) because the data 
import rate degrades from 1000docs/second to 10docs/second and the import gets 
stuck.
This patch introduces support for cursor paging which offers more or less 
predictable performance. In my tests the time to fetch the 1st and 1000th pages 
was about the same and the data import rate was stable throughout the entire 
import.

To enable cursor paging a user needs to add a "sort" attribute in the 
entity configuration:
```xml


  
 
url="http://localhost:8983/solr/collection1;>

  

```
If the "sort" attribute is missing then the default start/rows pagination 
is used.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/YegorKozlov/lucene-solr SOLR-9668

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/101.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #101


commit 840dfe68895fabdc8ff5458b3f114a678d0dd080
Author: U-CEB\YKozlov 
Date:   2016-10-20T08:34:55Z

SOLR-9668 Support cursor paging in SolrEntityProcessor




> Support cursor paging in SolrEntityProcessor
> 
>
> Key: SOLR-9668
> URL: https://issues.apache.org/jira/browse/SOLR-9668
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler
>Reporter: Yegor Kozlov
>Priority: Minor
>  Labels: dataimportHandler
> Fix For: master (7.0)
>
>
> SolrEntityProcessor paginates using the start and rows parameters which can 
> be very inefficient at large offsets. In fact, the current implementation  is 
> impracticable to import large amounts of data (10M+ documents) because the 
> data import rate degrades from 1000docs/second to 10docs/second and the 
> import gets stuck.
> This patch introduces support for cursor paging which offers more or less 
> predictable performance. In my tests the time to fetch the 1st and 1000th 
> pages was about the same and the data import rate was stable throughout the 
> entire import. 
> To enable cursor paging a user needs to add a "sort" attribute in the entity 
> configuration:
> {code}
> 
> 
>   
>  query="*:*"
> rows="1000"
> sort="id asc"   
> url="http://localhost:8983/solr/collection1;>
> 
>   
> 
> {code}
> If the "sort" attribute is missing then the default start/rows pagination is 
> used.



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

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