[jira] [Commented] (LUCENE-5644) ThreadAffinityDocumentsWriterThreadPool should clear the bindings on flush

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LUCENE-5644:


GitHub user vvdb opened a pull request:

https://github.com/apache/lucenenet/pull/208

LUCENE-5644: switch to simpler LIFO thread to ThreadState allocator d…

…uring indexing”. Technically, this is something from 
releases/lucene-solr/4.8.1, but profiling indicates it makes a huge difference 
in multithreaded scenarios

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

$ git pull https://github.com/vvdb/lucenenet master

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

https://github.com/apache/lucenenet/pull/208.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 #208


commit 18b8ef71fc08c1583c323ff00e2d1ef07e55c72c
Author: Vincent Van Den Berghe 
Date:   2017-06-13T05:50:31Z

LUCENE-5644: switch to simpler LIFO thread to ThreadState allocator during 
indexing”. Technically, this is something from releases/lucene-solr/4.8.1, but 
profiling indicates it makes a huge difference in multithreaded scenarios




> ThreadAffinityDocumentsWriterThreadPool should clear the bindings on flush
> --
>
> Key: LUCENE-5644
> URL: https://issues.apache.org/jira/browse/LUCENE-5644
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 4.8.1, 4.9, 6.0
>
> Attachments: LUCENE-5644.patch, LUCENE-5644.patch, LUCENE-5644.patch, 
> LUCENE-5644.patch, LUCENE-5644.patch
>
>
> This class remembers which thread used which DWPT, but it never clears
> this "affinity".  It really should clear it on flush, this way if the
> number of threads doing indexing has changed we only use as many DWPTs
> as there are incoming threads.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Better error message? (old version and new version are not comparable)

[S G]

Thanks Tomas,
I have read the contribution docs and also created a JIRA at
https://issues.apache.org/jira/browse/SOLR-10877
New PR is at https://github.com/apache/lucene-solr/pull/213
Please review the same.

-SG


On Mon, Jun 12, 2017 at 10:28 AM, Tomas Fernandez Lobbe 
wrote:

> Hi SG,
> You should create a Jira issue, then if you can rename your PR to include
> the Jira issue code in the title (that’s the way to link the Jira issue to
> the Github PR). Also, take a look at https://wiki.apache.org/
> solr/HowToContribute.
>
> Tomás
>
> On Jun 12, 2017, at 9:14 AM, S G  wrote:
>
> Hi Zheng,
>
> We are using 6.3 version.
> I have created a small PR that addresses this issue of better error
> message.
> Please merge the same if it looks ok.
> https://github.com/apache/lucene-solr/pull/212/files
>
> Thanks
> SG
>
>
> On Sun, Jun 11, 2017 at 8:45 PM, Zheng Lin Edwin Yeo  > wrote:
>
>> Which version of Solr are yo using?
>>
>> Also, I believe you should send this message to the user list at
>> solr-u...@lucene.apache.org
>>
>> Regards,
>> Edwin
>>
>> On 12 June 2017 at 02:45, S G  wrote:
>>
>>> Hi,
>>>
>>> Recently I ran into an issue where the logs were showing the following:
>>>
>>>
>>> org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error
>>> from server at http://solr-host:8983/solr/loadtest_shard1_replica1: old
>>> version and new version are not comparable: class java.lang.Long vs class
>>> java.lang.Integer: null
>>> at 
>>> org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:765)
>>> ~[load-client.jar]
>>> at 
>>> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1173)
>>> ~[load-client.jar]
>>> at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWit
>>> hRetryOnStaleState(CloudSolrClient.java:1062) ~[load-client.jar]
>>> at 
>>> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1004)
>>> ~[load-client.jar]
>>> at 
>>> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
>>> ~[load-client.jar]
>>> at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:106)
>>> ~[load-client.jar]
>>> at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:123)
>>> ~[load-client.jar]
>>> at WriteLoadTest$IndexWorker.addDocsToSolr(WriteLoadTest.java:629)
>>> [load-client.jar]
>>> at WriteLoadTest$IndexWorker.run(WriteLoadTest.java:573)
>>> [load-client.jar]
>>> Caused by: 
>>> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:
>>> Error from server at http://solr-host:8983/solr/loadtest_shard1_replica1:
>>> old version and new version are not comparable: class java.lang.Long vs
>>> class java.lang.Integer: null
>>> at 
>>> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:593)
>>> ~[load-client.jar]
>>> at 
>>> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
>>> ~[load-client.jar]
>>> at 
>>> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:251)
>>> ~[load-client.jar]
>>> at 
>>> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:435)
>>> ~[load-client.jar]
>>> at 
>>> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:387)
>>> ~[load-client.jar]
>>> at org.apache.solr.client.solrj.impl.CloudSolrClient.lambda$dir
>>> ectUpdate$0(CloudSolrClient.java:742) ~[load-client.jar]
>>> at 
>>> org.apache.solr.client.solrj.impl.CloudSolrClient$$Lambda$8/745780984.call(Unknown
>>> Source) ~[?:?]
>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>> ~[?:1.8.0_51]
>>> at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolE
>>> xecutor.lambda$execute$0(ExecutorUtil.java:229) ~[load-client.jar]
>>> at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolE
>>> xecutor$$Lambda$7/725894523.run(Unknown Source) ~[?:?]
>>> ... 3 more
>>>
>>>
>>> The message above is not clear at all.
>>> Which document is it talking about?
>>> I have so many documents being ingested and it's hard to figure out the
>>> same.
>>> It would have been nice if the message included a document ID too.
>>>
>>>
>>> Thanks
>>> SG
>>>
>>>
>>>
>>>
>>
>
>

[jira] [Commented] (SOLR-10877) Better error message instead of "old version and new version are not comparable"

[ASF GitHub Bot (JIRA)]

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

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

GitHub user sachingsachin opened a pull request:

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

SOLR-10877 More informative exceptions and log messages



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

$ git pull https://github.com/sachingsachin/lucene-solr fix_messages

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

https://github.com/apache/lucene-solr/pull/213.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 #213


commit a687a1312aa5c72b4d5514b37412ed3b46d7c2f2
Author: Sachin Goyal 
Date:   2017-06-10T23:29:30Z

More informative messages




> Better error message instead of "old version and new version are not 
> comparable"
> 
>
> Key: SOLR-10877
> URL: https://issues.apache.org/jira/browse/SOLR-10877
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.3, 6.5.1
>Reporter: Sachin Goyal
>
> I ran into an issue where the logs were showing the following:
> {color:darkred}
> org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
> server at http://solr-host:8983/solr/loadtest_shard1_replica1: old version 
> and new version are not comparable: class java.lang.Long vs class 
> java.lang.Integer: null
> at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:765)
>  ~\[load-client.jar\]
> at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1173)
>  ~\[load-client.jar\]
> at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1062)
>  ~\[load-client.jar\]
> at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1004)
>  ~\[load-client.jar\]
> at 
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149) 
> ~\[load-client.jar\]
> at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:106) 
> ~\[load-client.jar\]
> at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:123) 
> ~\[load-client.jar\]
> at WriteLoadTest$IndexWorker.addDocsToSolr(WriteLoadTest.java:629) 
> \[load-client.jar\]
> at WriteLoadTest$IndexWorker.run(WriteLoadTest.java:573) 
> \[load-client.jar\]
> Caused by: 
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
> from server at http://solr-host:8983/solr/loadtest_shard1_replica1: old 
> version and new version are not comparable: class java.lang.Long vs class 
> java.lang.Integer: null
> at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:593)
>  ~\[load-client.jar\]
> at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
>  ~\[load-client.jar\]
> at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:251)
>  ~\[load-client.jar\]
> at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:435)
>  ~\[load-client.jar\]
> at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:387)
>  ~\[load-client.jar\]
> at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.lambda$directUpdate$0(CloudSolrClient.java:742)
>  ~\[load-client.jar\]
> at 
> org.apache.solr.client.solrj.impl.CloudSolrClient$$Lambda$8/745780984.call(Unknown
>  Source) ~\[?:?\]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~\[?:1.8.0_51\]
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
>  ~\[load-client.jar\]
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$$Lambda$7/725894523.run(Unknown
>  Source) ~\[?:?\]
> ... 3 more
> {color}
> The message above is not clear at all.
> Which document is it talking about?
> I have so many documents being ingested and it's hard to figure out the same.
> It would have been nice if the message included a document ID too.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[GitHub] lucene-solr pull request #213: SOLR-10877 More informative exceptions and lo...

[sachingsachin]

GitHub user sachingsachin opened a pull request:

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

SOLR-10877 More informative exceptions and log messages



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

$ git pull https://github.com/sachingsachin/lucene-solr fix_messages

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

https://github.com/apache/lucene-solr/pull/213.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 #213


commit a687a1312aa5c72b4d5514b37412ed3b46d7c2f2
Author: Sachin Goyal 
Date:   2017-06-10T23:29:30Z

More informative messages




---
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-10877) Better error message instead of "old version and new version are not comparable"

[ASF GitHub Bot (JIRA)]

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

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

Github user sachingsachin closed the pull request at:

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


> Better error message instead of "old version and new version are not 
> comparable"
> 
>
> Key: SOLR-10877
> URL: https://issues.apache.org/jira/browse/SOLR-10877
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.3, 6.5.1
>Reporter: Sachin Goyal
>
> I ran into an issue where the logs were showing the following:
> {color:darkred}
> org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
> server at http://solr-host:8983/solr/loadtest_shard1_replica1: old version 
> and new version are not comparable: class java.lang.Long vs class 
> java.lang.Integer: null
> at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:765)
>  ~\[load-client.jar\]
> at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1173)
>  ~\[load-client.jar\]
> at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1062)
>  ~\[load-client.jar\]
> at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1004)
>  ~\[load-client.jar\]
> at 
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149) 
> ~\[load-client.jar\]
> at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:106) 
> ~\[load-client.jar\]
> at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:123) 
> ~\[load-client.jar\]
> at WriteLoadTest$IndexWorker.addDocsToSolr(WriteLoadTest.java:629) 
> \[load-client.jar\]
> at WriteLoadTest$IndexWorker.run(WriteLoadTest.java:573) 
> \[load-client.jar\]
> Caused by: 
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
> from server at http://solr-host:8983/solr/loadtest_shard1_replica1: old 
> version and new version are not comparable: class java.lang.Long vs class 
> java.lang.Integer: null
> at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:593)
>  ~\[load-client.jar\]
> at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
>  ~\[load-client.jar\]
> at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:251)
>  ~\[load-client.jar\]
> at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:435)
>  ~\[load-client.jar\]
> at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:387)
>  ~\[load-client.jar\]
> at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.lambda$directUpdate$0(CloudSolrClient.java:742)
>  ~\[load-client.jar\]
> at 
> org.apache.solr.client.solrj.impl.CloudSolrClient$$Lambda$8/745780984.call(Unknown
>  Source) ~\[?:?\]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~\[?:1.8.0_51\]
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
>  ~\[load-client.jar\]
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$$Lambda$7/725894523.run(Unknown
>  Source) ~\[?:?\]
> ... 3 more
> {color}
> The message above is not clear at all.
> Which document is it talking about?
> I have so many documents being ingested and it's hard to figure out the same.
> It would have been nice if the message included a document ID too.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[GitHub] lucene-solr pull request #212: SOLR-10877: More informative messages

[sachingsachin]

Github user sachingsachin closed the pull request at:

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


---
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] [Created] (SOLR-10877) Better error message instead of "old version and new version are not comparable"

[Sachin Goyal (JIRA)]

Sachin Goyal created SOLR-10877:
---

 Summary: Better error message instead of "old version and new 
version are not comparable"
 Key: SOLR-10877
 URL: https://issues.apache.org/jira/browse/SOLR-10877
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.5.1, 6.3
Reporter: Sachin Goyal



I ran into an issue where the logs were showing the following:

{color:darkred}
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://solr-host:8983/solr/loadtest_shard1_replica1: old version and 
new version are not comparable: class java.lang.Long vs class 
java.lang.Integer: null
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:765)
 ~\[load-client.jar\]
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1173)
 ~\[load-client.jar\]
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1062)
 ~\[load-client.jar\]
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1004)
 ~\[load-client.jar\]
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149) 
~\[load-client.jar\]
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:106) 
~\[load-client.jar\]
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:123) 
~\[load-client.jar\]
at WriteLoadTest$IndexWorker.addDocsToSolr(WriteLoadTest.java:629) 
\[load-client.jar\]
at WriteLoadTest$IndexWorker.run(WriteLoadTest.java:573) 
\[load-client.jar\]

Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://solr-host:8983/solr/loadtest_shard1_replica1: old version 
and new version are not comparable: class java.lang.Long vs class 
java.lang.Integer: null
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:593)
 ~\[load-client.jar\]
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
 ~\[load-client.jar\]
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:251)
 ~\[load-client.jar\]
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:435)
 ~\[load-client.jar\]
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:387)
 ~\[load-client.jar\]
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.lambda$directUpdate$0(CloudSolrClient.java:742)
 ~\[load-client.jar\]
at 
org.apache.solr.client.solrj.impl.CloudSolrClient$$Lambda$8/745780984.call(Unknown
 Source) ~\[?:?\]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
~\[?:1.8.0_51\]
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
 ~\[load-client.jar\]
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$$Lambda$7/725894523.run(Unknown
 Source) ~\[?:?\]
... 3 more
{color}

The message above is not clear at all.
Which document is it talking about?
I have so many documents being ingested and it's hard to figure out the same.
It would have been nice if the message included a document ID too.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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 # 4069 - Still Unstable!

[Policeman Jenkins Server]

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

13 tests failed.
FAILED:  
org.apache.solr.cloud.DeleteInactiveReplicaTest.deleteInactiveReplicaTest

Error Message:
Deleted core was still loaded!

Stack Trace:
java.lang.AssertionError: Deleted core was still loaded!
at 
__randomizedtesting.SeedInfo.seed([705522DD54DD693F:BD6BB92E1B7C1FDD]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at 
org.apache.solr.cloud.DeleteInactiveReplicaTest.deleteInactiveReplicaTest(DeleteInactiveReplicaTest.java:86)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  org.apache.solr.core.BlobRepositoryMockingTest.testCloudOnly

Error Message:
 Mockito cannot mock this class: class org.apache.solr.core.CoreContainer.  
Mockito can only mock non-private & 

[jira] [Updated] (SOLR-10433) automatically map collection admi calls from V1 to V2

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-10433:
--
Attachment: SOLR-10433.patch

> automatically map collection admi calls from V1 to V2
> -
>
> Key: SOLR-10433
> URL: https://issues.apache.org/jira/browse/SOLR-10433
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ, v2 API
>Reporter: Noble Paul
> Attachments: SOLR-10433.patch, SOLR-10433.patch, SOLR-10433.patch
>
>
> There are some bugs in v2 api that I would like to solve in other tickets :
> - DELETE method doest not support body ( we can't pass async id )
> - V2HttpCall should {{override getAuthCtx()}} to support 
> {{RuleBasedAuthorizationPlugin}}
> - with create collection, when user send this request
> {code}
> {
> "properties" : {"solr.tests.maxBufferedDocs" : 100}
> }
> {code}
> the v2 api can not resolve the value for 
> "properties.solr.tests.maxBufferedDocs"



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10433) automatically map collection admin calls from V1 to V2

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-10433:
--
Component/s: SolrJ

> automatically map collection admin calls from V1 to V2
> --
>
> Key: SOLR-10433
> URL: https://issues.apache.org/jira/browse/SOLR-10433
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ, v2 API
>Reporter: Noble Paul
> Attachments: SOLR-10433.patch, SOLR-10433.patch, SOLR-10433.patch
>
>
> There are some bugs in v2 api that I would like to solve in other tickets :
> - DELETE method doest not support body ( we can't pass async id )
> - V2HttpCall should {{override getAuthCtx()}} to support 
> {{RuleBasedAuthorizationPlugin}}
> - with create collection, when user send this request
> {code}
> {
> "properties" : {"solr.tests.maxBufferedDocs" : 100}
> }
> {code}
> the v2 api can not resolve the value for 
> "properties.solr.tests.maxBufferedDocs"



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10433) automatically map collection admin calls from V1 to V2

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-10433:
--
Summary: automatically map collection admin calls from V1 to V2  (was: 
automatically map collection admi calls from V1 to V2)

> automatically map collection admin calls from V1 to V2
> --
>
> Key: SOLR-10433
> URL: https://issues.apache.org/jira/browse/SOLR-10433
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ, v2 API
>Reporter: Noble Paul
> Attachments: SOLR-10433.patch, SOLR-10433.patch, SOLR-10433.patch
>
>
> There are some bugs in v2 api that I would like to solve in other tickets :
> - DELETE method doest not support body ( we can't pass async id )
> - V2HttpCall should {{override getAuthCtx()}} to support 
> {{RuleBasedAuthorizationPlugin}}
> - with create collection, when user send this request
> {code}
> {
> "properties" : {"solr.tests.maxBufferedDocs" : 100}
> }
> {code}
> the v2 api can not resolve the value for 
> "properties.solr.tests.maxBufferedDocs"



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10433) automatically map collection admi calls from V1 to V2

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-10433:
--
Summary: automatically map collection admi calls from V1 to V2  (was: 
switch between v2 and v1 endpoints internally in SolrJ)

> automatically map collection admi calls from V1 to V2
> -
>
> Key: SOLR-10433
> URL: https://issues.apache.org/jira/browse/SOLR-10433
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: v2 API
>Reporter: Noble Paul
> Attachments: SOLR-10433.patch, SOLR-10433.patch
>
>
> There are some bugs in v2 api that I would like to solve in other tickets :
> - DELETE method doest not support body ( we can't pass async id )
> - V2HttpCall should {{override getAuthCtx()}} to support 
> {{RuleBasedAuthorizationPlugin}}
> - with create collection, when user send this request
> {code}
> {
> "properties" : {"solr.tests.maxBufferedDocs" : 100}
> }
> {code}
> the v2 api can not resolve the value for 
> "properties.solr.tests.maxBufferedDocs"



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19853/
Java: 32bit/jdk-9-ea+173 -client -XX:+UseG1GC

2 tests failed.
FAILED:  org.apache.solr.core.TestSolrConfigHandler.testReqParams

Error Message:
Could not get expected value  'CY val' for path 'params/c' full output: 
{"error":{ "trace":"java.lang.ClassCastException\n", "code":500}},  
from server:  null

Stack Trace:
java.lang.AssertionError: Could not get expected value  'CY val' for path 
'params/c' full output: {"error":{
"trace":"java.lang.ClassCastException\n",
"code":500}},  from server:  null
at 
__randomizedtesting.SeedInfo.seed([3BA9F726D117407A:4C85CF2F8684C497]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:556)
at 
org.apache.solr.core.TestSolrConfigHandler.testReqParams(TestSolrConfigHandler.java:665)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
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:368)
at 

[jira] [Updated] (SOLR-10876) Regression in loading runtime UpdateRequestProcessors

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-10876:
--
Attachment: SOLR-10876.patch

> Regression in loading runtime UpdateRequestProcessors
> -
>
> Key: SOLR-10876
> URL: https://issues.apache.org/jira/browse/SOLR-10876
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-10876.patch
>
>
> This was introduced as a part of SOLR-9530



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (SOLR-10876) Regression in loading runtime UpdateRequestProcessors

[Noble Paul (JIRA)]

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

Noble Paul reassigned SOLR-10876:
-

Assignee: Noble Paul

> Regression in loading runtime UpdateRequestProcessors
> -
>
> Key: SOLR-10876
> URL: https://issues.apache.org/jira/browse/SOLR-10876
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>
> This was introduced as a part of SOLR-9530



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-10876) Regression in loading runtime UpdateRequestProcessors

[Noble Paul (JIRA)]

Noble Paul created SOLR-10876:
-

 Summary: Regression in loading runtime UpdateRequestProcessors
 Key: SOLR-10876
 URL: https://issues.apache.org/jira/browse/SOLR-10876
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Noble Paul


This was introduced as a part of SOLR-9530



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-9565) Make every UpdateRequestProcessor available implicitly

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-9565:
--

look at {{SolrCore.getUpdateProcessorChain(SolrParams params)}} for relevant 
changes

This was added as part of SOLR-9657

> Make every UpdateRequestProcessor available implicitly
> --
>
> Key: SOLR-9565
> URL: https://issues.apache.org/jira/browse/SOLR-9565
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>
> Now that we can 'construct' the URP chains through request parameters, we 
> should make all the URPs available automatically. The next challenge is to 
> make them read the configuration from request parameters as well
> to access {{HTMLStripFieldUpdateProcessorFactory}} the parameter could be 
> {{processor=HTMLStripField}} (The UpdateProcessorFactory part is 
> automatically appended )
> The next step is to make the URPs accept request parameters instead of just 
> configuration parameters e.g: 
> {{processor=HTMLStripField=}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10869) Make StatelessScriptUpdateProcessorFactory as Runtime URP; take params(s) with request

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-10869:
-

Please check that we don't introduce new attack vectors.  i.e. "script.file" 
should only resolve to an existing script in conf/...

+1 to remove the "stateless" from the name!  I've hated that needless verbosity.

> Make StatelessScriptUpdateProcessorFactory as Runtime URP; take params(s) 
> with request
> --
>
> Key: SOLR-10869
> URL: https://issues.apache.org/jira/browse/SOLR-10869
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Reporter: Amrit Sarkar
>Priority: Minor
>
> We are trying to get rid of processor definitions in SolrConfig for all URPs 
> and take parameters in the request itself.
> StatelessScriptUpdateProcessorFactory will be able to execute by sample curl 
> like below:
> {code}
> curl -X POST -H Content-Type: application/json  
> http://localhost:8983/solr/test/update/json/docs?processor=StatelessScript=1.js=2.js=3.js=keyA:valueA=keyB:valueB=keyC:valueC=
>  rhino=true --data-binary { "id" : "1" , "title_s" : "title_random" }
> {code}
> All the param(s) for this URP available can be passed as request handler 
> param(s). The scripts will be executed in the order the parameters are 
> received.
> Configuration for StatelessScriptUpdateProcessorFactory in solrconfig.xml is 
> optional. Backcompat is intact.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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+173) - Build # 19852 - Unstable!

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.solr.core.TestSolrConfigHandler.testReqParams

Error Message:
Could not get expected value  'CY val' for path 'params/c' full output: 
{"error":{ "trace":"java.lang.ClassCastException\n", "code":500}},  
from server:  null

Stack Trace:
java.lang.AssertionError: Could not get expected value  'CY val' for path 
'params/c' full output: {"error":{
"trace":"java.lang.ClassCastException\n",
"code":500}},  from server:  null
at 
__randomizedtesting.SeedInfo.seed([BBAA2CC732211450:CC8614CE65B290BD]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:556)
at 
org.apache.solr.core.TestSolrConfigHandler.testReqParams(TestSolrConfigHandler.java:665)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[JENKINS-EA] Lucene-Solr-master-Windows (32bit/jdk-9-ea+173) - Build # 6643 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6643/
Java: 32bit/jdk-9-ea+173 -server -XX:+UseG1GC

2 tests failed.
FAILED:  org.apache.solr.core.TestSolrConfigHandler.testReqParams

Error Message:
Could not get expected value  'CY val' for path 'params/c' full output: {   
"responseHeader":{ "status":500, "QTime":1},   "error":{ 
"msg":"java.base/[Ljava.lang.String; cannot be cast to 
java.base/java.lang.String", "trace":"java.lang.ClassCastException: 
java.base/[Ljava.lang.String; cannot be cast to 
java.base/java.lang.String\r\n\tat 
org.apache.solr.common.params.MapSolrParams.getParams(MapSolrParams.java:39)\r\n\tat
 
org.apache.solr.common.params.DefaultSolrParams.getParams(DefaultSolrParams.java:44)\r\n\tat
 
org.apache.solr.common.params.MultiMapSolrParams.asMultiMap(MultiMapSolrParams.java:103)\r\n\tat
 
org.apache.solr.common.params.MultiMapSolrParams.asMultiMap(MultiMapSolrParams.java:81)\r\n\tat
 
org.apache.solr.request.json.RequestUtil.processParams(RequestUtil.java:119)\r\n\tat
 
org.apache.solr.util.SolrPluginUtils.setDefaults(SolrPluginUtils.java:177)\r\n\tat
 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:175)\r\n\tat
 org.apache.solr.core.SolrCore.execute(SolrCore.java:2487)\r\n\tat 
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:722)\r\n\tat 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:528)\r\n\tat 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:374)\r\n\tat
 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:318)\r\n\tat
 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)\r\n\tat
 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)\r\n\tat
 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)\r\n\tat
 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)\r\n\tat
 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)\r\n\tat
 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)\r\n\tat
 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)\r\n\tat
 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\r\n\tat
 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)\r\n\tat
 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\r\n\tat
 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:462)\r\n\tat
 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\r\n\tat
 org.eclipse.jetty.server.Server.handle(Server.java:534)\r\n\tat 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)\r\n\tat 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)\r\n\tat
 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)\r\n\tat
 org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)\r\n\tat 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)\r\n\tat
 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)\r\n\tat
 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)\r\n\tat
 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)\r\n\tat
 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)\r\n\tat
 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)\r\n\tat
 java.base/java.lang.Thread.run(Thread.java:844)\r\n", "code":500}},  from 
server:  null

Stack Trace:
java.lang.AssertionError: Could not get expected value  'CY val' for path 
'params/c' full output: {
  "responseHeader":{
"status":500,
"QTime":1},
  "error":{
"msg":"java.base/[Ljava.lang.String; cannot be cast to 
java.base/java.lang.String",
"trace":"java.lang.ClassCastException: java.base/[Ljava.lang.String; cannot 
be cast to java.base/java.lang.String\r\n\tat 
org.apache.solr.common.params.MapSolrParams.getParams(MapSolrParams.java:39)\r\n\tat
 
org.apache.solr.common.params.DefaultSolrParams.getParams(DefaultSolrParams.java:44)\r\n\tat
 
org.apache.solr.common.params.MultiMapSolrParams.asMultiMap(MultiMapSolrParams.java:103)\r\n\tat
 
org.apache.solr.common.params.MultiMapSolrParams.asMultiMap(MultiMapSolrParams.java:81)\r\n\tat
 
org.apache.solr.request.json.RequestUtil.processParams(RequestUtil.java:119)\r\n\tat
 
org.apache.solr.util.SolrPluginUtils.setDefaults(SolrPluginUtils.java:177)\r\n\tat
 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:175)\r\n\tat
 org.apache.solr.core.SolrCore.execute(SolrCore.java:2487)\r\n\tat 

[jira] [Commented] (SOLR-10834) test configs should be changed to stop using numeric based uniqueKey field

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10834:
-

Last week i started experimenting with some scripted changes to test schemas & 
test xpath expressions to see if i could solve most of these w/o needing a lot 
of manual intervention.  The results seemed promising, so today i started 
digging into the manual cleanup still needed -- down to only ~40 failures, so 
i've gone ahead and pushed my branch in case anyone else wants to poke around 
and take a look.

(I do plan to come back to this soon either way)

> test configs should be changed to stop using numeric based uniqueKey field
> --
>
> Key: SOLR-10834
> URL: https://issues.apache.org/jira/browse/SOLR-10834
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>
> Apparently, once upon a time, as a way to prove that it worked and there were 
> no hard coded "String" assumptions, some the {{schema.xml}} used by tests was 
> written such that the uniqueKey field was definied as an "int".
> This has now snowballed such that there are at least 40 test schema files 
> (just in solr/core!) that define the uniqueKey field using a Trie field 
> (mostly TrieInt, but at least 2 TrieFloats!) despite the fact that at no 
> point have we ever recommended/encouraged people to use anything other then 
> StrField for their uniqueKey.
> that's nearly 1/3 of all the test schemas that we have -- which IIRC (from 
> some early experiments in SOLR-10807) are used in more then half the 
> solr/core tests.
> If we want to be able to deprecate/remove Trie fields in favor of point 
> fields, we're really going to update all of these test schemas to use a 
> StrField (we can't use PointFields as the uniqueKey due to the issues noted 
> in SOLR-10829) ... but AFAICT that's going to require a non trivial amount of 
> work due to many of these tests making explicit/implicit assumptions about 
> the datatype of the uniqueKey field (ex: sorting by id, range queries on ids, 
> casting stored field values returned by solrj, xpath expressions, etc...)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10834) test configs should be changed to stop using numeric based uniqueKey field

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10834:


Commit 1625df3d21b8fa27815d7a7b89a55fc338eeb23b in lucene-solr's branch 
refs/heads/jira/SOLR-10834 from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1625df3 ]

SOLR-10834: first step: bulk change test schemas using numeric uniqueKey fields 
to use string instead

many, many tests fail with this change


> test configs should be changed to stop using numeric based uniqueKey field
> --
>
> Key: SOLR-10834
> URL: https://issues.apache.org/jira/browse/SOLR-10834
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>
> Apparently, once upon a time, as a way to prove that it worked and there were 
> no hard coded "String" assumptions, some the {{schema.xml}} used by tests was 
> written such that the uniqueKey field was definied as an "int".
> This has now snowballed such that there are at least 40 test schema files 
> (just in solr/core!) that define the uniqueKey field using a Trie field 
> (mostly TrieInt, but at least 2 TrieFloats!) despite the fact that at no 
> point have we ever recommended/encouraged people to use anything other then 
> StrField for their uniqueKey.
> that's nearly 1/3 of all the test schemas that we have -- which IIRC (from 
> some early experiments in SOLR-10807) are used in more then half the 
> solr/core tests.
> If we want to be able to deprecate/remove Trie fields in favor of point 
> fields, we're really going to update all of these test schemas to use a 
> StrField (we can't use PointFields as the uniqueKey due to the issues noted 
> in SOLR-10829) ... but AFAICT that's going to require a non trivial amount of 
> work due to many of these tests making explicit/implicit assumptions about 
> the datatype of the uniqueKey field (ex: sorting by id, range queries on ids, 
> casting stored field values returned by solrj, xpath expressions, etc...)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7876) Avoid needless calls to LeafReader.fields and MultiFields.getFields

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-7876:
--

I'll commit this tomorrow.

> Avoid needless calls to LeafReader.fields and MultiFields.getFields
> ---
>
> Key: LUCENE-7876
> URL: https://issues.apache.org/jira/browse/LUCENE-7876
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: master (7.0), 6.7
>
> Attachments: LUCENE_7876_avoid_leafReader_fields.patch
>
>
> In LUCENE-7500 we're removing LeafReader.fields for 7.x.  Here in this issue 
> for 6.x and 7.x we simply avoid calling this method (and also 
> MultiFields.getFields) when there is an obvious replacement for 
> LeafReader.terms(field) (and MultiFields.getTerms).  Any absolutely 
> non-trivial changes are occurring in LUCENE-7500.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-9565) Make every UpdateRequestProcessor available implicitly

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9565:


+1 to the idea

Just curious; is there any code enabling this already in a common spot (if so 
where)?  Perhaps some other issue that escaped my attention made some of this 
possible already?



> Make every UpdateRequestProcessor available implicitly
> --
>
> Key: SOLR-9565
> URL: https://issues.apache.org/jira/browse/SOLR-9565
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>
> Now that we can 'construct' the URP chains through request parameters, we 
> should make all the URPs available automatically. The next challenge is to 
> make them read the configuration from request parameters as well
> to access {{HTMLStripFieldUpdateProcessorFactory}} the parameter could be 
> {{processor=HTMLStripField}} (The UpdateProcessorFactory part is 
> automatically appended )
> The next step is to make the URPs accept request parameters instead of just 
> configuration parameters e.g: 
> {{processor=HTMLStripField=}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10795) Numeric PointsFields: test multivalued sort using field(name, min|max) syntax

[JIRA]

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

Tomás Fernández Löbbe updated SOLR-10795:
-
Attachment: SOLR-10795.patch

> Numeric PointsFields: test multivalued sort using field(name, min|max) syntax
> -
>
> Key: SOLR-10795
> URL: https://issues.apache.org/jira/browse/SOLR-10795
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
> Attachments: SOLR-10795.patch
>
>
> TestMinMaxOnMultiValuedField tests Trie types for this case, should also test 
> Points



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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 # 891 - Still Unstable!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.hdfs.HdfsRecoveryZkTest

Error Message:
ObjectTracker found 1 object(s) that were not released!!! [HdfsTransactionLog] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.update.HdfsTransactionLog  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:130)  
at org.apache.solr.update.HdfsUpdateLog.init(HdfsUpdateLog.java:203)  at 
org.apache.solr.update.UpdateHandler.(UpdateHandler.java:153)  at 
org.apache.solr.update.UpdateHandler.(UpdateHandler.java:110)  at 
org.apache.solr.update.DirectUpdateHandler2.(DirectUpdateHandler2.java:108)
  at sun.reflect.GeneratedConstructorAccessor214.newInstance(Unknown Source)  
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
  at java.lang.reflect.Constructor.newInstance(Constructor.java:423)  at 
org.apache.solr.core.SolrCore.createInstance(SolrCore.java:760)  at 
org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:822)  at 
org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1088)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:947)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:830)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:930)  at 
org.apache.solr.core.CoreContainer.lambda$load$5(CoreContainer.java:565)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
 at java.lang.Thread.run(Thread.java:748)  

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [HdfsTransactionLog]
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.update.HdfsTransactionLog
at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
at 
org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:130)
at org.apache.solr.update.HdfsUpdateLog.init(HdfsUpdateLog.java:203)
at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:153)
at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:110)
at 
org.apache.solr.update.DirectUpdateHandler2.(DirectUpdateHandler2.java:108)
at sun.reflect.GeneratedConstructorAccessor214.newInstance(Unknown 
Source)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:760)
at org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:822)
at org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1088)
at org.apache.solr.core.SolrCore.(SolrCore.java:947)
at org.apache.solr.core.SolrCore.(SolrCore.java:830)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:930)
at 
org.apache.solr.core.CoreContainer.lambda$load$5(CoreContainer.java:565)
at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)


at __randomizedtesting.SeedInfo.seed([287D8AB58761C709]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:302)
at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:870)
at 

[jira] [Comment Edited] (SOLR-10873) Explore a utility for periodically checking the document counts for replicas of a shard

[Pushkar Raste (JIRA)]

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

Pushkar Raste edited comment on SOLR-10873 at 6/13/17 1:03 AM:
---

There are other advantages too
* You can compute Index fingerprint upto any arbitrary version. Depending on 
tolerance, you can check if fingerprint matches the last version in the second 
from last tlog. No need to differ commits in this case 

* Index fingerprint is cached in SolrCore class and hence even if frequency of 
sync check is high you may not have recompute fingerprint every single time

`RealTimeGetcomponent` already supports a call `processGetFingerprint` while 
working on SOLR-9446

 


was (Author: praste):
There are other advantages too
* You can compute Index fingerprint upto any arbitrary version. Depending on 
tolerance, you can check if fingerprint matches the last version in the second 
from last tlog. No need to differ commits in this case 

* Index fingerprint is cached in SolrCore class and hence even frequency of 
sync check is high you may not have recompute fingerprint every single time

`RealTimeGetcomponent` already supports a call `processGetFingerprint` while 
working on SOLR-9446

 

> Explore a utility for periodically checking the document counts for replicas 
> of a shard
> ---
>
> Key: SOLR-10873
> URL: https://issues.apache.org/jira/browse/SOLR-10873
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>
> We've had several situations "in the field" and on the user's list where the 
> number of documents on different replicas of the same shard differ. I've also 
> seen situations where the numbers are wildly different (two orders of 
> magnitude). I can force this situation by, say, taking down nodes, adding 
> replicas that become the leader then starting the nodes back up. But it 
> doesn't matter whether the discrepancy is a result of "pilot error" or a 
> problem with the code, in either case it would be useful to flag it.
> Straw-man proposal:
> We create a processor (modeled on DocExpirationUpdateProcessorFactory 
> perhaps?) that periodically wakes up and checks that each replica in the 
> given shard has the same document count (and perhaps other checks TBD?). Send 
> some kind of notification if a problem was detected.
> Issues:
> 1> this will require some way to deal with the differing commit times. 
> 1a> If we require a timestamp on each document we could check the config file 
> to see the autocommit interval and, say, check NOW-(2 x opensearcher 
> interval). In that case the config would just require the field to use be 
> specified.
> 1b> we could require that part of the configuration is a query to use to 
> check document counts. I kind of like this one.
> 2> How to let the admins know a discrepancy was found? e-mail? ERROR level 
> log message? Other?
> 3> How does this fit into the autoscaling initiative? This is a "monitor the 
> system and do something" item. If we go forward with this we should do it 
> with an eye toward fitting it in that framework.
> 3a> Is there anything we can do to auto-correct this situation? 
> Auto-correction could be tricky. Heuristics like "make the replica with the 
> most documents the leader and force full index replication on all the 
> replicas that don't agree" seem dangerous. 
> 4> How to keep the impact minimal? The simple approach would be for each 
> replica to check all other replicas in the shard. So say there are 10 
> replicas on a single shard, that would be 90 queries. It would suffice for 
> just one of those to check the other 9, not have all 10 check the other nine. 
> Maybe restrict the checker to be the leader? Or otherwise just make it one 
> replica/shard that does the checking?
> 5> It's probably useful to add a collections API call to fire this off 
> manually. Or maybe as part of CHECKSTATUS?
> What do people think?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-10873) Explore a utility for periodically checking the document counts for replicas of a shard

[Pushkar Raste (JIRA)]

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

Pushkar Raste edited comment on SOLR-10873 at 6/13/17 1:02 AM:
---

There are other advantages too
* You can compute Index fingerprint upto any arbitrary version. Depending on 
tolerance, you can check if fingerprint matches the last version in the second 
from last tlog. No need to differ commits in this case 

* Index fingerprint is cached in SolrCore class and hence even frequency of 
sync check is high you may not have recompute fingerprint every single time

`RealTimeGetcomponent` already supports a call `processGetFingerprint` while 
working on SOLR-9446

 


was (Author: praste):
There are other advantages too
* You can compute Index fingerprint upto any arbitrary version. Depending on 
tolerance, you can check if fingerprint matches the last version in second from 
last version in the tlog. No need to differ commits in this case 

* Index fingerprint is cached in SolrCore class and hence even frequency of 
sync check is high you may not have recompute fingerprint every single time

`RealTimeGetcomponent` already supports a call `processGetFingerprint` while 
working on SOLR-9446

 

> Explore a utility for periodically checking the document counts for replicas 
> of a shard
> ---
>
> Key: SOLR-10873
> URL: https://issues.apache.org/jira/browse/SOLR-10873
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>
> We've had several situations "in the field" and on the user's list where the 
> number of documents on different replicas of the same shard differ. I've also 
> seen situations where the numbers are wildly different (two orders of 
> magnitude). I can force this situation by, say, taking down nodes, adding 
> replicas that become the leader then starting the nodes back up. But it 
> doesn't matter whether the discrepancy is a result of "pilot error" or a 
> problem with the code, in either case it would be useful to flag it.
> Straw-man proposal:
> We create a processor (modeled on DocExpirationUpdateProcessorFactory 
> perhaps?) that periodically wakes up and checks that each replica in the 
> given shard has the same document count (and perhaps other checks TBD?). Send 
> some kind of notification if a problem was detected.
> Issues:
> 1> this will require some way to deal with the differing commit times. 
> 1a> If we require a timestamp on each document we could check the config file 
> to see the autocommit interval and, say, check NOW-(2 x opensearcher 
> interval). In that case the config would just require the field to use be 
> specified.
> 1b> we could require that part of the configuration is a query to use to 
> check document counts. I kind of like this one.
> 2> How to let the admins know a discrepancy was found? e-mail? ERROR level 
> log message? Other?
> 3> How does this fit into the autoscaling initiative? This is a "monitor the 
> system and do something" item. If we go forward with this we should do it 
> with an eye toward fitting it in that framework.
> 3a> Is there anything we can do to auto-correct this situation? 
> Auto-correction could be tricky. Heuristics like "make the replica with the 
> most documents the leader and force full index replication on all the 
> replicas that don't agree" seem dangerous. 
> 4> How to keep the impact minimal? The simple approach would be for each 
> replica to check all other replicas in the shard. So say there are 10 
> replicas on a single shard, that would be 90 queries. It would suffice for 
> just one of those to check the other 9, not have all 10 check the other nine. 
> Maybe restrict the checker to be the leader? Or otherwise just make it one 
> replica/shard that does the checking?
> 5> It's probably useful to add a collections API call to fire this off 
> manually. Or maybe as part of CHECKSTATUS?
> What do people think?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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+173) - Build # 3732 - Unstable!

[Policeman Jenkins Server]

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

7 tests failed.
FAILED:  org.apache.solr.cloud.CollectionsAPISolrJTest.testBalanceShardUnique

Error Message:
Expecting 'preferredleader' property to be balanced across all shards null Last 
available state: null

Stack Trace:
java.lang.AssertionError: Expecting 'preferredleader' property to be balanced 
across all shards
null
Last available state: null
at 
__randomizedtesting.SeedInfo.seed([323E5125B5619725:7A86E7680FC13FE6]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:265)
at 
org.apache.solr.cloud.CollectionsAPISolrJTest.testBalanceShardUnique(CollectionsAPISolrJTest.java:333)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
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:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  
org.apache.solr.cloud.CollectionsAPISolrJTest.testAddAndDeleteReplicaProp

Error Message:
Could not find collection : 

[jira] [Commented] (SOLR-10873) Explore a utility for periodically checking the document counts for replicas of a shard

[Pushkar Raste (JIRA)]

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

Pushkar Raste commented on SOLR-10873:
--

There are other advantages too
* You can compute Index fingerprint upto any arbitrary version. Depending on 
tolerance, you can check if fingerprint matches the last version in second from 
last version in the tlog. No need to differ commits in this case 

* Index fingerprint is cached in SolrCore class and hence even frequency of 
sync check is high you may not have recompute fingerprint every single time

`RealTimeGetcomponent` already supports a call `processGetFingerprint` while 
working on SOLR-9446

 

> Explore a utility for periodically checking the document counts for replicas 
> of a shard
> ---
>
> Key: SOLR-10873
> URL: https://issues.apache.org/jira/browse/SOLR-10873
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>
> We've had several situations "in the field" and on the user's list where the 
> number of documents on different replicas of the same shard differ. I've also 
> seen situations where the numbers are wildly different (two orders of 
> magnitude). I can force this situation by, say, taking down nodes, adding 
> replicas that become the leader then starting the nodes back up. But it 
> doesn't matter whether the discrepancy is a result of "pilot error" or a 
> problem with the code, in either case it would be useful to flag it.
> Straw-man proposal:
> We create a processor (modeled on DocExpirationUpdateProcessorFactory 
> perhaps?) that periodically wakes up and checks that each replica in the 
> given shard has the same document count (and perhaps other checks TBD?). Send 
> some kind of notification if a problem was detected.
> Issues:
> 1> this will require some way to deal with the differing commit times. 
> 1a> If we require a timestamp on each document we could check the config file 
> to see the autocommit interval and, say, check NOW-(2 x opensearcher 
> interval). In that case the config would just require the field to use be 
> specified.
> 1b> we could require that part of the configuration is a query to use to 
> check document counts. I kind of like this one.
> 2> How to let the admins know a discrepancy was found? e-mail? ERROR level 
> log message? Other?
> 3> How does this fit into the autoscaling initiative? This is a "monitor the 
> system and do something" item. If we go forward with this we should do it 
> with an eye toward fitting it in that framework.
> 3a> Is there anything we can do to auto-correct this situation? 
> Auto-correction could be tricky. Heuristics like "make the replica with the 
> most documents the leader and force full index replication on all the 
> replicas that don't agree" seem dangerous. 
> 4> How to keep the impact minimal? The simple approach would be for each 
> replica to check all other replicas in the shard. So say there are 10 
> replicas on a single shard, that would be 90 queries. It would suffice for 
> just one of those to check the other 9, not have all 10 check the other nine. 
> Maybe restrict the checker to be the leader? Or otherwise just make it one 
> replica/shard that does the checking?
> 5> It's probably useful to add a collections API call to fire this off 
> manually. Or maybe as part of CHECKSTATUS?
> What do people think?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10858) Make UUIDUpdateProcessorFactory as Runtime URP; take params(s) with request

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-10858:
---

[~dsmi...@mac.com] you can comment on SOLR-9565. We can discuss it there

> Make UUIDUpdateProcessorFactory as Runtime URP; take params(s) with request
> ---
>
> Key: SOLR-10858
> URL: https://issues.apache.org/jira/browse/SOLR-10858
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Reporter: Amrit Sarkar
>Priority: Minor
> Attachments: SOLR-10858.patch, SOLR-10858.patch, SOLR-10858.patch, 
> SOLR-10858.patch
>
>
> We are trying to get rid of processor definitions in SolrConfig for all URPs 
> and take parameters in the request itself.
> UUIDUpdateProcessorFactory will be able to execute by sample curl like below:
> {code}
>  curl -X POST -H Content-Type: application/json  
> http://localhost:8983/solr/test/update/json/docs?processor=UUID=id=true
>  --data-binary {"title": "titleA"}
> {code}
> {code}
>  curl -X POST -H Content-Type: application/json  
> http://localhost:8983/solr/test/update/json/docs?processor=UUID=true 
> --data-binary {"id":"1","title": "titleA"}
> {code}
> {code}
>  curl -X POST -H Content-Type: application/json  
> http://localhost:8983/solr/test/update/json/docs?processor=UUID=id=true
>  --data-binary {"id":"1","title": "titleA"}
> {code}
> Configuration for UUIDUpdateProcessorFactory in solrconfig.xml is optional.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10873) Explore a utility for periodically checking the document counts for replicas of a shard

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-10873:
---

Good idea! Plus it seems lightweight as well

> Explore a utility for periodically checking the document counts for replicas 
> of a shard
> ---
>
> Key: SOLR-10873
> URL: https://issues.apache.org/jira/browse/SOLR-10873
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>
> We've had several situations "in the field" and on the user's list where the 
> number of documents on different replicas of the same shard differ. I've also 
> seen situations where the numbers are wildly different (two orders of 
> magnitude). I can force this situation by, say, taking down nodes, adding 
> replicas that become the leader then starting the nodes back up. But it 
> doesn't matter whether the discrepancy is a result of "pilot error" or a 
> problem with the code, in either case it would be useful to flag it.
> Straw-man proposal:
> We create a processor (modeled on DocExpirationUpdateProcessorFactory 
> perhaps?) that periodically wakes up and checks that each replica in the 
> given shard has the same document count (and perhaps other checks TBD?). Send 
> some kind of notification if a problem was detected.
> Issues:
> 1> this will require some way to deal with the differing commit times. 
> 1a> If we require a timestamp on each document we could check the config file 
> to see the autocommit interval and, say, check NOW-(2 x opensearcher 
> interval). In that case the config would just require the field to use be 
> specified.
> 1b> we could require that part of the configuration is a query to use to 
> check document counts. I kind of like this one.
> 2> How to let the admins know a discrepancy was found? e-mail? ERROR level 
> log message? Other?
> 3> How does this fit into the autoscaling initiative? This is a "monitor the 
> system and do something" item. If we go forward with this we should do it 
> with an eye toward fitting it in that framework.
> 3a> Is there anything we can do to auto-correct this situation? 
> Auto-correction could be tricky. Heuristics like "make the replica with the 
> most documents the leader and force full index replication on all the 
> replicas that don't agree" seem dangerous. 
> 4> How to keep the impact minimal? The simple approach would be for each 
> replica to check all other replicas in the shard. So say there are 10 
> replicas on a single shard, that would be 90 queries. It would suffice for 
> just one of those to check the other 9, not have all 10 check the other nine. 
> Maybe restrict the checker to be the leader? Or otherwise just make it one 
> replica/shard that does the checking?
> 5> It's probably useful to add a collections API call to fire this off 
> manually. Or maybe as part of CHECKSTATUS?
> What do people think?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10778) Ant precommit task WARNINGS about unclosed resources

[Andrew Musselman (JIRA)]

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

Andrew Musselman commented on SOLR-10778:
-

On my list; anything that gets rid of excessive warnings that people ignore is 
good in my book.

> Ant precommit task WARNINGS about unclosed resources
> 
>
> Key: SOLR-10778
> URL: https://issues.apache.org/jira/browse/SOLR-10778
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: clients - java
>Affects Versions: 4.6
>Reporter: Andrew Musselman
>Priority: Minor
> Attachments: notclosed.txt
>
>
> During precommit we are seeing lots of warnings about resources that aren't 
> being closed, which could pose problems based on chat amongst the team. Log 
> snippet for example:
> [mkdir] Created dir: 
> /var/folders/5p/6b46rm_94dzc5m8d4v56tds4gp/T/ecj1165341501
>  [ecj-lint] Compiling 419 source files to 
> /var/folders/5p/6b46rm_94dzc5m8d4v56tds4gp/T/ecj1165341501
>  [ecj-lint] --
>  [ecj-lint] 1. WARNING in 
> /path/to/lucene-solr/solr/solrj/src/java/org/apache/solr/client/solrj/impl/LBHttpSolrClient.java
>  (at line 920)
>  [ecj-lint] new LBHttpSolrClient(httpSolrClientBuilder, httpClient, 
> solrServerUrls) :
>  [ecj-lint] 
> ^^^
>  [ecj-lint] Resource leak: '' is never closed
>  [ecj-lint] --
>  [ecj-lint] --
>  [ecj-lint] 2. WARNING in 
> /path/to/lucene-solr/solr/solrj/src/java/org/apache/solr/client/solrj/impl/StreamingBinaryResponseParser.java
>  (at line 49)
>  [ecj-lint] JavaBinCodec codec = new JavaBinCodec() {
>  [ecj-lint]  ^
>  [ecj-lint] Resource leak: 'codec' is never closed
>  [ecj-lint] --
>  [ecj-lint] --
>  [ecj-lint] 3. WARNING in 
> /path/to/lucene-solr/solr/solrj/src/java/org/apache/solr/client/solrj/request/JavaBinUpdateRequestCodec.java
>  (at line 90)
>  [ecj-lint] JavaBinCodec codec = new JavaBinCodec();
>  [ecj-lint]  ^
>  [ecj-lint] Resource leak: 'codec' is never closed
>  [ecj-lint] --
>  [ecj-lint] 4. WARNING in 
> /path/to/lucene-solr/solr/solrj/src/java/org/apache/solr/client/solrj/request/JavaBinUpdateRequestCodec.java
>  (at line 113)
>  [ecj-lint] JavaBinCodec codec = new JavaBinCodec() {
>  [ecj-lint]  ^
>  [ecj-lint] Resource leak: 'codec' is never closed



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

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

4 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.ZkControllerTest

Error Message:
ObjectTracker found 1 object(s) that were not released!!! [Overseer] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.cloud.Overseer  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.cloud.Overseer.start(Overseer.java:527)  at 
org.apache.solr.cloud.OverseerElectionContext.runLeaderProcess(ElectionContext.java:774)
  at 
org.apache.solr.cloud.LeaderElector.runIamLeaderProcess(LeaderElector.java:170) 
 at 
org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:135)  
at org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:307)  at 
org.apache.solr.cloud.LeaderElector.retryElection(LeaderElector.java:393)  at 
org.apache.solr.cloud.ZkController.rejoinOverseerElection(ZkController.java:1777)
  at 
org.apache.solr.cloud.Overseer$ClusterStateUpdater.checkIfIamStillLeader(Overseer.java:316)
  at java.lang.Thread.run(Thread.java:748)  

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [Overseer]
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.cloud.Overseer
at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
at org.apache.solr.cloud.Overseer.start(Overseer.java:527)
at 
org.apache.solr.cloud.OverseerElectionContext.runLeaderProcess(ElectionContext.java:774)
at 
org.apache.solr.cloud.LeaderElector.runIamLeaderProcess(LeaderElector.java:170)
at 
org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:135)
at 
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:307)
at 
org.apache.solr.cloud.LeaderElector.retryElection(LeaderElector.java:393)
at 
org.apache.solr.cloud.ZkController.rejoinOverseerElection(ZkController.java:1777)
at 
org.apache.solr.cloud.Overseer$ClusterStateUpdater.checkIfIamStillLeader(Overseer.java:316)
at java.lang.Thread.run(Thread.java:748)


at __randomizedtesting.SeedInfo.seed([4A06197013ED6D44]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:295)
at sun.reflect.GeneratedMethodAccessor32.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:870)
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:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.ZkControllerTest

Error Message:
1 thread leaked from SUITE 

[jira] [Commented] (SOLR-9321) Removed usage of deprecated clusterstate.getSlicesMap(), getSlices() and getActiveSlices()

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski commented on SOLR-9321:
---

[~ichattopadhyaya] any suggestions on how to replace that last deprecated 
method ({{getZkClusterStateVersion}})?

Based on my somewhat-naive understanding of the code involved, my 
suggestion/vote would be to work towards a solution where {{ZkStateWriter}} 
maintains a node with the express purpose of tracking the versioning of the 
ClusterState nodes.  The reason for deprecating getZkClusterStateVersion 
wouldn't be relevant anymore, and we could un-deprecate the method.  

But that would stretch the scope of this JIRA beyond the initial aim.  Would it 
be reasonable to split the resolution of {{getZkClusterStateVersion}} into a 
separate JIRA, since it appears more involved than a find-replace?  

> Removed usage of deprecated clusterstate.getSlicesMap(), getSlices() and 
> getActiveSlices()
> --
>
> Key: SOLR-9321
> URL: https://issues.apache.org/jira/browse/SOLR-9321
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-9321.patch, SOLR-9321.patch, SOLR-9321.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10873) Explore a utility for periodically checking the document counts for replicas of a shard

[Pushkar Raste (JIRA)]

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

Pushkar Raste commented on SOLR-10873:
--

 What if count is same but actual data is different. 
Can we use Index fingerprint instead to verify if replicas are in sync? 

> Explore a utility for periodically checking the document counts for replicas 
> of a shard
> ---
>
> Key: SOLR-10873
> URL: https://issues.apache.org/jira/browse/SOLR-10873
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>
> We've had several situations "in the field" and on the user's list where the 
> number of documents on different replicas of the same shard differ. I've also 
> seen situations where the numbers are wildly different (two orders of 
> magnitude). I can force this situation by, say, taking down nodes, adding 
> replicas that become the leader then starting the nodes back up. But it 
> doesn't matter whether the discrepancy is a result of "pilot error" or a 
> problem with the code, in either case it would be useful to flag it.
> Straw-man proposal:
> We create a processor (modeled on DocExpirationUpdateProcessorFactory 
> perhaps?) that periodically wakes up and checks that each replica in the 
> given shard has the same document count (and perhaps other checks TBD?). Send 
> some kind of notification if a problem was detected.
> Issues:
> 1> this will require some way to deal with the differing commit times. 
> 1a> If we require a timestamp on each document we could check the config file 
> to see the autocommit interval and, say, check NOW-(2 x opensearcher 
> interval). In that case the config would just require the field to use be 
> specified.
> 1b> we could require that part of the configuration is a query to use to 
> check document counts. I kind of like this one.
> 2> How to let the admins know a discrepancy was found? e-mail? ERROR level 
> log message? Other?
> 3> How does this fit into the autoscaling initiative? This is a "monitor the 
> system and do something" item. If we go forward with this we should do it 
> with an eye toward fitting it in that framework.
> 3a> Is there anything we can do to auto-correct this situation? 
> Auto-correction could be tricky. Heuristics like "make the replica with the 
> most documents the leader and force full index replication on all the 
> replicas that don't agree" seem dangerous. 
> 4> How to keep the impact minimal? The simple approach would be for each 
> replica to check all other replicas in the shard. So say there are 10 
> replicas on a single shard, that would be 90 queries. It would suffice for 
> just one of those to check the other 9, not have all 10 check the other nine. 
> Maybe restrict the checker to be the leader? Or otherwise just make it one 
> replica/shard that does the checking?
> 5> It's probably useful to add a collections API call to fire this off 
> manually. Or maybe as part of CHECKSTATUS?
> What do people think?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-10850) HttpSolrClient Javadoc examples reference nonexistent constructors

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski resolved SOLR-10850.

Resolution: Duplicate

> HttpSolrClient Javadoc examples reference nonexistent constructors
> --
>
> Key: SOLR-10850
> URL: https://issues.apache.org/jira/browse/SOLR-10850
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: master (7.0)
>Reporter: Jason Gerlowski
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-10850.patch
>
>
> A recent [JIRA|https://issues.apache.org/jira/browse/SOLR-10755] removed a 
> number of deprecated constructors from the SolrClient implementations.
> In the case of {{HttpSolrClient}}, the top-level Javadocs contain 
> instantiation instructions that still reference the old constructors:
> e.g.
> {code}
> /**
>  * A SolrClient implementation that talks directly to a Solr server via HTTP
>  *
>  * There are two ways to use an HttpSolrClient:
>  *
>  * 1) Pass a URL to the constructor that points directly at a particular core
>  * 
>  *   SolrClient client = new 
> HttpSolrClient("http://my-solr-server:8983/solr/core1;);
>  *   QueryResponse resp = client.query(new SolrQuery("*:*"));
>  * 
>  * In this case, you can query the given core directly, but you cannot query 
> any other
>  * cores or issue CoreAdmin requests with this client.
>  *
>  * 2) Pass the base URL of the node to the constructor
>  * 
>  *   SolrClient client = new 
> HttpSolrClient("http://my-solr-server:8983/solr;);
>  *   QueryResponse resp = client.query("core1", new SolrQuery("*:*"));
>  * 
>  * In this case, you must pass the name of the required core for all queries 
> and updates,
>  * but you may use the same client for all cores, and for CoreAdmin requests.
>  */
> {code}
> These Javadocs should be updated with examples that use the client Builder 
> types.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10850) HttpSolrClient Javadoc examples reference nonexistent constructors

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski commented on SOLR-10850:


When I filed this JIRA issue and SOLR-10851, I filed them separately as they 
seemed like conceptually different problems.  This ticket was about some a 
specific Javadoc comment that used some outdated methods; SOLR-10581 was 
focused on improving SolrClient documentation overall.

Both issues involved changes to the same lines of code/documentation though, 
and the recent resolution of SOLR-10581 has resolved this issue by coincidence.

I'm going to mark this issue as closed (if I have the permissions to).  If it 
turns out that I don't, I would request that someone please close it for me.



> HttpSolrClient Javadoc examples reference nonexistent constructors
> --
>
> Key: SOLR-10850
> URL: https://issues.apache.org/jira/browse/SOLR-10850
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: master (7.0)
>Reporter: Jason Gerlowski
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-10850.patch
>
>
> A recent [JIRA|https://issues.apache.org/jira/browse/SOLR-10755] removed a 
> number of deprecated constructors from the SolrClient implementations.
> In the case of {{HttpSolrClient}}, the top-level Javadocs contain 
> instantiation instructions that still reference the old constructors:
> e.g.
> {code}
> /**
>  * A SolrClient implementation that talks directly to a Solr server via HTTP
>  *
>  * There are two ways to use an HttpSolrClient:
>  *
>  * 1) Pass a URL to the constructor that points directly at a particular core
>  * 
>  *   SolrClient client = new 
> HttpSolrClient("http://my-solr-server:8983/solr/core1;);
>  *   QueryResponse resp = client.query(new SolrQuery("*:*"));
>  * 
>  * In this case, you can query the given core directly, but you cannot query 
> any other
>  * cores or issue CoreAdmin requests with this client.
>  *
>  * 2) Pass the base URL of the node to the constructor
>  * 
>  *   SolrClient client = new 
> HttpSolrClient("http://my-solr-server:8983/solr;);
>  *   QueryResponse resp = client.query("core1", new SolrQuery("*:*"));
>  * 
>  * In this case, you must pass the name of the required core for all queries 
> and updates,
>  * but you may use the same client for all cores, and for CoreAdmin requests.
>  */
> {code}
> These Javadocs should be updated with examples that use the client Builder 
> types.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-10850) HttpSolrClient Javadoc examples reference nonexistent constructors

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski edited comment on SOLR-10850 at 6/12/17 11:13 PM:
--

When I filed this JIRA issue and SOLR-10851, I filed them separately as they 
seemed like conceptually different problems.  This ticket was about some a 
specific Javadoc comment that used some outdated methods; SOLR-10851 was 
focused on improving SolrClient documentation overall.

Both issues involved changes to the same lines of code/documentation though, 
and the recent resolution of SOLR-10851 has resolved this issue by coincidence.

I'm going to mark this issue as closed (if I have the permissions to).  If it 
turns out that I don't, I would request that someone please close it for me.




was (Author: gerlowskija):
When I filed this JIRA issue and SOLR-10851, I filed them separately as they 
seemed like conceptually different problems.  This ticket was about some a 
specific Javadoc comment that used some outdated methods; SOLR-10581 was 
focused on improving SolrClient documentation overall.

Both issues involved changes to the same lines of code/documentation though, 
and the recent resolution of SOLR-10581 has resolved this issue by coincidence.

I'm going to mark this issue as closed (if I have the permissions to).  If it 
turns out that I don't, I would request that someone please close it for me.



> HttpSolrClient Javadoc examples reference nonexistent constructors
> --
>
> Key: SOLR-10850
> URL: https://issues.apache.org/jira/browse/SOLR-10850
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: master (7.0)
>Reporter: Jason Gerlowski
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-10850.patch
>
>
> A recent [JIRA|https://issues.apache.org/jira/browse/SOLR-10755] removed a 
> number of deprecated constructors from the SolrClient implementations.
> In the case of {{HttpSolrClient}}, the top-level Javadocs contain 
> instantiation instructions that still reference the old constructors:
> e.g.
> {code}
> /**
>  * A SolrClient implementation that talks directly to a Solr server via HTTP
>  *
>  * There are two ways to use an HttpSolrClient:
>  *
>  * 1) Pass a URL to the constructor that points directly at a particular core
>  * 
>  *   SolrClient client = new 
> HttpSolrClient("http://my-solr-server:8983/solr/core1;);
>  *   QueryResponse resp = client.query(new SolrQuery("*:*"));
>  * 
>  * In this case, you can query the given core directly, but you cannot query 
> any other
>  * cores or issue CoreAdmin requests with this client.
>  *
>  * 2) Pass the base URL of the node to the constructor
>  * 
>  *   SolrClient client = new 
> HttpSolrClient("http://my-solr-server:8983/solr;);
>  *   QueryResponse resp = client.query("core1", new SolrQuery("*:*"));
>  * 
>  * In this case, you must pass the name of the required core for all queries 
> and updates,
>  * but you may use the same client for all cores, and for CoreAdmin requests.
>  */
> {code}
> These Javadocs should be updated with examples that use the client Builder 
> types.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-10875) Cleanup @SuppressCodecs annotations for old codecs

[JIRA]

Tomás Fernández Löbbe created SOLR-10875:


 Summary: Cleanup @SuppressCodecs annotations for old codecs
 Key: SOLR-10875
 URL: https://issues.apache.org/jira/browse/SOLR-10875
 Project: Solr
  Issue Type: Task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Tomás Fernández Löbbe
Priority: Trivial


There are some {{@SuppressCodecs}} annotations in our tests for 3x and 4x 
codecs that can be removed



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10778) Ant precommit task WARNINGS about unclosed resources

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-10778:
---

I'm hoping to chip away at it a little at a time, any help welcome of course.

And if we really want to get ambitious, all the warnings period. All the 
deprecated warnings. All the.. Then on to findbugs. Then

> Ant precommit task WARNINGS about unclosed resources
> 
>
> Key: SOLR-10778
> URL: https://issues.apache.org/jira/browse/SOLR-10778
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: clients - java
>Affects Versions: 4.6
>Reporter: Andrew Musselman
>Priority: Minor
> Attachments: notclosed.txt
>
>
> During precommit we are seeing lots of warnings about resources that aren't 
> being closed, which could pose problems based on chat amongst the team. Log 
> snippet for example:
> [mkdir] Created dir: 
> /var/folders/5p/6b46rm_94dzc5m8d4v56tds4gp/T/ecj1165341501
>  [ecj-lint] Compiling 419 source files to 
> /var/folders/5p/6b46rm_94dzc5m8d4v56tds4gp/T/ecj1165341501
>  [ecj-lint] --
>  [ecj-lint] 1. WARNING in 
> /path/to/lucene-solr/solr/solrj/src/java/org/apache/solr/client/solrj/impl/LBHttpSolrClient.java
>  (at line 920)
>  [ecj-lint] new LBHttpSolrClient(httpSolrClientBuilder, httpClient, 
> solrServerUrls) :
>  [ecj-lint] 
> ^^^
>  [ecj-lint] Resource leak: '' is never closed
>  [ecj-lint] --
>  [ecj-lint] --
>  [ecj-lint] 2. WARNING in 
> /path/to/lucene-solr/solr/solrj/src/java/org/apache/solr/client/solrj/impl/StreamingBinaryResponseParser.java
>  (at line 49)
>  [ecj-lint] JavaBinCodec codec = new JavaBinCodec() {
>  [ecj-lint]  ^
>  [ecj-lint] Resource leak: 'codec' is never closed
>  [ecj-lint] --
>  [ecj-lint] --
>  [ecj-lint] 3. WARNING in 
> /path/to/lucene-solr/solr/solrj/src/java/org/apache/solr/client/solrj/request/JavaBinUpdateRequestCodec.java
>  (at line 90)
>  [ecj-lint] JavaBinCodec codec = new JavaBinCodec();
>  [ecj-lint]  ^
>  [ecj-lint] Resource leak: 'codec' is never closed
>  [ecj-lint] --
>  [ecj-lint] 4. WARNING in 
> /path/to/lucene-solr/solr/solrj/src/java/org/apache/solr/client/solrj/request/JavaBinUpdateRequestCodec.java
>  (at line 113)
>  [ecj-lint] JavaBinCodec codec = new JavaBinCodec() {
>  [ecj-lint]  ^
>  [ecj-lint] Resource leak: 'codec' is never closed



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-10851) SolrClient's should clarify expectations for solrServerUrl parameter

[JIRA]

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

Tomás Fernández Löbbe resolved SOLR-10851.
--
   Resolution: Fixed
Fix Version/s: 6.7

Thanks Jason

> SolrClient's should clarify expectations for solrServerUrl parameter
> 
>
> Key: SOLR-10851
> URL: https://issues.apache.org/jira/browse/SOLR-10851
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: master (7.0)
>Reporter: Jason Gerlowski
>Assignee: Tomás Fernández Löbbe
>Priority: Trivial
> Fix For: master (7.0), 6.7
>
> Attachments: SOLR-10581.patch
>
>
> A recent [mailing 
> list|http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201706.mbox/%3C7742F2CD-95EA-490C-8886-726FC5CA4F95%40apple.com%3E]
>  thread brought up a common point of confusion: it's difficult for new users 
> to tell what URL/path should be given as the {{solrServerUrl}} SolrClient 
> param.
> Currently, the top-level HttpSolrClient Javadocs explain this.  But none of 
> the other SolrClient implementations provide any guidance to unfamiliar users.
> We should add consistent documentation for this parameter to each of the 
> SolrClient implementations.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10851) SolrClient's should clarify expectations for solrServerUrl parameter

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10851:


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

SOLR-10851: SolrClients should clarify expectations for solrServerUrl parameter


> SolrClient's should clarify expectations for solrServerUrl parameter
> 
>
> Key: SOLR-10851
> URL: https://issues.apache.org/jira/browse/SOLR-10851
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: master (7.0)
>Reporter: Jason Gerlowski
>Assignee: Tomás Fernández Löbbe
>Priority: Trivial
> Fix For: master (7.0)
>
> Attachments: SOLR-10581.patch
>
>
> A recent [mailing 
> list|http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201706.mbox/%3C7742F2CD-95EA-490C-8886-726FC5CA4F95%40apple.com%3E]
>  thread brought up a common point of confusion: it's difficult for new users 
> to tell what URL/path should be given as the {{solrServerUrl}} SolrClient 
> param.
> Currently, the top-level HttpSolrClient Javadocs explain this.  But none of 
> the other SolrClient implementations provide any guidance to unfamiliar users.
> We should add consistent documentation for this parameter to each of the 
> SolrClient implementations.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10851) SolrClient's should clarify expectations for solrServerUrl parameter

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10851:


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

SOLR-10851: SolrClients should clarify expectations for solrServerUrl parameter


> SolrClient's should clarify expectations for solrServerUrl parameter
> 
>
> Key: SOLR-10851
> URL: https://issues.apache.org/jira/browse/SOLR-10851
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: master (7.0)
>Reporter: Jason Gerlowski
>Assignee: Tomás Fernández Löbbe
>Priority: Trivial
> Fix For: master (7.0)
>
> Attachments: SOLR-10581.patch
>
>
> A recent [mailing 
> list|http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201706.mbox/%3C7742F2CD-95EA-490C-8886-726FC5CA4F95%40apple.com%3E]
>  thread brought up a common point of confusion: it's difficult for new users 
> to tell what URL/path should be given as the {{solrServerUrl}} SolrClient 
> param.
> Currently, the top-level HttpSolrClient Javadocs explain this.  But none of 
> the other SolrClient implementations provide any guidance to unfamiliar users.
> We should add consistent documentation for this parameter to each of the 
> SolrClient implementations.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-10760) Remove trie field types and fields from example schemas

[Cassandra Targett (JIRA)]

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

Cassandra Targett edited comment on SOLR-10760 at 6/12/17 10:36 PM:


SOLR-9989 covers adding support for PointFields to JSON Facets. 

If we are agreed that we want to remove trie types/fields from example schemas 
for 7.0, then SOLR-9989 is a blocker for this issue. I'll mark it as such, and 
make another comment in that issue related to this.

Also, if this is a community goal for 7.0, we should probably change the 
priority here so it's marked as a blocker for 7.0.


was (Author: ctargett):
SOLR-9989 covers adding support for PointFields to JSON Facets. 

If we are agreed that we want to remove trie types/fields from example schemas 
for 7.0, then SOLR-9989 is a blocker for this issue. I'll mark it as such, and 
make another comment in that issue related to this.

> Remove trie field types and fields from example schemas
> ---
>
> Key: SOLR-10760
> URL: https://issues.apache.org/jira/browse/SOLR-10760
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>
> In order to make points fields the default, we should remove all trie field 
> types and fields from example schemas.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-9989) Add support for PointFields in FacetModule (JSON Facets)

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-9989:
-

If we want to remove trie* types and fields from 7.0 (as suggested in 
SOLR-10760), we need to make some decisions about this issue. Either we need to 
leave JSON Facets behind, or someone needs to help Dat out with a patch review 
so we can move forward on this.

And, if SOLR-10760 is a goal for 7.0, this issue should be a blocker for 7.0, 
in addition to being a blocker for SOLR-10760. I just marked it as a blocker 
for that issue, but have not changed this issue priority yet for 7.0.

> Add support for PointFields in FacetModule (JSON Facets)
> 
>
> Key: SOLR-9989
> URL: https://issues.apache.org/jira/browse/SOLR-9989
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: Tomás Fernández Löbbe
> Attachments: SOLR-9989.patch
>
>
> Followup task of SOLR-8396



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10851) SolrClient's should clarify expectations for solrServerUrl parameter

[JIRA]

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

Tomás Fernández Löbbe commented on SOLR-10851:
--

LGTM

> SolrClient's should clarify expectations for solrServerUrl parameter
> 
>
> Key: SOLR-10851
> URL: https://issues.apache.org/jira/browse/SOLR-10851
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: master (7.0)
>Reporter: Jason Gerlowski
>Priority: Trivial
> Fix For: master (7.0)
>
> Attachments: SOLR-10581.patch
>
>
> A recent [mailing 
> list|http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201706.mbox/%3C7742F2CD-95EA-490C-8886-726FC5CA4F95%40apple.com%3E]
>  thread brought up a common point of confusion: it's difficult for new users 
> to tell what URL/path should be given as the {{solrServerUrl}} SolrClient 
> param.
> Currently, the top-level HttpSolrClient Javadocs explain this.  But none of 
> the other SolrClient implementations provide any guidance to unfamiliar users.
> We should add consistent documentation for this parameter to each of the 
> SolrClient implementations.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (SOLR-10851) SolrClient's should clarify expectations for solrServerUrl parameter

[JIRA]

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

Tomás Fernández Löbbe reassigned SOLR-10851:


Assignee: Tomás Fernández Löbbe

> SolrClient's should clarify expectations for solrServerUrl parameter
> 
>
> Key: SOLR-10851
> URL: https://issues.apache.org/jira/browse/SOLR-10851
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: master (7.0)
>Reporter: Jason Gerlowski
>Assignee: Tomás Fernández Löbbe
>Priority: Trivial
> Fix For: master (7.0)
>
> Attachments: SOLR-10581.patch
>
>
> A recent [mailing 
> list|http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201706.mbox/%3C7742F2CD-95EA-490C-8886-726FC5CA4F95%40apple.com%3E]
>  thread brought up a common point of confusion: it's difficult for new users 
> to tell what URL/path should be given as the {{solrServerUrl}} SolrClient 
> param.
> Currently, the top-level HttpSolrClient Javadocs explain this.  But none of 
> the other SolrClient implementations provide any guidance to unfamiliar users.
> We should add consistent documentation for this parameter to each of the 
> SolrClient implementations.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-8392) SolrParam.get(String) returns String and shouldn't be used in other instanceof checks

[Mike Drob (JIRA)]

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

Mike Drob resolved SOLR-8392.
-
Resolution: Fixed

> SolrParam.get(String) returns String and shouldn't be used in other 
> instanceof checks
> -
>
> Key: SOLR-8392
> URL: https://issues.apache.org/jira/browse/SOLR-8392
> Project: Solr
>  Issue Type: Bug
>Reporter: Mike Drob
>Assignee: Mike Drob
> Fix For: master (7.0)
>
> Attachments: SOLR-8392.patch, SOLR-8392.patch
>
>
> There's a couple of places where we declare the return type of 
> solrParams.get() as an Object and then do instanceof checks for other types. 
> Since we know it will be a String, we can simplify this logic in several 
> places.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-8392) SolrParam.get(String) returns String and shouldn't be used in other instanceof checks

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8392: Remove instanceof checks on return value of SolrParam::get


> SolrParam.get(String) returns String and shouldn't be used in other 
> instanceof checks
> -
>
> Key: SOLR-8392
> URL: https://issues.apache.org/jira/browse/SOLR-8392
> Project: Solr
>  Issue Type: Bug
>Reporter: Mike Drob
>Assignee: Mike Drob
> Fix For: master (7.0)
>
> Attachments: SOLR-8392.patch, SOLR-8392.patch
>
>
> There's a couple of places where we declare the return type of 
> solrParams.get() as an Object and then do instanceof checks for other types. 
> Since we know it will be a String, we can simplify this logic in several 
> places.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10760) Remove trie field types and fields from example schemas

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-10760:
--

SOLR-9989 covers adding support for PointFields to JSON Facets. 

If we are agreed that we want to remove trie types/fields from example schemas 
for 7.0, then SOLR-9989 is a blocker for this issue. I'll mark it as such, and 
make another comment in that issue related to this.

> Remove trie field types and fields from example schemas
> ---
>
> Key: SOLR-10760
> URL: https://issues.apache.org/jira/browse/SOLR-10760
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>
> In order to make points fields the default, we should remove all trie field 
> types and fields from example schemas.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-9735) Umbrella JIRA for Auto Scaling and Cluster Management in SolrCloud

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-9735:
-

Here was the initial commit which didn't get caught by the Jira bot for 
reference:

https://github.com/apache/lucene-solr/commit/e5d8ed397ab8db3268e1de86ca5ee5fe53dc04cc

> Umbrella JIRA for Auto Scaling and Cluster Management in SolrCloud
> --
>
> Key: SOLR-9735
> URL: https://issues.apache.org/jira/browse/SOLR-9735
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Anshum Gupta
>Assignee: Shalin Shekhar Mangar
>   Original Estimate: 1,344h
>  Remaining Estimate: 1,344h
>
> As SolrCloud is now used at fairly large scale, most users end up writing 
> their own cluster management tools. We should have a framework for cluster 
> management in Solr.
> In a discussion with [~noble.paul], we outlined the following steps w.r.t. 
> the approach to having this implemented:
> * *Basic API* calls for cluster management e.g. utilize added nodes, remove a 
> node etc. These calls would need explicit invocation by the users to begin 
> with. It would also specify the {{strategy}} to use. For instance I can have 
> a strategy called {{optimizeCoreCount}} which would target to have an even 
> no:of cores in each node . The strategy could optionally take parameters as 
> well
> * *Metrics* and stats tracking e.g. qps, etc. These would be required for any 
> advanced cluster management tasks e.g. *maintain a qps of 'x'* by 
> *auto-adding a replica* (using a recipe) etc. We would need 
> collection/shard/node level views of metrics for this.
> * *Recipes*: combination of multiple sequential/parallel API calls based on 
> rules. This would be complicated specially as most of these would be long 
> running series of tasks which would either have to be rolled back or resumed 
> in case of a failure.
> * *Event based triggers* that would not require explicit cluster management 
> calls for end users.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-8392) SolrParam.get(String) returns String and shouldn't be used in other instanceof checks

[Mike Drob (JIRA)]

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

Mike Drob updated SOLR-8392:

Fix Version/s: (was: 6.0)
   master (7.0)

> SolrParam.get(String) returns String and shouldn't be used in other 
> instanceof checks
> -
>
> Key: SOLR-8392
> URL: https://issues.apache.org/jira/browse/SOLR-8392
> Project: Solr
>  Issue Type: Bug
>Reporter: Mike Drob
>Assignee: Mike Drob
> Fix For: master (7.0)
>
> Attachments: SOLR-8392.patch, SOLR-8392.patch
>
>
> There's a couple of places where we declare the return type of 
> solrParams.get() as an Object and then do instanceof checks for other types. 
> Since we know it will be a String, we can simplify this logic in several 
> places.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10778) Ant precommit task WARNINGS about unclosed resources

[Mike Drob (JIRA)]

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

Mike Drob commented on SOLR-10778:
--

[~erickerickson] - I think taking care of the warnings is a hugely valuable 
thing, despite being unglamorous.

> Ant precommit task WARNINGS about unclosed resources
> 
>
> Key: SOLR-10778
> URL: https://issues.apache.org/jira/browse/SOLR-10778
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: clients - java
>Affects Versions: 4.6
>Reporter: Andrew Musselman
>Priority: Minor
> Attachments: notclosed.txt
>
>
> During precommit we are seeing lots of warnings about resources that aren't 
> being closed, which could pose problems based on chat amongst the team. Log 
> snippet for example:
> [mkdir] Created dir: 
> /var/folders/5p/6b46rm_94dzc5m8d4v56tds4gp/T/ecj1165341501
>  [ecj-lint] Compiling 419 source files to 
> /var/folders/5p/6b46rm_94dzc5m8d4v56tds4gp/T/ecj1165341501
>  [ecj-lint] --
>  [ecj-lint] 1. WARNING in 
> /path/to/lucene-solr/solr/solrj/src/java/org/apache/solr/client/solrj/impl/LBHttpSolrClient.java
>  (at line 920)
>  [ecj-lint] new LBHttpSolrClient(httpSolrClientBuilder, httpClient, 
> solrServerUrls) :
>  [ecj-lint] 
> ^^^
>  [ecj-lint] Resource leak: '' is never closed
>  [ecj-lint] --
>  [ecj-lint] --
>  [ecj-lint] 2. WARNING in 
> /path/to/lucene-solr/solr/solrj/src/java/org/apache/solr/client/solrj/impl/StreamingBinaryResponseParser.java
>  (at line 49)
>  [ecj-lint] JavaBinCodec codec = new JavaBinCodec() {
>  [ecj-lint]  ^
>  [ecj-lint] Resource leak: 'codec' is never closed
>  [ecj-lint] --
>  [ecj-lint] --
>  [ecj-lint] 3. WARNING in 
> /path/to/lucene-solr/solr/solrj/src/java/org/apache/solr/client/solrj/request/JavaBinUpdateRequestCodec.java
>  (at line 90)
>  [ecj-lint] JavaBinCodec codec = new JavaBinCodec();
>  [ecj-lint]  ^
>  [ecj-lint] Resource leak: 'codec' is never closed
>  [ecj-lint] --
>  [ecj-lint] 4. WARNING in 
> /path/to/lucene-solr/solr/solrj/src/java/org/apache/solr/client/solrj/request/JavaBinUpdateRequestCodec.java
>  (at line 113)
>  [ecj-lint] JavaBinCodec codec = new JavaBinCodec() {
>  [ecj-lint]  ^
>  [ecj-lint] Resource leak: 'codec' is never closed



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-8392) SolrParam.get(String) returns String and shouldn't be used in other instanceof checks

[Mike Drob (JIRA)]

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

Mike Drob commented on SOLR-8392:
-

Yea, I'll take care of it.

> SolrParam.get(String) returns String and shouldn't be used in other 
> instanceof checks
> -
>
> Key: SOLR-8392
> URL: https://issues.apache.org/jira/browse/SOLR-8392
> Project: Solr
>  Issue Type: Bug
>Reporter: Mike Drob
> Fix For: 6.0
>
> Attachments: SOLR-8392.patch, SOLR-8392.patch
>
>
> There's a couple of places where we declare the return type of 
> solrParams.get() as an Object and then do instanceof checks for other types. 
> Since we know it will be a String, we can simplify this logic in several 
> places.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (SOLR-8392) SolrParam.get(String) returns String and shouldn't be used in other instanceof checks

[Mike Drob (JIRA)]

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

Mike Drob reassigned SOLR-8392:
---

Assignee: Mike Drob

> SolrParam.get(String) returns String and shouldn't be used in other 
> instanceof checks
> -
>
> Key: SOLR-8392
> URL: https://issues.apache.org/jira/browse/SOLR-8392
> Project: Solr
>  Issue Type: Bug
>Reporter: Mike Drob
>Assignee: Mike Drob
> Fix For: 6.0
>
> Attachments: SOLR-8392.patch, SOLR-8392.patch
>
>
> There's a couple of places where we declare the return type of 
> solrParams.get() as an Object and then do instanceof checks for other types. 
> Since we know it will be a String, we can simplify this logic in several 
> places.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-10835) ExportWriter only works with TrieFooFields, not FooPointFields

[JIRA]

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

Tomás Fernández Löbbe resolved SOLR-10835.
--
   Resolution: Fixed
Fix Version/s: 6.7
   master (7.0)

> ExportWriter only works with TrieFooFields, not FooPointFields
> --
>
> Key: SOLR-10835
> URL: https://issues.apache.org/jira/browse/SOLR-10835
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Tomás Fernández Löbbe
> Fix For: master (7.0), 6.7
>
> Attachments: SOLR-10835.patch, SOLR-10835.patch, SOLR-10835.patch
>
>
> ExportWriter explicitly fails hard if you attempt to use it with any of the 
> new Numeric Points based fields.
> The current failures come from explicit {{if (fieldType instanceof 
> TrieFooField)}} checks in {{ExportWriter.getFieldWriters}} -- those could 
> probably be replaced with {{instanceof FooValueFieldType}} (the numeric 
> marker interfaces) or {{getNumericType()}} but i suspect in the multivalued 
> case other problems will arise due to how ExportWriter dips into the guts of 
> DocValues and assumes SortedSetDocValues 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10835) ExportWriter only works with TrieFooFields, not FooPointFields

[JIRA]

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

Tomás Fernández Löbbe commented on SOLR-10835:
--

I did two minor changes and committed:
* Using a LongFunction in ExportWriter to convert DV long to the correct type 
(instead of always calling the switch).
* Modified the random test to always run the same queries (it was running many 
times the same queries before, which made no sense)


> ExportWriter only works with TrieFooFields, not FooPointFields
> --
>
> Key: SOLR-10835
> URL: https://issues.apache.org/jira/browse/SOLR-10835
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-10835.patch, SOLR-10835.patch, SOLR-10835.patch
>
>
> ExportWriter explicitly fails hard if you attempt to use it with any of the 
> new Numeric Points based fields.
> The current failures come from explicit {{if (fieldType instanceof 
> TrieFooField)}} checks in {{ExportWriter.getFieldWriters}} -- those could 
> probably be replaced with {{instanceof FooValueFieldType}} (the numeric 
> marker interfaces) or {{getNumericType()}} but i suspect in the multivalued 
> case other problems will arise due to how ExportWriter dips into the guts of 
> DocValues and assumes SortedSetDocValues 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10835) ExportWriter only works with TrieFooFields, not FooPointFields

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10835:


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

SOLR-10835: Add support for point fields in Export Handler


> ExportWriter only works with TrieFooFields, not FooPointFields
> --
>
> Key: SOLR-10835
> URL: https://issues.apache.org/jira/browse/SOLR-10835
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-10835.patch, SOLR-10835.patch, SOLR-10835.patch
>
>
> ExportWriter explicitly fails hard if you attempt to use it with any of the 
> new Numeric Points based fields.
> The current failures come from explicit {{if (fieldType instanceof 
> TrieFooField)}} checks in {{ExportWriter.getFieldWriters}} -- those could 
> probably be replaced with {{instanceof FooValueFieldType}} (the numeric 
> marker interfaces) or {{getNumericType()}} but i suspect in the multivalued 
> case other problems will arise due to how ExportWriter dips into the guts of 
> DocValues and assumes SortedSetDocValues 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10751) Master/Slave IndexVersion conflict

[JIRA]

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

Tomás Fernández Löbbe updated SOLR-10751:
-
Description: 
I’ve been looking at some failures in the replica types tests. One strange 
failure I noticed is, master and slave share the same version, but have 
different generation. The IndexFetcher code does more or less this:
{code}
masterVersion = fetchMasterVersion()
masterGeneration = fetchMasterGeneration()

if (masterVersion == 0 && slaveGeneration != 0 && forceReplication) {
   delete my index
   commit locally
   return
} 
if (masterVersion != slaveVersion) {
  fetchIndexFromMaster(masterGeneration)
} else {
  //do nothing, master and slave are in sync.
}
{code}
The problem I see happens with this sequence of events:

delete index in master (not a DBQ=\*:\*, I mean a complete removal of the index 
files and reload of the core)
replication happens in slave (sees a version 0, deletes local index and commit)
add document in master and commit

if the commit in master and in the slave happen at the same millisecond*, they 
both end up with the same version, but different indices. 
I think that in addition of checking for the same version, we should validate 
that slave and master have the same generation and If not, consider them not in 
sync, and proceed to the replication.
True, this is a situation that's difficult to happen in a real prod environment 
and it's more likely to affect tests, but I think the change makes sense. 


  was:
I’ve been looking at some failures in the replica types tests. One strange 
failure I noticed is, master and slave share the same version, but have 
different generation. The IndexFetcher code does more or less this:
{code}
masterVersion = fetchMasterVersion()
masterGeneration = fetchMasterGeneration()

if (masterVersion == 0 && slaveGeneration != 0 && forceReplication) {
   delete my index
   commit locally
   return
} 
if (masterVersion != slaveVersion) {
  fetchIndexFromMaster(masterGeneration)
} else {
  //do nothing, master and slave are in sync.
}
{code}
The problem I see happens with this sequence of events:

delete index in master (not a DBQ=*:*, I mean a complete removal of the index 
files and reload of the core)
replication happens in slave (sees a version 0, deletes local index and commit)
add document in master and commit

if the commit in master and in the slave happen at the same millisecond*, they 
both end up with the same version, but different indices. 
I think that in addition of checking for the same version, we should validate 
that slave and master have the same generation and If not, consider them not in 
sync, and proceed to the replication.
True, this is a situation that's difficult to happen in a real prod environment 
and it's more likely to affect tests, but I think the change makes sense. 



> Master/Slave IndexVersion conflict
> --
>
> Key: SOLR-10751
> URL: https://issues.apache.org/jira/browse/SOLR-10751
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (7.0)
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-10751.patch
>
>
> I’ve been looking at some failures in the replica types tests. One strange 
> failure I noticed is, master and slave share the same version, but have 
> different generation. The IndexFetcher code does more or less this:
> {code}
> masterVersion = fetchMasterVersion()
> masterGeneration = fetchMasterGeneration()
> if (masterVersion == 0 && slaveGeneration != 0 && forceReplication) {
>delete my index
>commit locally
>return
> } 
> if (masterVersion != slaveVersion) {
>   fetchIndexFromMaster(masterGeneration)
> } else {
>   //do nothing, master and slave are in sync.
> }
> {code}
> The problem I see happens with this sequence of events:
> delete index in master (not a DBQ=\*:\*, I mean a complete removal of the 
> index files and reload of the core)
> replication happens in slave (sees a version 0, deletes local index and 
> commit)
> add document in master and commit
> if the commit in master and in the slave happen at the same millisecond*, 
> they both end up with the same version, but different indices. 
> I think that in addition of checking for the same version, we should validate 
> that slave and master have the same generation and If not, consider them not 
> in sync, and proceed to the replication.
> True, this is a situation that's difficult to happen in a real prod 
> environment and it's more likely to affect tests, but I think the change 
> makes sense. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: 

[jira] [Commented] (SOLR-10835) ExportWriter only works with TrieFooFields, not FooPointFields

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10835:


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

SOLR-10835: Add support for point fields in Export Handler


> ExportWriter only works with TrieFooFields, not FooPointFields
> --
>
> Key: SOLR-10835
> URL: https://issues.apache.org/jira/browse/SOLR-10835
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-10835.patch, SOLR-10835.patch, SOLR-10835.patch
>
>
> ExportWriter explicitly fails hard if you attempt to use it with any of the 
> new Numeric Points based fields.
> The current failures come from explicit {{if (fieldType instanceof 
> TrieFooField)}} checks in {{ExportWriter.getFieldWriters}} -- those could 
> probably be replaced with {{instanceof FooValueFieldType}} (the numeric 
> marker interfaces) or {{getNumericType()}} but i suspect in the multivalued 
> case other problems will arise due to how ExportWriter dips into the guts of 
> DocValues and assumes SortedSetDocValues 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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 # 4068 - Unstable!

[Policeman Jenkins Server]

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

5 tests failed.
FAILED:  org.apache.solr.cloud.CustomCollectionTest.testCustomCollectionsAPI

Error Message:
Could not find collection : implicitcoll

Stack Trace:
org.apache.solr.common.SolrException: Could not find collection : implicitcoll
at 
__randomizedtesting.SeedInfo.seed([F935F4BC8C8BF33D:93D47AD7B1114545]:0)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:194)
at 
org.apache.solr.cloud.SolrCloudTestCase.getCollectionState(SolrCloudTestCase.java:247)
at 
org.apache.solr.cloud.CustomCollectionTest.testCustomCollectionsAPI(CustomCollectionTest.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
org.apache.solr.cloud.DeleteReplicaTest.deleteReplicaByCountForAllShards

Error Message:
Expected two shards with two replicas each null Live Nodes: 

[jira] [Assigned] (SOLR-9526) data_driven configs defaults to "strings" for unmapped fields, makes most fields containing "textual content" unsearchable, breaks tutorial examples

[JIRA]

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

Jan Høydahl reassigned SOLR-9526:
-

Assignee: Jan Høydahl

> data_driven configs defaults to "strings" for unmapped fields, makes most 
> fields containing "textual content" unsearchable, breaks tutorial examples
> 
>
> Key: SOLR-9526
> URL: https://issues.apache.org/jira/browse/SOLR-9526
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Jan Høydahl
> Attachments: SOLR-9526.patch, SOLR-9526.patch
>
>
> James Pritchett pointed out on the solr-user list that this sample query from 
> the quick start tutorial matched no docs (even though the tutorial text says 
> "The above request returns only one document")...
> http://localhost:8983/solr/gettingstarted/select?wt=json=true=name:foundation
> The root problem seems to be that the add-unknown-fields-to-the-schema chain 
> in data_driven_schema_configs is configured with...
> {code}
> strings
> {code}
> ...and the "strings" type uses StrField and is not tokenized.
> 
> Original thread: 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201609.mbox/%3ccac-n2zrpsspfnk43agecspchc5b-0ff25xlfnzogyuvyg2d...@mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-9526) data_driven configs defaults to "strings" for unmapped fields, makes most fields containing "textual content" unsearchable, breaks tutorial examples

[JIRA]

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

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

What do folks think about the approach taken in the patch? I'm thinking about 
updating it to apply to master.

> data_driven configs defaults to "strings" for unmapped fields, makes most 
> fields containing "textual content" unsearchable, breaks tutorial examples
> 
>
> Key: SOLR-9526
> URL: https://issues.apache.org/jira/browse/SOLR-9526
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
> Attachments: SOLR-9526.patch, SOLR-9526.patch
>
>
> James Pritchett pointed out on the solr-user list that this sample query from 
> the quick start tutorial matched no docs (even though the tutorial text says 
> "The above request returns only one document")...
> http://localhost:8983/solr/gettingstarted/select?wt=json=true=name:foundation
> The root problem seems to be that the add-unknown-fields-to-the-schema chain 
> in data_driven_schema_configs is configured with...
> {code}
> strings
> {code}
> ...and the "strings" type uses StrField and is not tokenized.
> 
> Original thread: 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201609.mbox/%3ccac-n2zrpsspfnk43agecspchc5b-0ff25xlfnzogyuvyg2d...@mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10874) FloatPayloadValueSource throws assertion error if debug=true

[Michael Kosten (JIRA)]

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

Michael Kosten updated SOLR-10874:
--
Attachment: SOLR-10874.patch

Here's a patch that fixes this issue on Solr 6.6, including adding to an 
existing test. 

> FloatPayloadValueSource throws assertion error if debug=true
> 
>
> Key: SOLR-10874
> URL: https://issues.apache.org/jira/browse/SOLR-10874
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Affects Versions: 6.6
>Reporter: Michael Kosten
>Priority: Minor
> Attachments: SOLR-10874.patch
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Using the new payload function will fail with an assertion error if the debug 
> parameter is included in the query. This is caused by the floatValue method 
> in FloatPayloadValueSource being called for the same doc id twice in a row.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-10874) FloatPayloadValueSource throws assertion error if debug=true

[Michael Kosten (JIRA)]

Michael Kosten created SOLR-10874:
-

 Summary: FloatPayloadValueSource throws assertion error if 
debug=true
 Key: SOLR-10874
 URL: https://issues.apache.org/jira/browse/SOLR-10874
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: search
Affects Versions: 6.6
Reporter: Michael Kosten
Priority: Minor


Using the new payload function will fail with an assertion error if the debug 
parameter is included in the query. This is caused by the floatValue method in 
FloatPayloadValueSource being called for the same doc id twice in a row.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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 # 1323 - Failure

[Apache Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.lucene.search.TestInetAddressRangeQueries.testRandomBig

Error Message:
Java heap space

Stack Trace:
java.lang.OutOfMemoryError: Java heap space
at 
__randomizedtesting.SeedInfo.seed([6AE5E766A0153ED9:EDB29AE9314C4259]:0)
at 
org.apache.lucene.util.bkd.HeapPointWriter.writePackedValue(HeapPointWriter.java:107)
at 
org.apache.lucene.util.bkd.HeapPointWriter.append(HeapPointWriter.java:128)
at org.apache.lucene.util.bkd.PointReader.split(PointReader.java:74)
at org.apache.lucene.util.bkd.BKDWriter.build(BKDWriter.java:1791)
at org.apache.lucene.util.bkd.BKDWriter.build(BKDWriter.java:1805)
at org.apache.lucene.util.bkd.BKDWriter.build(BKDWriter.java:1805)
at org.apache.lucene.util.bkd.BKDWriter.build(BKDWriter.java:1805)
at org.apache.lucene.util.bkd.BKDWriter.finish(BKDWriter.java:1008)
at 
org.apache.lucene.codecs.lucene60.Lucene60PointsWriter.writeField(Lucene60PointsWriter.java:130)
at 
org.apache.lucene.codecs.PointsWriter.mergeOneField(PointsWriter.java:62)
at 
org.apache.lucene.codecs.lucene60.Lucene60PointsWriter.merge(Lucene60PointsWriter.java:223)
at 
org.apache.lucene.index.SegmentMerger.mergePoints(SegmentMerger.java:187)
at org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:136)
at 
org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4361)
at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3933)
at 
org.apache.lucene.index.SerialMergeScheduler.merge(SerialMergeScheduler.java:40)
at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:2082)
at 
org.apache.lucene.index.IndexWriter.doAfterSegmentFlushed(IndexWriter.java:4992)
at 
org.apache.lucene.index.DocumentsWriter$MergePendingEvent.process(DocumentsWriter.java:731)
at 
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:5030)
at 
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:5021)
at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1573)
at 
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1315)
at 
org.apache.lucene.search.BaseRangeFieldQueryTestCase.verify(BaseRangeFieldQueryTestCase.java:190)
at 
org.apache.lucene.search.BaseRangeFieldQueryTestCase.doTestRandom(BaseRangeFieldQueryTestCase.java:160)
at 
org.apache.lucene.search.BaseRangeFieldQueryTestCase.testRandomBig(BaseRangeFieldQueryTestCase.java:75)
at 
org.apache.lucene.search.TestInetAddressRangeQueries.testRandomBig(TestInetAddressRangeQueries.java:81)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)


FAILED:  org.apache.solr.TestDistributedSearch.test

Error Message:
Captured an uncaught exception in thread: Thread[id=44906, name=Thread-33143, 
state=RUNNABLE, group=TGRP-TestDistributedSearch]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=44906, name=Thread-33143, state=RUNNABLE, 
group=TGRP-TestDistributedSearch]
at 
__randomizedtesting.SeedInfo.seed([96F460804B43D487:1EA05F5AE5BFB97F]:0)
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:39331//collection1: 
java.lang.NullPointerException
at 
org.apache.solr.search.grouping.distributed.responseprocessor.StoredFieldsShardResponseProcessor.process(StoredFieldsShardResponseProcessor.java:41)
at 
org.apache.solr.handler.component.QueryComponent.handleGroupedResponses(QueryComponent.java:768)
at 
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:751)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:178)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2487)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:722)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:528)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:374)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:318)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
at 

[jira] [Updated] (SOLR-10704) REPLACENODE can make the collection lost data which replicaFactor is 1

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-10704:
-
Attachment: SOLR-10704.patch

This patch waits for all replicas that we're moving that were leaders (which 
covers also the case of replicationFactor=1) until they are recovered and only 
then proceeds to deleting the old replicas.

> REPLACENODE can make the collection lost data which replicaFactor is 1 
> ---
>
> Key: SOLR-10704
> URL: https://issues.apache.org/jira/browse/SOLR-10704
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 6.2
> Environment: Red Hat 4.8.3-9, JDK 1.8.0_121
>Reporter: Daisy.Yuan
>Assignee: Andrzej Bialecki 
> Fix For: master (7.0), 6.7
>
> Attachments: 219.log, SOLR-10704.patch
>
>
> When some replicas which the relative collection's replicaFactor is 1, it 
> will lost data after executing the REPLACENODE cmd. 
> It may be the new replica on the target node does not complete revovering, 
> but the old replica on the source node  was already be deleted.
> At last the target revocery failed for the following exception:
> 2017-05-18 17:08:48,587 | ERROR | 
> recoveryExecutor-3-thread-2-processing-n:192.168.229.137:21103_solr 
> x:replace-hdfs-coll1_shard1_replica2 s:shard1 c:replace-hdfs-coll1 
> r:core_node3 | Error while trying to recover. 
> core=replace-hdfs-coll1_shard1_replica2:java.lang.NullPointerException
> at org.apache.solr.update.PeerSync.alreadyInSync(PeerSync.java:339)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-10873) Explore a utility for periodically checking the document counts for replicas of a shard

[Erick Erickson (JIRA)]

Erick Erickson created SOLR-10873:
-

 Summary: Explore a utility for periodically checking the document 
counts for replicas of a shard
 Key: SOLR-10873
 URL: https://issues.apache.org/jira/browse/SOLR-10873
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Erick Erickson


We've had several situations "in the field" and on the user's list where the 
number of documents on different replicas of the same shard differ. I've also 
seen situations where the numbers are wildly different (two orders of 
magnitude). I can force this situation by, say, taking down nodes, adding 
replicas that become the leader then starting the nodes back up. But it doesn't 
matter whether the discrepancy is a result of "pilot error" or a problem with 
the code, in either case it would be useful to flag it.

Straw-man proposal:
We create a processor (modeled on DocExpirationUpdateProcessorFactory perhaps?) 
that periodically wakes up and checks that each replica in the given shard has 
the same document count (and perhaps other checks TBD?). Send some kind of 
notification if a problem was detected.

Issues:
1> this will require some way to deal with the differing commit times. 
1a> If we require a timestamp on each document we could check the config file 
to see the autocommit interval and, say, check NOW-(2 x opensearcher interval). 
In that case the config would just require the field to use be specified.
1b> we could require that part of the configuration is a query to use to check 
document counts. I kind of like this one.

2> How to let the admins know a discrepancy was found? e-mail? ERROR level log 
message? Other?

3> How does this fit into the autoscaling initiative? This is a "monitor the 
system and do something" item. If we go forward with this we should do it with 
an eye toward fitting it in that framework.
3a> Is there anything we can do to auto-correct this situation? Auto-correction 
could be tricky. Heuristics like "make the replica with the most documents the 
leader and force full index replication on all the replicas that don't agree" 
seem dangerous. 

4> How to keep the impact minimal? The simple approach would be for each 
replica to check all other replicas in the shard. So say there are 10 replicas 
on a single shard, that would be 90 queries. It would suffice for just one of 
those to check the other 9, not have all 10 check the other nine. Maybe 
restrict the checker to be the leader? Or otherwise just make it one 
replica/shard that does the checking?

5> It's probably useful to add a collections API call to fire this off 
manually. Or maybe as part of CHECKSTATUS?

What do people think?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10871) Remove monospace text from headings in Ref Guide

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10871:


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

SOLR-10871: remove backticks for monospace type in headings


> Remove monospace text from headings in Ref Guide
> 
>
> Key: SOLR-10871
> URL: https://issues.apache.org/jira/browse/SOLR-10871
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
> Fix For: master (7.0)
>
> Attachments: monospace-in-header-new.png, 
> monospace-in-header-old.png, ref-guide-monospace-headings.txt, Screen Shot 
> 2017-06-12 at 11.20.04 AM.png
>
>
> Monospace text doesn't look great in section headings in the PDF - the font 
> color is different and the size is smaller. With the old way of generating 
> the PDF we could make it the same color & adjust the font size so it was less 
> jarring. We don't have that option now, so the difference is much more 
> pronounced.
> I found 148 instances of this in 40 files. I think we can make that "normal" 
> text without losing any important information for the reader.
> Attaching screenshots of what it used to look like and what it now looks 
> like, to illustrate the difference.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10865) parameter processor=Template doesn't invoke TemplateUpdateProcessorFactory.

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-10865:

Attachment: SOLR-10865.patch

The URPFactories are not allowed to Lazy Initialized and hence inform(Solrcore 
...) never gets called for URPs which are not defined in SolrConfig. The one 
mentioned in config, get through their inform(...) at core creation. 

If we are making URPs free of config, we need to allow processors to be 
initialized lazy (after core creation) and instead of using flag runtimeLib 
flag to get LazyPluginHolder, we can pass _startup=true_, justifiable and neat.

Attached patch for the same. Some minor corrections, blank spaces / lines here 
and there. 

> parameter processor=Template doesn't invoke TemplateUpdateProcessorFactory.
> ---
>
> Key: SOLR-10865
> URL: https://issues.apache.org/jira/browse/SOLR-10865
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Affects Versions: master (7.0)
>Reporter: Amrit Sarkar
> Attachments: SOLR-10865.patch, SOLR-10865.patch, SOLR-10865.patch
>
>
> Ref docs::
> {quote}
> The TemplateUpdateProcessorFactory can be used to add new fields to documents 
> based on a template pattern.
> This can be used directly in a request without any configuration. To enable 
> this processor, use the parameter processor=Template.
> {quote}
> Sample curl::
> {code}
> curl -X POST -H 'Content-Type:application/json' 
> 'http://localhost:8983/solr/gettingstarted/update/json/docs?processor=Template=fullName_s:AmritSarkar=true'
>  --data-binary '{"id": 1,"title": "titleA"}'
> {code}
> I am receiving exception::
> {code}
> 
> 
> 400 name="QTime">3 name="error-class">org.apache.solr.common.SolrException name="root-error-class">org.apache.solr.common.SolrException name="msg">No such processor Template400
> 
> {code}
> {code}
> ERROR - 2017-06-10 07:39:51.598; [c:gettingstarted s:shard2 r:core_node1 
> x:gettingstarted_shard2_replica_n1] org.apache.solr.common.SolrException; 
> org.apache.solr.common.SolrException: No such processor Template
>   at 
> org.apache.solr.update.processor.UpdateRequestProcessorChain.getReqProcessors(UpdateRequestProcessorChain.java:286)
>   at 
> org.apache.solr.update.processor.UpdateRequestProcessorChain.constructChain(UpdateRequestProcessorChain.java:235)
> {code}
> I looked into how the testclass has been created::
> TemplateUpdateProcessorTest::
> {code}
>   public void testSimple() throws Exception {
> AddUpdateCommand cmd = new AddUpdateCommand(new 
> LocalSolrQueryRequest(null,
> new ModifiableSolrParams()
> .add("processor", "Template")
> .add("Template.field", "id:${firstName}_${lastName}")
> .add("Template.field", "another:${lastName}_${firstName}")
> .add("Template.field", "missing:${lastName}_${unKnown}")
> ));
> cmd.solrDoc = new SolrInputDocument();
> cmd.solrDoc.addField("firstName", "Tom");
> cmd.solrDoc.addField("lastName", "Cruise");
> new TemplateUpdateProcessorFactory().getInstance(cmd.getReq(), new 
> SolrQueryResponse(), null).processAdd(cmd);
> assertEquals("Tom_Cruise", cmd.solrDoc.getFieldValue("id"));
> assertEquals("Cruise_Tom", cmd.solrDoc.getFieldValue("another"));
> assertEquals("Cruise_", cmd.solrDoc.getFieldValue("missing"));
>   }
> {code}
> *There is no test to check whether _processor=Template_ works or not*, 
> TemplateUpdateProcessorFactory() object is EXPLICITLY created to getInstance 
> and do processing on the updates.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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_131) - Build # 19849 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19849/
Java: 32bit/jdk1.8.0_131 -server -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.update.AutoCommitTest.testCommitWithin

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([DB26C0F7E2F28EBB:61F4AF8F61DC60AE]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:890)
at 
org.apache.solr.update.AutoCommitTest.testCommitWithin(AutoCommitTest.java:353)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=1]
xml response was: 

00


request was:q=id:529=standard=0=20=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:883)
... 40 more




Build Log:
[...truncated 12118 lines...]
   [junit4] Suite: org.apache.solr.update.AutoCommitTest
   

[jira] [Commented] (SOLR-10858) Make UUIDUpdateProcessorFactory as Runtime URP; take params(s) with request

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-10858:
-

I see [~noble.paul].  You didn't mention SOLR-9565 just now but I think it's 
pertinent?  Perhaps all these issues recently created of this nature should 
reference that issue show we could discuss the broad approach there instead of 
on issues to specific URPs?

> Make UUIDUpdateProcessorFactory as Runtime URP; take params(s) with request
> ---
>
> Key: SOLR-10858
> URL: https://issues.apache.org/jira/browse/SOLR-10858
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Reporter: Amrit Sarkar
>Priority: Minor
> Attachments: SOLR-10858.patch, SOLR-10858.patch, SOLR-10858.patch, 
> SOLR-10858.patch
>
>
> We are trying to get rid of processor definitions in SolrConfig for all URPs 
> and take parameters in the request itself.
> UUIDUpdateProcessorFactory will be able to execute by sample curl like below:
> {code}
>  curl -X POST -H Content-Type: application/json  
> http://localhost:8983/solr/test/update/json/docs?processor=UUID=id=true
>  --data-binary {"title": "titleA"}
> {code}
> {code}
>  curl -X POST -H Content-Type: application/json  
> http://localhost:8983/solr/test/update/json/docs?processor=UUID=true 
> --data-binary {"id":"1","title": "titleA"}
> {code}
> {code}
>  curl -X POST -H Content-Type: application/json  
> http://localhost:8983/solr/test/update/json/docs?processor=UUID=id=true
>  --data-binary {"id":"1","title": "titleA"}
> {code}
> Configuration for UUIDUpdateProcessorFactory in solrconfig.xml is optional.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10835) ExportWriter only works with TrieFooFields, not FooPointFields

[JIRA]

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

Tomás Fernández Löbbe commented on SOLR-10835:
--

I've been running TestExportWriter over the weekend and I've seen no failures. 
I'll commit the last patch to master and 6.x (not sure if there will be a 6.7, 
but if there isn't, we should update CHANGES.txt since there are many things 
listed as 6.7 already)

> ExportWriter only works with TrieFooFields, not FooPointFields
> --
>
> Key: SOLR-10835
> URL: https://issues.apache.org/jira/browse/SOLR-10835
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-10835.patch, SOLR-10835.patch, SOLR-10835.patch
>
>
> ExportWriter explicitly fails hard if you attempt to use it with any of the 
> new Numeric Points based fields.
> The current failures come from explicit {{if (fieldType instanceof 
> TrieFooField)}} checks in {{ExportWriter.getFieldWriters}} -- those could 
> probably be replaced with {{instanceof FooValueFieldType}} (the numeric 
> marker interfaces) or {{getNumericType()}} but i suspect in the multivalued 
> case other problems will arise due to how ExportWriter dips into the guts of 
> DocValues and assumes SortedSetDocValues 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10871) Remove monospace text from headings in Ref Guide

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10871:
---

bq. How about this - I'll commit the change to remove them all to master and 
tomorrow we can see how they look in the Jenkins build 
(https://builds.apache.org/job/Solr-reference-guide-master/). If it's 
dissatisfactory, we'll revert the commit and use italics instead.

+1

> Remove monospace text from headings in Ref Guide
> 
>
> Key: SOLR-10871
> URL: https://issues.apache.org/jira/browse/SOLR-10871
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
> Fix For: master (7.0)
>
> Attachments: monospace-in-header-new.png, 
> monospace-in-header-old.png, ref-guide-monospace-headings.txt, Screen Shot 
> 2017-06-12 at 11.20.04 AM.png
>
>
> Monospace text doesn't look great in section headings in the PDF - the font 
> color is different and the size is smaller. With the old way of generating 
> the PDF we could make it the same color & adjust the font size so it was less 
> jarring. We don't have that option now, so the difference is much more 
> pronounced.
> I found 148 instances of this in 40 files. I think we can make that "normal" 
> text without losing any important information for the reader.
> Attaching screenshots of what it used to look like and what it now looks 
> like, to illustrate the difference.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Better error message? (old version and new version are not comparable)

[Tomas Fernandez Lobbe]

Hi SG, 
You should create a Jira issue, then if you can rename your PR to include the 
Jira issue code in the title (that’s the way to link the Jira issue to the 
Github PR). Also, take a look at https://wiki.apache.org/solr/HowToContribute.

Tomás

> On Jun 12, 2017, at 9:14 AM, S G  wrote:
> 
> Hi Zheng,
> 
> We are using 6.3 version.
> I have created a small PR that addresses this issue of better error message.
> Please merge the same if it looks ok.
> https://github.com/apache/lucene-solr/pull/212/files 
> 
> 
> Thanks
> SG
> 
> 
> On Sun, Jun 11, 2017 at 8:45 PM, Zheng Lin Edwin Yeo  > wrote:
> Which version of Solr are yo using?
> 
> Also, I believe you should send this message to the user list at 
> solr-u...@lucene.apache.org 
> 
> Regards,
> Edwin
> 
> On 12 June 2017 at 02:45, S G  > wrote:
> Hi,
> 
> Recently I ran into an issue where the logs were showing the following:
> 
> 
> org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
> server at http://solr-host:8983/solr/loadtest_shard1_replica1 
> : old version and new 
> version are not comparable: class java.lang.Long vs class java.lang.Integer: 
> null
> at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:765)
>  ~[load-client.jar]
> at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1173)
>  ~[load-client.jar]
> at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1062)
>  ~[load-client.jar]
> at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1004)
>  ~[load-client.jar]
> at 
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149) 
> ~[load-client.jar]
> at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:106) 
> ~[load-client.jar]
> at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:123) 
> ~[load-client.jar]
> at WriteLoadTest$IndexWorker.addDocsToSolr(WriteLoadTest.java:629) 
> [load-client.jar]
> at WriteLoadTest$IndexWorker.run(WriteLoadTest.java:573) 
> [load-client.jar]
> Caused by: 
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
> from server at http://solr-host:8983/solr/loadtest_shard1_replica1 
> : old version and new 
> version are not comparable: class java.lang.Long vs class java.lang.Integer: 
> null
> at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:593)
>  ~[load-client.jar]
> at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
>  ~[load-client.jar]
> at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:251)
>  ~[load-client.jar]
> at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:435)
>  ~[load-client.jar]
> at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:387)
>  ~[load-client.jar]
> at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.lambda$directUpdate$0(CloudSolrClient.java:742)
>  ~[load-client.jar]
> at 
> org.apache.solr.client.solrj.impl.CloudSolrClient$$Lambda$8/745780984.call(Unknown
>  Source) ~[?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[?:1.8.0_51]
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
>  ~[load-client.jar]
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$$Lambda$7/725894523.run(Unknown
>  Source) ~[?:?]
> ... 3 more
> 
> 
> The message above is not clear at all.
> Which document is it talking about?
> I have so many documents being ingested and it's hard to figure out the same.
> It would have been nice if the message included a document ID too.
> 
> 
> Thanks
> SG
> 
> 
> 
> 
> 

[jira] [Commented] (SOLR-10871) Remove monospace text from headings in Ref Guide

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-10871:
--

How about this - I'll commit the change to remove them all to master and 
tomorrow we can see how they look in the Jenkins build 
(https://builds.apache.org/job/Solr-reference-guide-master/). If it's 
dissatisfactory, we'll revert the commit and use italics instead.

> Remove monospace text from headings in Ref Guide
> 
>
> Key: SOLR-10871
> URL: https://issues.apache.org/jira/browse/SOLR-10871
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
> Fix For: master (7.0)
>
> Attachments: monospace-in-header-new.png, 
> monospace-in-header-old.png, ref-guide-monospace-headings.txt, Screen Shot 
> 2017-06-12 at 11.20.04 AM.png
>
>
> Monospace text doesn't look great in section headings in the PDF - the font 
> color is different and the size is smaller. With the old way of generating 
> the PDF we could make it the same color & adjust the font size so it was less 
> jarring. We don't have that option now, so the difference is much more 
> pronounced.
> I found 148 instances of this in 40 files. I think we can make that "normal" 
> text without losing any important information for the reader.
> Attaching screenshots of what it used to look like and what it now looks 
> like, to illustrate the difference.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10871) Remove monospace text from headings in Ref Guide

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10871:
---

bq. If we do decide to continue including some form of highlighting, I'd vote 
for underlined.

In an offline discussion, [~ctargett] mentioned that underlined text usually 
means hyperlinks, and pointed me to 
[https://github.com/asciidoctor/asciidoctor/issues/867], an asciidoctor issue 
that includes a comment describing why using underlines in digital pubs is a 
bad idea.  In part:

{quote}
All the major style guides (Chicago, New York) explicitly advise against the 
use of the underline, labeling it as legacy, and the HTML5 specification 
discourage its use in normal text to avoid confusion with hyperlinks. Text 
should be emphasized using italics (preferred), bold (used sparingly) or an 
alternative styling that is still accessible.
{quote}

I agree, and I withdraw my preference for underscores (if any highlighting ends 
up being used).

> Remove monospace text from headings in Ref Guide
> 
>
> Key: SOLR-10871
> URL: https://issues.apache.org/jira/browse/SOLR-10871
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
> Fix For: master (7.0)
>
> Attachments: monospace-in-header-new.png, 
> monospace-in-header-old.png, ref-guide-monospace-headings.txt, Screen Shot 
> 2017-06-12 at 11.20.04 AM.png
>
>
> Monospace text doesn't look great in section headings in the PDF - the font 
> color is different and the size is smaller. With the old way of generating 
> the PDF we could make it the same color & adjust the font size so it was less 
> jarring. We don't have that option now, so the difference is much more 
> pronounced.
> I found 148 instances of this in 40 files. I think we can make that "normal" 
> text without losing any important information for the reader.
> Attaching screenshots of what it used to look like and what it now looks 
> like, to illustrate the difference.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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 # 890 - Unstable!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testParallelCommitStream

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

Stack Trace:
java.lang.AssertionError: expected:<5> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([17F9173E2B67B476:3713753EB726593A]: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.client.solrj.io.stream.StreamExpressionTest.testParallelCommitStream(StreamExpressionTest.java:4582)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




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

[jira] [Comment Edited] (SOLR-10871) Remove monospace text from headings in Ref Guide

[Steve Rowe (JIRA)]

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

Steve Rowe edited comment on SOLR-10871 at 6/12/17 4:55 PM:


Attaching what {{egrep -r --include="\*.adoc" '^=+.*`'}} finds for me on master 
under {{solr/solr-ref-guide/}}: 188 instances, of which 103 include "aram" 
(54%).

For those 54%, I agree that "The XXX Parameter" wouldn't benefit much from 
highlighting XXX.

Similarly, 28 of the headings (14%) consist of a heading that is entirely in 
monospace.  These  also wouldn't benefit much from highlighting.

Looking at the remaining 57 (30%), I don't see any that would be irreparably 
harmed by removing all highlighting.  In some cases, using italics for symbols 
(e.g. {{!}}, {{||}}, {{+}}, {{-}}, {{&&}}) might actual make them look worse.

On balance, I guess I'm +1 to removing all highlighting (rather than 
substituting e.g. italics).



was (Author: steve_rowe):
Attaching what {{egrep -r --include="*.adoc" '^=+.*`}} finds for me on master 
under {{solr/solr-ref-guide/}}: 188 instances, of which 103 include "aram" 
(54%).

For those 54%, I agree that "The XXX Parameter" wouldn't benefit much from 
highlighting XXX.

Similarly, 28 of the headings (14%) consist of a heading that is entirely in 
monospace.  These  also wouldn't benefit much from highlighting.

Looking at the remaining 57 (30%), I don't see any that would be irreparably 
harmed by removing all highlighting.  In some cases, using italics for symbols 
(e.g. {{!}}, {{||}}, {{+}}, {{-}}, {{&&}}) might actual make them look worse.

On balance, I guess I'm +1 to removing all highlighting (rather than 
substituting e.g. italics).


> Remove monospace text from headings in Ref Guide
> 
>
> Key: SOLR-10871
> URL: https://issues.apache.org/jira/browse/SOLR-10871
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
> Fix For: master (7.0)
>
> Attachments: monospace-in-header-new.png, 
> monospace-in-header-old.png, ref-guide-monospace-headings.txt, Screen Shot 
> 2017-06-12 at 11.20.04 AM.png
>
>
> Monospace text doesn't look great in section headings in the PDF - the font 
> color is different and the size is smaller. With the old way of generating 
> the PDF we could make it the same color & adjust the font size so it was less 
> jarring. We don't have that option now, so the difference is much more 
> pronounced.
> I found 148 instances of this in 40 files. I think we can make that "normal" 
> text without losing any important information for the reader.
> Attaching screenshots of what it used to look like and what it now looks 
> like, to illustrate the difference.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10871) Remove monospace text from headings in Ref Guide

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-10871:
--
Attachment: ref-guide-monospace-headings.txt

Attaching what {{egrep -r --include="*.adoc" '^=+.*`}} finds for me on master 
under {{solr/solr-ref-guide/}}: 188 instances, of which 103 include "aram" 
(54%).

For those 54%, I agree that "The XXX Parameter" wouldn't benefit much from 
highlighting XXX.

Similarly, 28 of the headings (14%) consist of a heading that is entirely in 
monospace.  These  also wouldn't benefit much from highlighting.

Looking at the remaining 57 (30%), I don't see any that would be irreparably 
harmed by removing all highlighting.  In some cases, using italics for symbols 
(e.g. {{!}}, {{||}}, {{+}}, {{-}}, {{&&}}) might actual make them look worse.

On balance, I guess I'm +1 to removing all highlighting (rather than 
substituting e.g. italics).


> Remove monospace text from headings in Ref Guide
> 
>
> Key: SOLR-10871
> URL: https://issues.apache.org/jira/browse/SOLR-10871
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
> Fix For: master (7.0)
>
> Attachments: monospace-in-header-new.png, 
> monospace-in-header-old.png, ref-guide-monospace-headings.txt, Screen Shot 
> 2017-06-12 at 11.20.04 AM.png
>
>
> Monospace text doesn't look great in section headings in the PDF - the font 
> color is different and the size is smaller. With the old way of generating 
> the PDF we could make it the same color & adjust the font size so it was less 
> jarring. We don't have that option now, so the difference is much more 
> pronounced.
> I found 148 instances of this in 40 files. I think we can make that "normal" 
> text without losing any important information for the reader.
> Attaching screenshots of what it used to look like and what it now looks 
> like, to illustrate the difference.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10857) Solr loads UNLOADed core on request

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10857:


Commit 59af129548d50c07b3b9b9f879a7105b5dfcd3d8 in lucene-solr's branch 
refs/heads/branch_6_6 from [~erickerickson]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=59af129 ]

SOLR-10857: Solr loads UNLOADed core on request, cleaned up printStackTrace

(cherry picked from commit 5a737a3aab969b120a84dbc7cd7ed351796576b3)
(cherry picked from commit 40368ec6b01d2f1198cbe57f7374233d74631249)


> Solr loads UNLOADed core on request
> ---
>
> Key: SOLR-10857
> URL: https://issues.apache.org/jira/browse/SOLR-10857
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Mikhail Khludnev
>Assignee: Erick Erickson
> Fix For: master (7.0), 6.7, 6.6.1
>
> Attachments: SOLR-10857.patch, SOLR-10857.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10857) Solr loads UNLOADed core on request

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10857:


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

SOLR-10857: Solr loads UNLOADed core on request, cleaned up printStackTrace

(cherry picked from commit 5a737a3aab969b120a84dbc7cd7ed351796576b3)


> Solr loads UNLOADed core on request
> ---
>
> Key: SOLR-10857
> URL: https://issues.apache.org/jira/browse/SOLR-10857
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Mikhail Khludnev
>Assignee: Erick Erickson
> Fix For: master (7.0), 6.7, 6.6.1
>
> Attachments: SOLR-10857.patch, SOLR-10857.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10872) _version_ returns exception when changed to point field

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10872:
-

bq. {{Point fields can't use FieldCache}}

That string exists in 6.5, but not in 6.6

> _version_ returns exception when changed to point field
> ---
>
> Key: SOLR-10872
> URL: https://issues.apache.org/jira/browse/SOLR-10872
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Shawn Feldman
>Priority: Minor
>
> I changed all my TrieLong Fields to Point fields.  _version_ always returns 
> an error unless i turn on docvalues for version
>   
>   
> Getting this error when i index 
> {code}
>  Remote error message: Point fields can't use FieldCache. Use docValues=true 
> for field: _version_
> solr2_1|at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.doFinish(DistributedUpdateProcessor.java:973)
> solr2_1|at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.finish(DistributedUpdateProcessor.java:1912)
> solr2_1|at 
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.finish(LogUpdateProcessorFactory.java:182)
> solr2_1|at 
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:78)
> solr2_1|at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)
> solr2_1|at org.apache.solr.core.SolrCore.execute(SolrCore.java:2440)
> solr2_1|at 
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:723)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10872) _version_ returns exception when changed to point field

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10872:
-

Shawn: you said this affects 6.6 but i'm not sure i understand how that's 
possible given the fixes in SOLR-10472.

See also SOLR-10832 for other reasons why Points are not currently a good idea 
for {{\_version_}}

> _version_ returns exception when changed to point field
> ---
>
> Key: SOLR-10872
> URL: https://issues.apache.org/jira/browse/SOLR-10872
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Shawn Feldman
>Priority: Minor
>
> I changed all my TrieLong Fields to Point fields.  _version_ always returns 
> an error unless i turn on docvalues for version
>   
>   
> Getting this error when i index 
> {code}
>  Remote error message: Point fields can't use FieldCache. Use docValues=true 
> for field: _version_
> solr2_1|at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.doFinish(DistributedUpdateProcessor.java:973)
> solr2_1|at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.finish(DistributedUpdateProcessor.java:1912)
> solr2_1|at 
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.finish(LogUpdateProcessorFactory.java:182)
> solr2_1|at 
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:78)
> solr2_1|at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)
> solr2_1|at org.apache.solr.core.SolrCore.execute(SolrCore.java:2440)
> solr2_1|at 
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:723)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10857) Solr loads UNLOADed core on request

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10857:


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

SOLR-10857: Solr loads UNLOADed core on request, cleaned up printStackTrace


> Solr loads UNLOADed core on request
> ---
>
> Key: SOLR-10857
> URL: https://issues.apache.org/jira/browse/SOLR-10857
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Mikhail Khludnev
>Assignee: Erick Erickson
> Fix For: master (7.0), 6.7, 6.6.1
>
> Attachments: SOLR-10857.patch, SOLR-10857.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10871) Remove monospace text from headings in Ref Guide

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10871:
-

bq. I'm not a fan of using quotes, since I think we already use them very 
inconsistently...

That's the argument for why i originally used monospoace in the headers - to 
try and be consistent :)

bq. Probably 80% or more of the usages are in regard to parameters, and like 
the example I showed, the heading clearly states the section is about "The 
start Parameter", ...

my only concern (in the past) about having no typographic distrinction is the 
risk of a "Who's on First" situation? ... things like "The facet.query 
Parameter" are pretty self describing, but something like "The start Parameter" 
or "The sort Parameter" _might_ be confusing to new users w/o quotes or some 
other form of indication that it's a "literal" parameter name... "Yes, i am in 
fact interested in the parameter for doing a sort - please tell me what it's 
name is!"

But this is likely just a theoretical problem that doesn't really exist -- if 
the sections are written well, as soon as the reader gets to the first sentence 
after the heading, it should be obvious.

> Remove monospace text from headings in Ref Guide
> 
>
> Key: SOLR-10871
> URL: https://issues.apache.org/jira/browse/SOLR-10871
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
> Fix For: master (7.0)
>
> Attachments: monospace-in-header-new.png, 
> monospace-in-header-old.png, Screen Shot 2017-06-12 at 11.20.04 AM.png
>
>
> Monospace text doesn't look great in section headings in the PDF - the font 
> color is different and the size is smaller. With the old way of generating 
> the PDF we could make it the same color & adjust the font size so it was less 
> jarring. We don't have that option now, so the difference is much more 
> pronounced.
> I found 148 instances of this in 40 files. I think we can make that "normal" 
> text without losing any important information for the reader.
> Attaching screenshots of what it used to look like and what it now looks 
> like, to illustrate the difference.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10871) Remove monospace text from headings in Ref Guide

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-10871:
--

bq. Note that bold doesn't have any effect, I'm assuming because the headings 
are already (effectively) bolded.

Yes, headings are already bold. 

Italics could work. I wonder about the inconsistency about using italics in 
headings and monospace in text - perhaps it's fine, though. I could see  the 
same argument about removing the monospace from headings - it's inconsistent. 
But, in the case of the monospace, the effect turns out to be more jarring than 
useful. The goal is to convey information to the reader without causing 
unnecessary interruption in the flow of their reading. Italics would flow with 
the text.

Probably 80% or more of the usages are in regard to parameters, and like the 
example I showed, the heading clearly states the section is about "The start 
Parameter", "The fq Parameter", "The facet.query Parameter", etc. Does 
differentiating the text style for the name of the parameter help the reader 
without interrupting his/her reading? I'm open to being convinced about that, 
but I'm not yet.

I'm not a fan of using quotes, since I think we already use them very 
inconsistently - for example, sometimes when we refer to the techproducts 
example we put "techproducts" in monospace, but sometimes it's in single 
quotes, and sometimes it's double quotes, and other times it's a combo of these.

> Remove monospace text from headings in Ref Guide
> 
>
> Key: SOLR-10871
> URL: https://issues.apache.org/jira/browse/SOLR-10871
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
> Fix For: master (7.0)
>
> Attachments: monospace-in-header-new.png, 
> monospace-in-header-old.png, Screen Shot 2017-06-12 at 11.20.04 AM.png
>
>
> Monospace text doesn't look great in section headings in the PDF - the font 
> color is different and the size is smaller. With the old way of generating 
> the PDF we could make it the same color & adjust the font size so it was less 
> jarring. We don't have that option now, so the difference is much more 
> pronounced.
> I found 148 instances of this in 40 files. I think we can make that "normal" 
> text without losing any important information for the reader.
> Attaching screenshots of what it used to look like and what it now looks 
> like, to illustrate the difference.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Better error message? (old version and new version are not comparable)

[S G]

Hi Zheng,

We are using 6.3 version.
I have created a small PR that addresses this issue of better error message.
Please merge the same if it looks ok.
https://github.com/apache/lucene-solr/pull/212/files

Thanks
SG


On Sun, Jun 11, 2017 at 8:45 PM, Zheng Lin Edwin Yeo 
wrote:

> Which version of Solr are yo using?
>
> Also, I believe you should send this message to the user list at solr-user
> @lucene.apache.org
>
> Regards,
> Edwin
>
> On 12 June 2017 at 02:45, S G  wrote:
>
>> Hi,
>>
>> Recently I ran into an issue where the logs were showing the following:
>>
>>
>> org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error
>> from server at http://solr-host:8983/solr/loadtest_shard1_replica1: old
>> version and new version are not comparable: class java.lang.Long vs class
>> java.lang.Integer: null
>> at 
>> org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:765)
>> ~[load-client.jar]
>> at 
>> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1173)
>> ~[load-client.jar]
>> at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWit
>> hRetryOnStaleState(CloudSolrClient.java:1062) ~[load-client.jar]
>> at 
>> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1004)
>> ~[load-client.jar]
>> at 
>> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
>> ~[load-client.jar]
>> at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:106)
>> ~[load-client.jar]
>> at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:123)
>> ~[load-client.jar]
>> at WriteLoadTest$IndexWorker.addDocsToSolr(WriteLoadTest.java:629)
>> [load-client.jar]
>> at WriteLoadTest$IndexWorker.run(WriteLoadTest.java:573)
>> [load-client.jar]
>> Caused by: 
>> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:
>> Error from server at http://solr-host:8983/solr/loadtest_shard1_replica1:
>> old version and new version are not comparable: class java.lang.Long vs
>> class java.lang.Integer: null
>> at 
>> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:593)
>> ~[load-client.jar]
>> at 
>> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
>> ~[load-client.jar]
>> at 
>> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:251)
>> ~[load-client.jar]
>> at 
>> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:435)
>> ~[load-client.jar]
>> at 
>> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:387)
>> ~[load-client.jar]
>> at org.apache.solr.client.solrj.impl.CloudSolrClient.lambda$dir
>> ectUpdate$0(CloudSolrClient.java:742) ~[load-client.jar]
>> at 
>> org.apache.solr.client.solrj.impl.CloudSolrClient$$Lambda$8/745780984.call(Unknown
>> Source) ~[?:?]
>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>> ~[?:1.8.0_51]
>> at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolE
>> xecutor.lambda$execute$0(ExecutorUtil.java:229) ~[load-client.jar]
>> at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolE
>> xecutor$$Lambda$7/725894523.run(Unknown Source) ~[?:?]
>> ... 3 more
>>
>>
>> The message above is not clear at all.
>> Which document is it talking about?
>> I have so many documents being ingested and it's hard to figure out the
>> same.
>> It would have been nice if the message included a document ID too.
>>
>>
>> Thanks
>> SG
>>
>>
>>
>>
>

[GitHub] lucene-solr pull request #212: More informative messages

[sachingsachin]

GitHub user sachingsachin opened a pull request:

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

More informative messages



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

$ git pull https://github.com/sachingsachin/lucene-solr fix_messages

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

https://github.com/apache/lucene-solr/pull/212.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 #212


commit a687a1312aa5c72b4d5514b37412ed3b46d7c2f2
Author: Sachin Goyal 
Date:   2017-06-10T23:29:30Z

More informative messages




---
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] [Created] (SOLR-10872) _version_ returns exception when changed to point field

[Shawn Feldman (JIRA)]

Shawn Feldman created SOLR-10872:


 Summary: _version_ returns exception when changed to point field
 Key: SOLR-10872
 URL: https://issues.apache.org/jira/browse/SOLR-10872
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.6
Reporter: Shawn Feldman
Priority: Minor


I changed all my TrieLong Fields to Point fields.  _version_ always returns an 
error unless i turn on docvalues for version

  
  

Getting this error when i index 
{code}
 Remote error message: Point fields can't use FieldCache. Use docValues=true 
for field: _version_
solr2_1|at 
org.apache.solr.update.processor.DistributedUpdateProcessor.doFinish(DistributedUpdateProcessor.java:973)
solr2_1|at 
org.apache.solr.update.processor.DistributedUpdateProcessor.finish(DistributedUpdateProcessor.java:1912)
solr2_1|at 
org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.finish(LogUpdateProcessorFactory.java:182)
solr2_1|at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:78)
solr2_1|at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)
solr2_1|at org.apache.solr.core.SolrCore.execute(SolrCore.java:2440)
solr2_1|at 
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:723)
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10871) Remove monospace text from headings in Ref Guide

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10871:
-

I'm guessing i'm personally responsible for at least 140 of those instances.

i've always thought the differentiated font in the header was nice because it 
helped draw attention to the fact that they were the {{names}} of params -- but 
i think in the new world order removing the font change and indicating that in 
some other way is fine.  quotes, single quotes, italics, etc... or in some 
cases maybe just rewording the header where it may not be obvious (ie: always 
use the form "The foo parameter") will probably suffice?



> Remove monospace text from headings in Ref Guide
> 
>
> Key: SOLR-10871
> URL: https://issues.apache.org/jira/browse/SOLR-10871
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
> Fix For: master (7.0)
>
> Attachments: monospace-in-header-new.png, 
> monospace-in-header-old.png, Screen Shot 2017-06-12 at 11.20.04 AM.png
>
>
> Monospace text doesn't look great in section headings in the PDF - the font 
> color is different and the size is smaller. With the old way of generating 
> the PDF we could make it the same color & adjust the font size so it was less 
> jarring. We don't have that option now, so the difference is much more 
> pronounced.
> I found 148 instances of this in 40 files. I think we can make that "normal" 
> text without losing any important information for the reader.
> Attaching screenshots of what it used to look like and what it now looks 
> like, to illustrate the difference.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-10871) Remove monospace text from headings in Ref Guide

[Steve Rowe (JIRA)]

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

Steve Rowe edited comment on SOLR-10871 at 6/12/17 3:27 PM:


I think there would be a semantic loss in some cases if we can't highlight 
stuff that's currently monospaced, in some (other) way.

Here's PDF screenshot of the possibilities I could think of: [^Screen Shot 
2017-06-12 at 11.20.04 AM.png].  Note that bold doesn't have any effect, I'm 
assuming because the headings are already (effectively) bolded.

If we do decide to continue including some form of highlighting, I'd vote for 
underlined.


was (Author: steve_rowe):
I think there would be a semantic loss in some cases if we can't highlight 
stuff that's currently monospaced, in some (other) way.

Here's PDF screenshot of the possibilities I could think of: [^Screen Shot 
2017-06-12 at 11.20.04 AM.png].  Note that bold doesn't have any effect, I'm 
assuming because the headings are already (effectively) bolded.

If we do decide to continue including some form of highlighting, I'd vote for 
underlined,

> Remove monospace text from headings in Ref Guide
> 
>
> Key: SOLR-10871
> URL: https://issues.apache.org/jira/browse/SOLR-10871
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
> Fix For: master (7.0)
>
> Attachments: monospace-in-header-new.png, 
> monospace-in-header-old.png, Screen Shot 2017-06-12 at 11.20.04 AM.png
>
>
> Monospace text doesn't look great in section headings in the PDF - the font 
> color is different and the size is smaller. With the old way of generating 
> the PDF we could make it the same color & adjust the font size so it was less 
> jarring. We don't have that option now, so the difference is much more 
> pronounced.
> I found 148 instances of this in 40 files. I think we can make that "normal" 
> text without losing any important information for the reader.
> Attaching screenshots of what it used to look like and what it now looks 
> like, to illustrate the difference.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10871) Remove monospace text from headings in Ref Guide

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-10871:
--
Attachment: Screen Shot 2017-06-12 at 11.20.04 AM.png

I think there would be a semantic loss in some cases if we can't highlight 
stuff that's currently monospaced, in some (other) way.

Here's PDF screenshot of the possibilities I could think of: [^Screen Shot 
2017-06-12 at 11.20.04 AM.png].  Note that bold doesn't have any effect, I'm 
assuming because the headings are already (effectively) bolded.

If we do decide to continue including some form of highlighting, I'd vote for 
underlined,

> Remove monospace text from headings in Ref Guide
> 
>
> Key: SOLR-10871
> URL: https://issues.apache.org/jira/browse/SOLR-10871
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
> Fix For: master (7.0)
>
> Attachments: monospace-in-header-new.png, 
> monospace-in-header-old.png, Screen Shot 2017-06-12 at 11.20.04 AM.png
>
>
> Monospace text doesn't look great in section headings in the PDF - the font 
> color is different and the size is smaller. With the old way of generating 
> the PDF we could make it the same color & adjust the font size so it was less 
> jarring. We don't have that option now, so the difference is much more 
> pronounced.
> I found 148 instances of this in 40 files. I think we can make that "normal" 
> text without losing any important information for the reader.
> Attaching screenshots of what it used to look like and what it now looks 
> like, to illustrate the difference.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10865) parameter processor=Template doesn't invoke TemplateUpdateProcessorFactory.

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar commented on SOLR-10865:
-

[~shalinmangar] agreed. This is not working after *SOLR-9530* where certain 
adjustments made in *UpdateRequestProcessorChain.java* to make sure inform(...) 
works for AtomicURP (related to _LazyPluginHolder_ in PluginBag.java_). I 
didn't make the changes myself but I see what are you saying and we may have 
gone wrong there.

patch snippet from SOLR-9530 =>
{code}
diff --git 
a/solr/core/src/java/org/apache/solr/update/processor/UpdateRequestProcessorChain.java
 
b/solr/core/src/java/org/apache/solr/update/processor/UpdateRequestProcessorChain.java
index 0ed626cb0f..05d1a5ae3f 100644
--- 
a/solr/core/src/java/org/apache/solr/update/processor/UpdateRequestProcessorChain.java
+++ 
b/solr/core/src/java/org/apache/solr/update/processor/UpdateRequestProcessorChain.java
@@ -28,6 +28,8 @@ import org.apache.solr.common.params.MapSolrParams;
 import org.apache.solr.common.params.SolrParams;
 import org.apache.solr.common.util.NamedList;
 import org.apache.solr.common.util.StrUtils;
+import org.apache.solr.common.util.Utils;
+import org.apache.solr.core.PluginBag;
 import org.apache.solr.core.PluginInfo;
 import org.apache.solr.core.SolrCore;
 import org.apache.solr.request.SolrQueryRequest;
@@ -271,9 +273,13 @@ public final class UpdateRequestProcessorChain implements 
PluginInfoInitialized
   UpdateRequestProcessorFactory p = core.getUpdateProcessors().get(s);
   if (p == null) {
 try {
-  p = core.createInstance(s + "UpdateProcessorFactory", 
UpdateRequestProcessorFactory.class,
-  "updateProcessor", null, core.getMemClassLoader());
-  core.getUpdateProcessors().put(s, p);
+  PluginInfo pluginInfo = new PluginInfo("updateProcessor",
+  Utils.makeMap("name", s,
+  "class", s + "UpdateProcessorFactory",
+  "runtimeLib", "true"));
+
+  PluginBag.PluginHolder pluginHolder = 
core.getUpdateProcessors().createPlugin(pluginInfo);
+  core.getUpdateProcessors().put(s, p = pluginHolder.get());
 } catch (SolrException e) {
 }
 if (p == null)
{code}

I don't recall the exact reason behind this, but will surely look into it.

> parameter processor=Template doesn't invoke TemplateUpdateProcessorFactory.
> ---
>
> Key: SOLR-10865
> URL: https://issues.apache.org/jira/browse/SOLR-10865
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Affects Versions: master (7.0)
>Reporter: Amrit Sarkar
> Attachments: SOLR-10865.patch, SOLR-10865.patch
>
>
> Ref docs::
> {quote}
> The TemplateUpdateProcessorFactory can be used to add new fields to documents 
> based on a template pattern.
> This can be used directly in a request without any configuration. To enable 
> this processor, use the parameter processor=Template.
> {quote}
> Sample curl::
> {code}
> curl -X POST -H 'Content-Type:application/json' 
> 'http://localhost:8983/solr/gettingstarted/update/json/docs?processor=Template=fullName_s:AmritSarkar=true'
>  --data-binary '{"id": 1,"title": "titleA"}'
> {code}
> I am receiving exception::
> {code}
> 
> 
> 400 name="QTime">3 name="error-class">org.apache.solr.common.SolrException name="root-error-class">org.apache.solr.common.SolrException name="msg">No such processor Template400
> 
> {code}
> {code}
> ERROR - 2017-06-10 07:39:51.598; [c:gettingstarted s:shard2 r:core_node1 
> x:gettingstarted_shard2_replica_n1] org.apache.solr.common.SolrException; 
> org.apache.solr.common.SolrException: No such processor Template
>   at 
> org.apache.solr.update.processor.UpdateRequestProcessorChain.getReqProcessors(UpdateRequestProcessorChain.java:286)
>   at 
> org.apache.solr.update.processor.UpdateRequestProcessorChain.constructChain(UpdateRequestProcessorChain.java:235)
> {code}
> I looked into how the testclass has been created::
> TemplateUpdateProcessorTest::
> {code}
>   public void testSimple() throws Exception {
> AddUpdateCommand cmd = new AddUpdateCommand(new 
> LocalSolrQueryRequest(null,
> new ModifiableSolrParams()
> .add("processor", "Template")
> .add("Template.field", "id:${firstName}_${lastName}")
> .add("Template.field", "another:${lastName}_${firstName}")
> .add("Template.field", "missing:${lastName}_${unKnown}")
> ));
> cmd.solrDoc = new SolrInputDocument();
> cmd.solrDoc.addField("firstName", "Tom");
> cmd.solrDoc.addField("lastName", "Cruise");
> new TemplateUpdateProcessorFactory().getInstance(cmd.getReq(), new 
> SolrQueryResponse(), 

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

[Policeman Jenkins Server]

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

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

Error Message:
There are still nodes recoverying - waited for 330 seconds

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 330 
seconds
at 
__randomizedtesting.SeedInfo.seed([FC4C6121947DEE4E:776BB2F0D57B45CA]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:187)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:144)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:139)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:856)
at 
org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey(ShardSplitTest.java:437)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
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:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
   

[jira] [Updated] (LUCENE-7868) Use multiple threads to apply deletes and DV updates

[Michael McCandless (JIRA)]

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

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

Another iteration, with feedback from [~rcmuir] (thank you!) and still many 
nocommits.

I added a new test case testing index sorting with DV updates and this 
uncovered a pre-existing bug, I think introduced with LUCENE-6766, when you try 
to update recently indexed documents ... I'll open a separate issue later to 
fix this for 6.6.x.

I've also run some DV update performance tests and this uncovered problems with 
the patch ... still iterating.

> Use multiple threads to apply deletes and DV updates
> 
>
> Key: LUCENE-7868
> URL: https://issues.apache.org/jira/browse/LUCENE-7868
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0)
>
> Attachments: cpu-after.png, cpu-before.png, LUCENE-7868.patch, 
> LUCENE-7868.patch, LUCENE-7868.patch
>
>
> Today, when users delete documents or apply doc values updates, IndexWriter 
> buffers them up into frozen packets and then eventually uses a single thread 
> (BufferedUpdatesStream.applyDeletesAndUpdates) to resolve delete/update terms 
> to docids.  This thread also holds IW's monitor lock, so it also blocks 
> refresh, merges starting/finishing, commits, etc.
> We have heavily optimized this part of Lucene over time, e.g. LUCENE-6161, 
> LUCENE-2897, LUCENE-2680, LUCENE-3342, but still, it's a single thread so it 
> can't use multiple CPU cores commonly available now.
> This doesn't affect append-only usage, but for update-heavy users (me!) this 
> can be a big bottleneck, and causes long stop-the-world hangs during indexing.
> I have an initial exploratory patch to make these lookups concurrent, without 
> holding IW's lock, so that when a new packet of deletes is pushed, which 
> happens when we flush a new segment, we immediately use that same indexing 
> thread to and resolve the deletions.
> This is analogous to when we made segment flushing concurrent (LUCENE-3023), 
> just for deletes and DV updates as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-10871) Remove monospace text from headings in Ref Guide

[Cassandra Targett (JIRA)]

Cassandra Targett created SOLR-10871:


 Summary: Remove monospace text from headings in Ref Guide
 Key: SOLR-10871
 URL: https://issues.apache.org/jira/browse/SOLR-10871
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: documentation
Reporter: Cassandra Targett
Assignee: Cassandra Targett
 Fix For: master (7.0)
 Attachments: monospace-in-header-new.png, monospace-in-header-old.png

Monospace text doesn't look great in section headings in the PDF - the font 
color is different and the size is smaller. With the old way of generating the 
PDF we could make it the same color & adjust the font size so it was less 
jarring. We don't have that option now, so the difference is much more 
pronounced.

I found 148 instances of this in 40 files. I think we can make that "normal" 
text without losing any important information for the reader.

Attaching screenshots of what it used to look like and what it now looks like, 
to illustrate the difference.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10871) Remove monospace text from headings in Ref Guide

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-10871:
-
Attachment: monospace-in-header-old.png
monospace-in-header-new.png

> Remove monospace text from headings in Ref Guide
> 
>
> Key: SOLR-10871
> URL: https://issues.apache.org/jira/browse/SOLR-10871
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
> Fix For: master (7.0)
>
> Attachments: monospace-in-header-new.png, monospace-in-header-old.png
>
>
> Monospace text doesn't look great in section headings in the PDF - the font 
> color is different and the size is smaller. With the old way of generating 
> the PDF we could make it the same color & adjust the font size so it was less 
> jarring. We don't have that option now, so the difference is much more 
> pronounced.
> I found 148 instances of this in 40 files. I think we can make that "normal" 
> text without losing any important information for the reader.
> Attaching screenshots of what it used to look like and what it now looks 
> like, to illustrate the difference.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10433) switch between v2 and v1 endpoints internally in SolrJ

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-10433:
--
Attachment: SOLR-10433.patch

> switch between v2 and v1 endpoints internally in SolrJ
> --
>
> Key: SOLR-10433
> URL: https://issues.apache.org/jira/browse/SOLR-10433
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: v2 API
>Reporter: Noble Paul
> Attachments: SOLR-10433.patch, SOLR-10433.patch
>
>
> There are some bugs in v2 api that I would like to solve in other tickets :
> - DELETE method doest not support body ( we can't pass async id )
> - V2HttpCall should {{override getAuthCtx()}} to support 
> {{RuleBasedAuthorizationPlugin}}
> - with create collection, when user send this request
> {code}
> {
> "properties" : {"solr.tests.maxBufferedDocs" : 100}
> }
> {code}
> the v2 api can not resolve the value for 
> "properties.solr.tests.maxBufferedDocs"



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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