[jira] [Closed] (SOLR-8201) Swap space info not showing in new UI (see screenshot)

[Erick Erickson (JIRA)]

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

Erick Erickson closed SOLR-8201.

Resolution: Cannot Reproduce

> Swap space info not showing in new UI (see screenshot)
> --
>
> Key: SOLR-8201
> URL: https://issues.apache.org/jira/browse/SOLR-8201
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Reporter: Youssef Chaker
>Assignee: Upayavira
>Priority: Minor
> Attachments: swap space.png
>
>
> The old UI displays info about the swap space (even if nothing is allocated) 
> whereas the new UI does not (see screenshot).



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

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

[jira] [Closed] (SOLR-5651) Make labels clickable and the output wrapped in UI

[Erick Erickson (JIRA)]

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

Erick Erickson closed SOLR-5651.

Resolution: Cannot Reproduce

> Make labels clickable and the output wrapped in UI
> --
>
> Key: SOLR-5651
> URL: https://issues.apache.org/jira/browse/SOLR-5651
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 4.6
>Reporter: Artem Lukanin
> Fix For: 6.0, 4.9
>
> Attachments: SOLR-5651_clickable_labels.patch, 
> SOLR-5651_clickable_labels.patch
>
>
> Now it is practically impossible to tick off check boxes in the UI, because 
> the label text is wrapped in a fancy A tag without HREF.
> Also it is very hard to read the output on the Query menu when 
> debugQuery=true. It is impossible to scroll the window to the right. It would 
> be better if the text in the PRE tag was wrapped.



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

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

[jira] [Closed] (SOLR-5270) lastModified not updating when selecting another core in Core Admin

[Erick Erickson (JIRA)]

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

Erick Erickson closed SOLR-5270.

Resolution: Cannot Reproduce

> lastModified not updating when selecting another core in Core Admin
> ---
>
> Key: SOLR-5270
> URL: https://issues.apache.org/jira/browse/SOLR-5270
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Reporter: Simon Endele
>Priority: Minor
>
> When selecting a core in the section "Core Admin" in the Solr Admin web UI, 
> data like dataDir, version, numDocs, maxDoc are updated via JavaScript, but 
> lastModified is not. A refresh of the page does the trick.
> Had a look into the network traffic of my browser and it seems that the JSON 
> fetched via AJAX contains the correct information.
> Can be reproduced in different browsers with the example by cloning 
> collection1 into a collection2 and indexing collection2 anew by calling "java 
> -jar post.jar *.xml" in the exampledocs directory.
> Tested with Solr 4.4.0.



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

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

[jira] [Resolved] (SOLR-380) There's no way to convert search results into page-level hits of a "structured document".

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-380.
-
Resolution: Won't Fix

> There's no way to convert search results into page-level hits of a 
> "structured document".
> -
>
> Key: SOLR-380
> URL: https://issues.apache.org/jira/browse/SOLR-380
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Tricia Jenkins
>Priority: Minor
> Fix For: 6.0, 4.9
>
> Attachments: SOLR-380-XmlPayload.patch, SOLR-380-XmlPayload.patch, 
> xmlpayload-example.zip, xmlpayload-src.jar, xmlpayload.jar
>
>
> "Paged-Text" FieldType for Solr
> A chance to dig into the guts of Solr. The problem: If we index a monograph 
> in Solr, there's no way to convert search results into page-level hits. The 
> solution: have a "paged-text" fieldtype which keeps track of page divisions 
> as it indexes, and reports page-level hits in the search results.
> The input would contain page milestones: . As Solr processed 
> the tokens (using its standard tokenizers and filters), it would concurrently 
> build a structural map of the item, indicating which term position marked the 
> beginning of which page: . This map would 
> be stored in an unindexed field in some efficient format.
> At search time, Solr would retrieve term positions for all hits that are 
> returned in the current request, and use the stored map to determine page ids 
> for each term position. The results would imitate the results for 
> highlighting, something like:
> 
> 
> 234
> 236
> 
> 
> 19
> 
> 
> 
> 
> 
>  name="pos">14325
> 
> 
> ...
> 



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

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

[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_92) - Build # 1284 - Still Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1284/
Java: 32bit/jdk1.8.0_92 -client -XX:+UseConcMarkSweepGC

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

Error Message:
Could not get expected value  'P val' for path 'response/params/y/p' full 
output: {   "responseHeader":{ "status":0, "QTime":0},   "response":{   
  "znodeVersion":1, "params":{   "x":{ "a":"A val", 
"b":"B val", "":{"v":0}},   "y":{ "c":"CY val", 
"b":"BY val", "i":20, "d":[   "val 1",   "val 
2"], "":{"v":0},  from server:  https://127.0.0.1:37438/collection1

Stack Trace:
java.lang.AssertionError: Could not get expected value  'P val' for path 
'response/params/y/p' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "response":{
"znodeVersion":1,
"params":{
  "x":{
"a":"A val",
"b":"B val",
"":{"v":0}},
  "y":{
"c":"CY val",
"b":"BY val",
"i":20,
"d":[
  "val 1",
  "val 2"],
"":{"v":0},  from server:  https://127.0.0.1:37438/collection1
at 
__randomizedtesting.SeedInfo.seed([9682BDC72D81C96C:1ED6821D837DA494]: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:481)
at 
org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:215)
at 
org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:61)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/345/
Java: 32bit/jdk1.8.0_92 -server -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.solr.common.cloud.TestCollectionStateWatchers.testSimpleCollectionWatch

Error Message:
CollectionStateWatcher wasn't cleared after completion

Stack Trace:
java.lang.AssertionError: CollectionStateWatcher wasn't cleared after completion
at 
__randomizedtesting.SeedInfo.seed([CAA7410B4A498501:979C8E7B0D441A3F]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.common.cloud.TestCollectionStateWatchers.testSimpleCollectionWatch(TestCollectionStateWatchers.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 13326 lines...]
   [junit4] Suite: org.apache.solr.common.cloud.TestCollectionStateWatchers
   [junit4]   2> Creating dataDir: 

[jira] [Commented] (SOLR-380) There's no way to convert search results into page-level hits of a "structured document".

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-380:


Let's close this. And the associated WIKI page. The original reporter confirmed 
it is ok to do so.

> There's no way to convert search results into page-level hits of a 
> "structured document".
> -
>
> Key: SOLR-380
> URL: https://issues.apache.org/jira/browse/SOLR-380
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Tricia Jenkins
>Priority: Minor
> Fix For: 4.9, 6.0
>
> Attachments: SOLR-380-XmlPayload.patch, SOLR-380-XmlPayload.patch, 
> xmlpayload-example.zip, xmlpayload-src.jar, xmlpayload.jar
>
>
> "Paged-Text" FieldType for Solr
> A chance to dig into the guts of Solr. The problem: If we index a monograph 
> in Solr, there's no way to convert search results into page-level hits. The 
> solution: have a "paged-text" fieldtype which keeps track of page divisions 
> as it indexes, and reports page-level hits in the search results.
> The input would contain page milestones: . As Solr processed 
> the tokens (using its standard tokenizers and filters), it would concurrently 
> build a structural map of the item, indicating which term position marked the 
> beginning of which page: . This map would 
> be stored in an unindexed field in some efficient format.
> At search time, Solr would retrieve term positions for all hits that are 
> returned in the current request, and use the stored map to determine page ids 
> for each term position. The results would imitate the results for 
> highlighting, something like:
> 
> 
> 234
> 236
> 
> 
> 19
> 
> 
> 
> 
> 
>  name="pos">14325
> 
> 
> ...
> 



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

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

[jira] [Resolved] (SOLR-4794) UI is broken on browsers for Android

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar resolved SOLR-4794.
-
   Resolution: Implemented
Fix Version/s: (was: 6.0)

> UI is broken on browsers for Android
> 
>
> Key: SOLR-4794
> URL: https://issues.apache.org/jira/browse/SOLR-4794
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 4.3
> Environment: HTC Amaze 4G
>Reporter: Shawn Heisey
>Priority: Minor
>
> I've tried three browsers for my Android phone, an Amaze 4G by HTC.  All of 
> them have problems.
> One problem common to all of them is that the stuff on the left-hand side of 
> the screen always stays put and will cover up the rest of the page if you 
> zoom in and/or scroll around.
> 1) Built-in browser: I think this is probably provided or modified by HTC.  
> This one is extremely broken. By clicking in what looks like incorrect 
> places, you can select a core, but you can't get to any of the good stuff 
> like the query or analysis UI.
> 2) Chrome for Android: Better than the HTC/Android browser.  I can get to the 
> query UI, but when I try to execute a query, it goes back to the dashboard.
> 3) Firefox for Android: Works fairly well on the few things I tested, except 
> for the left-hand stuff covering the rest of the page as mentioned above.  I 
> don't know if everything is working, but this is the only one that let me use 
> the query UI.



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

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

[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_92) - Build # 1283 - Still Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1283/
Java: 32bit/jdk1.8.0_92 -server -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.cloud.TestSolrCloudWithKerberosAlt.testBasics

Error Message:
Address already in use

Stack Trace:
java.net.BindException: Address already in use
at 
__randomizedtesting.SeedInfo.seed([82617E41AAD13197:BFB9D06D923F6FE7]:0)
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:433)
at sun.nio.ch.Net.bind(Net.java:425)
at 
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at 
org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:252)
at 
org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:49)
at 
org.apache.mina.core.polling.AbstractPollingIoAcceptor.registerHandles(AbstractPollingIoAcceptor.java:525)
at 
org.apache.mina.core.polling.AbstractPollingIoAcceptor.access$200(AbstractPollingIoAcceptor.java:67)
at 
org.apache.mina.core.polling.AbstractPollingIoAcceptor$Acceptor.run(AbstractPollingIoAcceptor.java:409)
at 
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:65)
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:745)




Build Log:
[...truncated 12187 lines...]
   [junit4] Suite: org.apache.solr.cloud.TestSolrCloudWithKerberosAlt
   [junit4]   2> 1738709 WARN  
(TEST-TestSolrCloudWithKerberosAlt.testBasics-seed#[82617E41AAD13197]) [] 
o.a.d.s.c.DefaultDirectoryService You didn't change the admin password of 
directory service instance 'DefaultKrbServer'.  Please update the admin 
password as soon as possible to prevent a possible security breach.
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestSolrCloudWithKerberosAlt -Dtests.method=testBasics 
-Dtests.seed=82617E41AAD13197 -Dtests.multiplier=3 -Dtests.slow=true 
-Dtests.locale=be-BY -Dtests.timezone=MET -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] ERROR   9.17s J2 | TestSolrCloudWithKerberosAlt.testBasics <<<
   [junit4]> Throwable #1: java.net.BindException: Address already in use
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([82617E41AAD13197:BFB9D06D923F6FE7]:0)
   [junit4]>at sun.nio.ch.Net.bind0(Native Method)
   [junit4]>at sun.nio.ch.Net.bind(Net.java:433)
   [junit4]>at sun.nio.ch.Net.bind(Net.java:425)
   [junit4]>at 
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
   [junit4]>at 
sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
   [junit4]>at 
org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:252)
   [junit4]>at 
org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:49)
   [junit4]>at 
org.apache.mina.core.polling.AbstractPollingIoAcceptor.registerHandles(AbstractPollingIoAcceptor.java:525)
   [junit4]>at 
org.apache.mina.core.polling.AbstractPollingIoAcceptor.access$200(AbstractPollingIoAcceptor.java:67)
   [junit4]>at 
org.apache.mina.core.polling.AbstractPollingIoAcceptor$Acceptor.run(AbstractPollingIoAcceptor.java:409)
   [junit4]>at 
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:65)
   [junit4]>at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
   [junit4]>at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
   [junit4]   2> NOTE: leaving temporary files on disk at: 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/J2/temp/solr.cloud.TestSolrCloudWithKerberosAlt_82617E41AAD13197-001
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene62): {}, 
docValues:{}, maxPointsInLeafNode=326, sim=ClassicSimilarity, locale=be-BY, 
timezone=MET
   [junit4]   2> NOTE: Linux 4.4.0-31-generic i386/Oracle Corporation 1.8.0_92 
(32-bit)/cpus=12,threads=1,free=312995680,total=518979584
   [junit4]   2> NOTE: All tests run in this JVM: [UpdateParamsTest, TestUtils, 
TestPerFieldSimilarity, BinaryUpdateRequestHandlerTest, 
TestElisionMultitermQuery, TestNamedUpdateProcessors, JavabinLoaderTest, 
CursorMarkTest, OverseerRolesTest, TestFieldSortValues, 
StatelessScriptUpdateProcessorFactoryTest, DeleteInactiveReplicaTest, 
FullSolrCloudDistribCmdsTest, SuggestComponentContextFilterQueryTest, 
TestFastWriter, RegexBoostProcessorTest, TestConfigOverlay, SuggesterWFSTTest, 
BooleanFieldTest, TestBlobHandler, TestSearcherReuse, 

[jira] [Updated] (LUCENE-7397) Inefficient FVhighlighting when set many HighlightedField.

[donghyun Kim (JIRA)]

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

donghyun Kim updated LUCENE-7397:
-
Issue Type: Improvement  (was: Bug)

> Inefficient FVhighlighting when set many HighlightedField.
> --
>
> Key: LUCENE-7397
> URL: https://issues.apache.org/jira/browse/LUCENE-7397
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
> Environment: CentOS release 6.4 (Final)
> quad core 1.87
> 8gb memory
> tested Elasticsearch - 1.5 with lucene 4.10.4 
> But i see mirrored Master version in github 
> https://github.com/apache/lucene-solr
>Reporter: donghyun Kim
>Priority: Minor
>
> when highlighting, search result 
> org.apache.lucene.search.vectorhighlight.FastVectorHighlighter.java
> getBestFragment method ~ FieldTermStack.java read whole doc's termvector 
> every highlighted field.
> It causes slow query when many highlight field



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

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

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

[Policeman Jenkins Server]

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

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

Error Message:
ObjectTracker found 4 object(s) that were not released!!! 
[MDCAwareThreadPoolExecutor, MockDirectoryWrapper, MockDirectoryWrapper, 
SolrCore]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 4 object(s) that were not 
released!!! [MDCAwareThreadPoolExecutor, MockDirectoryWrapper, 
MockDirectoryWrapper, SolrCore]
at __randomizedtesting.SeedInfo.seed([4C707C46A220E571]: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:258)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


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

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) 
Thread[id=709, name=searcherExecutor-272-thread-1, state=WAITING, 
group=TGRP-TestLazyCores] at sun.misc.Unsafe.park(Native Method)
 at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.core.TestLazyCores: 
   1) Thread[id=709, name=searcherExecutor-272-thread-1, state=WAITING, 
group=TGRP-TestLazyCores]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at 

[jira] [Commented] (SOLR-8149) Core Selector -> Plugins / Stats - active item is not highlighted

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-8149:
-

I confirm this is still happening in master.

> Core Selector -> Plugins / Stats - active item is not highlighted
> -
>
> Key: SOLR-8149
> URL: https://issues.apache.org/jira/browse/SOLR-8149
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: 5.3.1
>Reporter: Labuzov Dmitriy
>Priority: Trivial
> Attachments: SOLR-8149.patch
>
>
> Angular UI version:
> Select a core in 'Core Selector' then go to 'Plugins / Stats', then select 
> any item (ex., CACHE) - active item is not highlighted (it does in Original 
> UI).



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

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

[jira] [Commented] (SOLR-4861) Simple reflected cross site scripting vulnerability

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-4861:
-

The code is still there.
However, it is in the embedded Jetty wrapper which is used solely in test code. 
I can't see how this can get leveraged into the the vulnerability. Are there 
more details on this?

> Simple reflected cross site scripting vulnerability
> ---
>
> Key: SOLR-4861
> URL: https://issues.apache.org/jira/browse/SOLR-4861
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 4.2, 4.3
> Environment: Requires web ui / Jetty Solr to be exploited.
>Reporter: John Menerick
>  Labels: security
>
> There exists a simple XSS via the 404 Jetty / Solr code.  Within 
> JettySolrRunner.java, line 465, if someone asks for a non-existent page / url 
> which contains malicious code, the "Can not find" can be escaped and 
> malicious code will be executed on the victim's browser. 



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

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

[jira] [Commented] (SOLR-8987) UI: Schema Browser doesn't show details for field names that start with underscore?

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-8987:
-

I cannot reproduce this in master on new UI.

> UI: Schema Browser doesn't show details for field names that start with 
> underscore?
> ---
>
> Key: SOLR-8987
> URL: https://issues.apache.org/jira/browse/SOLR-8987
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: 6.0
>Reporter: Hoss Man
>Assignee: Upayavira
> Attachments: SOLR-8987.png
>
>
> * {{bin/solr -e cloud -noprompt}}
> * http://127.0.1.1:8983/solr/#/films/schema?field=_text_
> "Field Type:" and "Flags:" show nothing, and none of the analyzer info is 
> visible.
> work arround: use the old ui...
> http://127.0.1.1:8983/solr/old.html#/gettingstarted_shard1_replica2/schema-browser?field=_text_



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

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

[jira] [Commented] (SOLR-4794) UI is broken on browsers for Android

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-4794:
-

This is an ancient bug request against old browsers with legacy UI. Safe to 
close, I think. The current (Angular) UI does seem to work on Android browsers 
(just tested). Any specific new issues should be in a new case.

> UI is broken on browsers for Android
> 
>
> Key: SOLR-4794
> URL: https://issues.apache.org/jira/browse/SOLR-4794
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 4.3
> Environment: HTC Amaze 4G
>Reporter: Shawn Heisey
>Priority: Minor
> Fix For: 6.0
>
>
> I've tried three browsers for my Android phone, an Amaze 4G by HTC.  All of 
> them have problems.
> One problem common to all of them is that the stuff on the left-hand side of 
> the screen always stays put and will cover up the rest of the page if you 
> zoom in and/or scroll around.
> 1) Built-in browser: I think this is probably provided or modified by HTC.  
> This one is extremely broken. By clicking in what looks like incorrect 
> places, you can select a core, but you can't get to any of the good stuff 
> like the query or analysis UI.
> 2) Chrome for Android: Better than the HTC/Android browser.  I can get to the 
> query UI, but when I try to execute a query, it goes back to the dashboard.
> 3) Firefox for Android: Works fairly well on the few things I tested, except 
> for the left-hand stuff covering the rest of the page as mentioned above.  I 
> don't know if everything is working, but this is the only one that let me use 
> the query UI.



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

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

[jira] [Commented] (SOLR-7841) solradmin's query browser incorrectly renders docs with large ID large numbers

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-7841:
-

This is a very old bug report. It does not seem to be a problem against new 
(Angular) Admin UI. I just tested on master with several browsers on Mac and 
Windows.


> solradmin's query browser incorrectly renders docs with large ID large numbers
> --
>
> Key: SOLR-7841
> URL: https://issues.apache.org/jira/browse/SOLR-7841
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 4.10.4
>Reporter: Erick Tryzelaar
>
> JavaScript JSON engines parse integers as a floating point number. This 
> causes problems for documents a large id, such as {{38585496994725888}}, 
> which gets cast into the floating point number {{38585496994725890}}. This 
> means that one cannot reliably copy an id from a {{\*:\*}} query and search 
> for it with {{id:...}}.



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

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

[jira] [Commented] (SOLR-8645) New UI is not HTML Encoding XML

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-8645:
-

Is this for collection/files screen? If so, the problem is gone in the latest 
(Angular) Admin UI in master. In fact, I think it might have been fixed as a 
sideproduct of SOLR-6992 even earlier.

> New UI is not HTML Encoding XML
> ---
>
> Key: SOLR-8645
> URL: https://issues.apache.org/jira/browse/SOLR-8645
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 5.4.1
>Reporter: David Johnson
>Priority: Minor
>
> When viewing the Zookeeper configuration, the managed-schema file is 
> displayed without HTML encoding. This results in only the inner text of the 
> configuration elements being displayed, rather than the full XML structure.  
> This only applies to the New UI.



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

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

[jira] [Commented] (SOLR-5270) lastModified not updating when selecting another core in Core Admin

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-5270:
-

This does not seem to happen with the new Angular UI (on master). I tested on 
Mac, Windows and Android.

> lastModified not updating when selecting another core in Core Admin
> ---
>
> Key: SOLR-5270
> URL: https://issues.apache.org/jira/browse/SOLR-5270
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Reporter: Simon Endele
>Priority: Minor
>
> When selecting a core in the section "Core Admin" in the Solr Admin web UI, 
> data like dataDir, version, numDocs, maxDoc are updated via JavaScript, but 
> lastModified is not. A refresh of the page does the trick.
> Had a look into the network traffic of my browser and it seems that the JSON 
> fetched via AJAX contains the correct information.
> Can be reproduced in different browsers with the example by cloning 
> collection1 into a collection2 and indexing collection2 anew by calling "java 
> -jar post.jar *.xml" in the exampledocs directory.
> Tested with Solr 4.4.0.



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

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

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

[Policeman Jenkins Server]

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

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

Error Message:
java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 
127.0.0.1:47749/solr within 1 ms

Stack Trace:
org.apache.solr.common.SolrException: java.util.concurrent.TimeoutException: 
Could not connect to ZooKeeper 127.0.0.1:47749/solr within 1 ms
at 
__randomizedtesting.SeedInfo.seed([4F5F7943788FF4A5:C70B4699D673995D]:0)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:181)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:115)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:105)
at 
org.apache.solr.common.cloud.ZkStateReader.(ZkStateReader.java:227)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.connect(CloudSolrClient.java:560)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.getCommonCloudSolrClient(AbstractFullDistribZkTestBase.java:1737)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkCollectionExpectations(AbstractFullDistribZkTestBase.java:1669)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkForCollection(AbstractFullDistribZkTestBase.java:1710)
at 
org.apache.solr.cloud.AliasIntegrationTest.test(AliasIntegrationTest.java:76)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-5651) Make labels clickable and the output wrapped in UI

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-5651:
-

Can be closed? All of these seem resolved in the new (Angular) admin UI.

> Make labels clickable and the output wrapped in UI
> --
>
> Key: SOLR-5651
> URL: https://issues.apache.org/jira/browse/SOLR-5651
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 4.6
>Reporter: Artem Lukanin
> Fix For: 4.9, 6.0
>
> Attachments: SOLR-5651_clickable_labels.patch, 
> SOLR-5651_clickable_labels.patch
>
>
> Now it is practically impossible to tick off check boxes in the UI, because 
> the label text is wrapped in a fancy A tag without HREF.
> Also it is very hard to read the output on the Query menu when 
> debugQuery=true. It is impossible to scroll the window to the right. It would 
> be better if the text in the PRE tag was wrapped.



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

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

[jira] [Updated] (LUCENE-7397) Inefficient FVhighlighting when set many HighlightedField.

[donghyun Kim (JIRA)]

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

donghyun Kim updated LUCENE-7397:
-
Description: 
when highlighting, search result 
org.apache.lucene.search.vectorhighlight.FastVectorHighlighter.java
getBestFragment method ~ FieldTermStack.java read whole doc's termvector every 
highlighted field.
It causes slow query when many highlight field


  was:
when highlighting result 
org.apache.lucene.search.vectorhighlight.FastVectorHighlighter.java
getBestFragment method ~ FieldTermStack.java read termvector every highlighted 
field.



> Inefficient FVhighlighting when set many HighlightedField.
> --
>
> Key: LUCENE-7397
> URL: https://issues.apache.org/jira/browse/LUCENE-7397
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
> Environment: CentOS release 6.4 (Final)
> quad core 1.87
> 8gb memory
> tested Elasticsearch - 1.5 with lucene 4.10.4 
> But i see mirrored Master version in github 
> https://github.com/apache/lucene-solr
>Reporter: donghyun Kim
>Priority: Minor
>
> when highlighting, search result 
> org.apache.lucene.search.vectorhighlight.FastVectorHighlighter.java
> getBestFragment method ~ FieldTermStack.java read whole doc's termvector 
> every highlighted field.
> It causes slow query when many highlight field



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

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

[jira] [Updated] (LUCENE-7397) Inefficient FVhighlighting when set many HighlightedField.

[donghyun Kim (JIRA)]

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

donghyun Kim updated LUCENE-7397:
-
Environment: 
CentOS release 6.4 (Final)
quad core 1.87
8gb memory
tested Elasticsearch - 1.5 with lucene 4.10.4 
But i see mirrored Master version in github 
https://github.com/apache/lucene-solr

  was:
CentOS release 6.4 (Final)
quad core 1.87
8gb memory
Elasticsearch - 1.5 with lucene 4.10.4


> Inefficient FVhighlighting when set many HighlightedField.
> --
>
> Key: LUCENE-7397
> URL: https://issues.apache.org/jira/browse/LUCENE-7397
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
> Environment: CentOS release 6.4 (Final)
> quad core 1.87
> 8gb memory
> tested Elasticsearch - 1.5 with lucene 4.10.4 
> But i see mirrored Master version in github 
> https://github.com/apache/lucene-solr
>Reporter: donghyun Kim
>Priority: Minor
>
> when highlighting result 
> org.apache.lucene.search.vectorhighlight.FastVectorHighlighter.java
> getBestFragment method ~ FieldTermStack.java read termvector every 
> highlighted field.



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

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

[jira] [Commented] (LUCENE-7397) Inefficient FVhighlighting when set many HighlightedField.

[donghyun Kim (JIRA)]

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

donghyun Kim commented on LUCENE-7397:
--



when each searchDoc's highlightPhase, It calls highlighter's(In this case, FVH) 
highlight(highlighterContext).
In FastVectorHighlighter.java, loop for each requested 'HighlightedField' and 
getBestFragments.
getBestFragments method receive parameter[2] hitContext.docId() that uses for 
getting termVector of doc.
It finally reach org.apache.lucene.search.vectorhighlight.FieldTermStack.java 
and get termVector of doc.

The problem is 
'every highlightedField's getBestFragments method' call
 final Fields vectors = reader.getTermVectors(docId); 

and it seems Inefficiently slow when search highlight result include (big 
document && many highlightedField). read whole doc's termvector with every 
highlightedField.

my testing machine:
quad 1.87 ghz,
8Gb memory,
spinning disk.
ES-1.5.2 (relevent code not changed, when I saw)

Example,
my query :
`
{
"from" : 0,
"size" : 20,

"query" : {
"query about highlighted field and more"},
"explain" : false,
"fields" : [ "highlight", "fileRevision", "ownerNameUnigram", "ownerName", 
"ownerId", "timeLastModified", "size" ],
"sort" : [ {
"_score" : { }
} ],
"highlight" : {
"pre_tags" : [ "" ],
"post_tags" : [ "" ],
"order" : "score",
"fragment_size" : 128,
"number_of_fragments" : 10,
"require_field_match" : true,
"type" : "fvh",
"fields" : [ {
"ownerName" : { }
}, {
"fileName_ko" : { }
}, {
"fileName_en" : { }
}, {
"fileName_id" : { }
}, {
"fileName_es" : { }
}, {
"fileName_zh" : { }
}, {
"fileName_ja" : { }
}, {
"fileName_it" : { }
}, {
"fileName_ru" : { }
}, {
"fileName_pt" : { }
}, {
"fileName_hi" : { }
}, {
"fileName_etc" : { }
}, {
"contents_ko" : { }
}, {
"contents_ko.ngram" : { }
}, {
"contents_en" : { }
}, {
"contents_en.ngram" : { }
}, {
"contents_id" : { }
}, {
"contents_id.ngram" : { }
}, {
"contents_es" : { }
}, {
"contents_es.ngram" : { }
}, {
"contents_zh" : { }
}, {
"contents_zh.ngram" : { }
}, {
"contents_ja" : { }
}, {
"contents_ja.ngram" : { }
}, {
"contents_it" : { }
}, {
"contents_it.ngram" : { }
}, {
"contents_ru" : { }
}, {
"contents_ru.ngram" : { }
}, {
"contents_pt" : { }
}, {
"contents_pt.ngram" : { }
}, {
"contents_hi" : { }
}, {
"contents_hi.ngram" : { }
}, {
"contents_etc" : { }
}, {
"contents_etc.ngram" : { }
} ]
}
}
`

Test
[tookTime in millis, getBestFragments]
my doc 12538's every field getBestFragments took about 20ms. 
and total highlight phase tooks 705 ms.

I have a sparse mapping field. that means
'doc 12538' field fileName_*
[fileName_id , fileName_es, fileName_zh, fileName_ja, fileName_it, fileName_ru, 
fileName_pt, fileName_hi, fileName_etc]
only one field is filled with data among this array.
It's same to contents_* field.

dangerous doc 12538 - 
CONVOCADOS_TALLER_SALUDMENTAL_JULIO2014.xlsx.txt

[2016-07-26 16:57:04,043][INFO ][root ] [4][FastVectorHighlighter.highlight] 
[22], filedName : fileName_id, docId : 12538
[23], filedName : fileName_id, docId : 12538
[20], filedName : fileName_es, docId : 12538
[21], filedName : fileName_zh, docId : 12538
[21], filedName : fileName_ja, docId : 12538
[28], filedName : fileName_it, docId : 12538
[26], filedName : fileName_ru, docId : 12538
[24], filedName : fileName_pt, docId : 12538
[22], filedName : fileName_hi, docId : 12538
[22], filedName : fileName_etc, docId : 12538
[22], filedName : contents_ko, docId : 12538
[20], filedName : contents_ko.ngram, docId : 12538
[19], filedName : contents_en, docId : 12538
[19], filedName : contents_en.ngram, docId : 12538
[20], filedName : contents_id, docId : 12538
[20], filedName : contents_id.ngram, docId : 12538
[19], filedName : contents_es, docId : 12538
[18], filedName : contents_es.ngram, docId : 12538
[19], filedName : contents_zh, docId : 12538
[19], filedName : contents_zh.ngram, docId : 12538
[19], filedName : contents_ja, docId : 12538
[19], filedName : contents_ja.ngram, docId : 12538
[18], filedName : contents_it, docId : 12538
[18], filedName : contents_it.ngram, docId : 12538
[18], filedName : contents_ru, docId : 12538
[18], filedName : contents_ru.ngram, docId : 12538
[20], filedName : contents_pt.ngram, docId : 12538
[18], filedName : contents_hi, docId : 12538
[18], filedName : contents_hi.ngram, docId : 12538
[18], filedName : contents_etc, docId : 12538
[19], filedName : contents_etc.ngram, docId : 12538
[2016-07-26 16:57:04,654][INFO ][root ] highlight tooks : 705, docId : 12538

and...
reader.getTermVectors(docId) tooks.
I didn't log sync with getBestFragments took. but i can see rough sequence and 
how it tooks.
I think heavy analyzed doc (have big termvectors) impact my query. (around 20ms 
sequence.)

long tTime = System.currentTimeMillis();
final Fields vectors = reader.getTermVectors(docId);
termVectorTimeLogging("tVectorTime : "+(System.currentTimeMillis() - tTime));

tVectorTime : 1

[jira] [Created] (LUCENE-7397) Inefficient FVhighlighting when set many HighlightedField.

[donghyun Kim (JIRA)]

donghyun Kim created LUCENE-7397:


 Summary: Inefficient FVhighlighting when set many HighlightedField.
 Key: LUCENE-7397
 URL: https://issues.apache.org/jira/browse/LUCENE-7397
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/search
 Environment: CentOS release 6.4 (Final)
quad core 1.87
8gb memory
Elasticsearch - 1.5 with lucene 4.10.4
Reporter: donghyun Kim
Priority: Minor


when highlighting result 
org.apache.lucene.search.vectorhighlight.FastVectorHighlighter.java
getBestFragment method ~ FieldTermStack.java read termvector every highlighted 
field.




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

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

[jira] [Commented] (SOLR-8596) Web UI doesn't correctly generate queries which include local parameters

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-8596:
--

GitHub user arafalov opened a pull request:

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

SOLR-8596: Split only on first equal sign

Being more careful about splitting only on first equal sign, not all of 
them for raw requests. This avoids breaking local parameters syntax.

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

$ git pull https://github.com/arafalov/lucene-solr-contributions 
alex-SOLR-8596

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

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


commit d80ce4a71fe5ac219355d4c096791a17f4173e00
Author: Alexandre Rafalovitch 
Date:   2016-07-27T00:02:00Z

SOLR-8596: Split only on first equal sign




> Web UI doesn't correctly generate queries which include local parameters
> 
>
> Key: SOLR-8596
> URL: https://issues.apache.org/jira/browse/SOLR-8596
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 5.4
> Environment: Windows 8.1 Pro x64
>Reporter: Ismael Teijeiro Flórez
>Priority: Minor
>  Labels: local-parameters
>
> When configuring the "Raw Query Parameters" field for a query with a value 
> like the following, the generated query is incorrect:
> {{stats=true=\{!min=true 20max=true\}MYFIELD}}
> The generated query in this case: 
> {noformat}
> http://localhost:8983/solr/mycollection/select?indent=on=*:*=0=\{!min=true=json
> {noformat}
> As you can see, the following fragment is incorrect: {{stats.field=\{!min}}.
> This is the obtained response:
> {noformat}
> {
>   "responseHeader":{
> "status":400,
> "QTime":0,
> "params":{
>   "indent":"on",
>   "stats.field":"{!min",
>   "stats":"true",
>   "q":"*:*",
>   "_":"1453742574279",
>   "wt":"json",
>   "rows":"0"}},
>   "error":{
> "msg":"Unable to parse stats.field: {!min due to: Expected identifier at 
> pos 5 str='{!min'",
> "code":400}}
> {noformat}
> If the following URL is pasted directly in the browser, the query works as 
> expected:
> {noformat}
> http://localhost:8983/solr/mycollection/select?indent=on=*:*=0={!min=true
>  max=true}MYFIELD=true=json
> {noformat}



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

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

[GitHub] lucene-solr pull request #56: SOLR-8596: Split only on first equal sign

[arafalov]

GitHub user arafalov opened a pull request:

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

SOLR-8596: Split only on first equal sign

Being more careful about splitting only on first equal sign, not all of 
them for raw requests. This avoids breaking local parameters syntax.

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

$ git pull https://github.com/arafalov/lucene-solr-contributions 
alex-SOLR-8596

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

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


commit d80ce4a71fe5ac219355d4c096791a17f4173e00
Author: Alexandre Rafalovitch 
Date:   2016-07-27T00:02:00Z

SOLR-8596: Split only on first equal sign




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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1282/
Java: 64bit/jdk1.8.0_92 -XX:-UseCompressedOops -XX:+UseG1GC

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

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

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

[jira] [Commented] (LUCENE-7396) Speed up flush of 1-dimension points

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7396:


Also, for these tests, I fixed IW's buffer to be the same (i.e. didn't count 
the {{int[] ords}} against IW's buffer), so that in both cases we are flushing 
after the same number of docs.

> Speed up flush of 1-dimension points
> 
>
> Key: LUCENE-7396
> URL: https://issues.apache.org/jira/browse/LUCENE-7396
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7396.patch, LUCENE-7396.patch
>
>
> 1D points already have an optimized merge implementation which works when 
> points come in order. So maybe we could make IndexWriter's PointValuesWriter 
> sort before feeding the PointsFormat and somehow propagate the information to 
> the PointsFormat?
> The benefit is that flushing could directly stream points to disk with little 
> memory usage.



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

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

[jira] [Commented] (LUCENE-7396) Speed up flush of 1-dimension points

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7396:


I added a sop for how long it takes to flush each field's points.

Trunk:
{noformat}
127.0.0.1: IW 0 [2016-07-26T23:44:01.962Z; LuceneIndexing-1-thread-1]: 2047 
msec to write docValues
127.0.0.1: FIELD surcharge: 2218.62956 msec
127.0.0.1: FIELD pick_up_lon: 1968.539463 msec
127.0.0.1: FIELD mta_tax: 1967.196068 msec
127.0.0.1: FIELD fare_amount: 2179.47771 msec
127.0.0.1: FIELD trip_distance: 2042.19908 msec
127.0.0.1: FIELD pick_up_lat: 2002.735026 msec
127.0.0.1: FIELD drop_off_date_time: 1315.330631 msec
127.0.0.1: FIELD tolls_amount: 1942.725832 msec
127.0.0.1: FIELD passenger_count: 797.681094 msec
127.0.0.1: FIELD drop_off_lon: 1937.206549 msec
127.0.0.1: FIELD total_amount: 1987.058896 msec
127.0.0.1: FIELD pick_up_date_time: 1296.005252 msec
127.0.0.1: FIELD tip_amount: 2063.410329 msec
127.0.0.1: FIELD drop_off_lat: 2045.020601 msec
127.0.0.1: IW 0 [2016-07-26T23:44:27.726Z; LuceneIndexing-1-thread-1]: 25764 
msec to write points
{noformat}

and patch:

{noformat}
127.0.0.1: IW 0 [2016-07-26T23:49:54.494Z; LuceneIndexing-1-thread-1]: 2033 
msec to write docValues
127.0.0.1: FIELD surcharge: 2137.926903 msec
127.0.0.1: FIELD pick_up_lon: 2511.391725 msec
127.0.0.1: FIELD mta_tax: 2144.822578 msec
127.0.0.1: FIELD fare_amount: 3232.977894 msec
127.0.0.1: FIELD trip_distance: 2545.771801 msec
127.0.0.1: FIELD pick_up_lat: 2939.796276 msec
127.0.0.1: FIELD drop_off_date_time: 1272.857191 msec
127.0.0.1: FIELD tolls_amount: 2042.863782 msec
127.0.0.1: FIELD passenger_count: 565.551751 msec
127.0.0.1: FIELD drop_off_lon: 2493.79608 msec
127.0.0.1: FIELD total_amount: 2596.043882 msec
127.0.0.1: FIELD pick_up_date_time: 1308.397927 msec
127.0.0.1: FIELD tip_amount: 2316.962831 msec
127.0.0.1: FIELD drop_off_lat: 2748.935673 msec
127.0.0.1: IW 0 [2016-07-26T23:50:25.415Z; LuceneIndexing-1-thread-1]: 30920 
msec to write points
{noformat}

This is using 1 thread w/ 1 GB IW buffer.

Some fields seem to take similar time, but others are sizably different (e.g. 
the lat/lon points) ... odd.

> Speed up flush of 1-dimension points
> 
>
> Key: LUCENE-7396
> URL: https://issues.apache.org/jira/browse/LUCENE-7396
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7396.patch, LUCENE-7396.patch
>
>
> 1D points already have an optimized merge implementation which works when 
> points come in order. So maybe we could make IndexWriter's PointValuesWriter 
> sort before feeding the PointsFormat and somehow propagate the information to 
> the PointsFormat?
> The benefit is that flushing could directly stream points to disk with little 
> memory usage.



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

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

[jira] [Commented] (SOLR-8596) Web UI doesn't correctly generate queries which include local parameters

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-8596:
-

I confirm this against the trunk with 
{code}
 stats=true={!min=true max=true}popularity
{code}

> Web UI doesn't correctly generate queries which include local parameters
> 
>
> Key: SOLR-8596
> URL: https://issues.apache.org/jira/browse/SOLR-8596
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 5.4
> Environment: Windows 8.1 Pro x64
>Reporter: Ismael Teijeiro Flórez
>Priority: Minor
>  Labels: local-parameters
>
> When configuring the "Raw Query Parameters" field for a query with a value 
> like the following, the generated query is incorrect:
> {{stats=true=\{!min=true 20max=true\}MYFIELD}}
> The generated query in this case: 
> {noformat}
> http://localhost:8983/solr/mycollection/select?indent=on=*:*=0=\{!min=true=json
> {noformat}
> As you can see, the following fragment is incorrect: {{stats.field=\{!min}}.
> This is the obtained response:
> {noformat}
> {
>   "responseHeader":{
> "status":400,
> "QTime":0,
> "params":{
>   "indent":"on",
>   "stats.field":"{!min",
>   "stats":"true",
>   "q":"*:*",
>   "_":"1453742574279",
>   "wt":"json",
>   "rows":"0"}},
>   "error":{
> "msg":"Unable to parse stats.field: {!min due to: Expected identifier at 
> pos 5 str='{!min'",
> "code":400}}
> {noformat}
> If the following URL is pasted directly in the browser, the query works as 
> expected:
> {noformat}
> http://localhost:8983/solr/mycollection/select?indent=on=*:*=0={!min=true
>  max=true}MYFIELD=true=json
> {noformat}



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

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

[jira] [Commented] (LUCENE-7396) Speed up flush of 1-dimension points

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7396:


These results are awesome!  I tested {{IndexAndSearchOpenStreetMaps1D}} and saw 
good indexing gains.

However, I also tested with the NYC taxi data 
(http://www.nyc.gov/html/tlc/html/about/trip_record_data.shtml).  Each of these 
docs has ~20 points, and unfortunately somehow writing points (from the IW log) 
is a bit (10-20%) slower.  I wonder if something about the data distribution 
somehow affects the performance change here?

Also, I don't think we should pre-budget into IW's buffer for the int[] ords we 
allocate?  That is really a transient thing, only allocated (and then freed, or 
at least reclaimable by GC) for the one field currently writing its points, so 
I think it's fair to not count that against IW's buffer?  It's allowed that IW 
allocates heap beyond its RAM buffer for transient things like this...

> Speed up flush of 1-dimension points
> 
>
> Key: LUCENE-7396
> URL: https://issues.apache.org/jira/browse/LUCENE-7396
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7396.patch, LUCENE-7396.patch
>
>
> 1D points already have an optimized merge implementation which works when 
> points come in order. So maybe we could make IndexWriter's PointValuesWriter 
> sort before feeding the PointsFormat and somehow propagate the information to 
> the PointsFormat?
> The benefit is that flushing could directly stream points to disk with little 
> memory usage.



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

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

[jira] [Created] (SOLR-9345) Solr admin UI - cloud tab document enhancements

[nirav patel (JIRA)]

nirav patel created SOLR-9345:
-

 Summary: Solr admin UI - cloud tab document enhancements
 Key: SOLR-9345
 URL: https://issues.apache.org/jira/browse/SOLR-9345
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: documentation
Affects Versions: 6.1
Reporter: nirav patel


I think Cloud tab in Solr Admin UI can use lots of improvement. 
https://cwiki.apache.org/confluence/display/solr/Cloud+Screens
e.g. Explaining what each directory is, where it stored and what information it 
contains. description of fields like what aversion, children_count, ctime etc

Also please link the above document or specific section to other docs that 
refereing its content. Like in following I had no idea what Zookeeper 'configs' 
directory was until I found it in Admin UI by myself.
https://cwiki.apache.org/confluence/display/solr/Solr+Start+Script+Reference#SolrStartScriptReference-ConfigurationDirectoriesandSolrCloud



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

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

[jira] [Commented] (SOLR-8201) Swap space info not showing in new UI (see screenshot)

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-8201:
-

I cannot reproduce this on master. Checked the browser on Mac and Windows. I 
suspect that - if this problem still exists - it would be more about 
configuration of the server. 

So, without more specific reproduction, this can probably be close as 
Non-reproducible.

> Swap space info not showing in new UI (see screenshot)
> --
>
> Key: SOLR-8201
> URL: https://issues.apache.org/jira/browse/SOLR-8201
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Reporter: Youssef Chaker
>Assignee: Upayavira
>Priority: Minor
> Attachments: swap space.png
>
>
> The old UI displays info about the swap space (even if nothing is allocated) 
> whereas the new UI does not (see screenshot).



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

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

[jira] [Commented] (SOLR-8715) New Admin UI's Schema screen fails for some fields

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-8715:
--

GitHub user arafalov opened a pull request:

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

SOLR-8715: Added special condition to match server

One-line fix. Just a missed condition to match server-side special case.

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

$ git pull https://github.com/arafalov/lucene-solr-contributions 
alex-SOLR-8715

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

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


commit 8a6f462458a1e6610027271b4212f132dee33df5
Author: Alexandre Rafalovitch 
Date:   2016-07-26T23:09:09Z

SOLR-8715: Added special condition to match server




> New Admin UI's Schema screen fails for some fields
> --
>
> Key: SOLR-8715
> URL: https://issues.apache.org/jira/browse/SOLR-8715
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: 5.5, 6.0
> Environment: mac, firefox
>Reporter: Alexandre Rafalovitch
>Assignee: Upayavira
>  Labels: admin-interface
> Attachments: Problem shown in the released 5.5 version.png
>
>
> In techproducts example, using new Admin UI and trying to load the Schema for 
> text field causes blank screen and the Javascript error in the developer 
> console:
> {noformat}
> Error: row.flags is undefined
> getFieldProperties@http://localhost:8983/solr/js/angular/controllers/schema.js:482:40
> $scope.refresh/http://localhost:8983/solr/js/angular/controllers/schema.js:76:38
> 
> {noformat}
> Tested with 5.5rc3



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

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

[GitHub] lucene-solr pull request #55: SOLR-8715: Added special condition to match se...

[arafalov]

GitHub user arafalov opened a pull request:

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

SOLR-8715: Added special condition to match server

One-line fix. Just a missed condition to match server-side special case.

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

$ git pull https://github.com/arafalov/lucene-solr-contributions 
alex-SOLR-8715

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

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


commit 8a6f462458a1e6610027271b4212f132dee33df5
Author: Alexandre Rafalovitch 
Date:   2016-07-26T23:09:09Z

SOLR-8715: Added special condition to match server




---
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-9252) Feature selection and logistic regression on text

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-9252:
--

Ok, I have the patch running and it looks great.

I have the following expression running:

{code}
train(training, 
features(training, q="*:*", featureSet="first", field="body", 
outcome="out_i", numTerms=200), 
q="*:*", 
name="model", 
field="body", 
outcome="out_i", 
maxIterations=100)
{code}

In the patch *train* is still the function name in the /stream handler. But we 
can make a final decision on this before committing.

The accuracy seems to be 98% on the Enron training data with this patch. Here 
is the final model:

{code}
{
"idfs_ds": [1.2627703388716238, 1.2043595767152093, 
1.3886172425360304, 1.5488587854881268, 1.6127302558747882, 2.1359177807201526, 
1.514866246141212, 1.7375701403808523, 1.6166175299631897, 1.756428159015249, 
1.7929202354640175, 1.2834893120635762, 1.899442866302021, 1.8639061320252337, 
1.7631697575821685, 1.6820002892260415, 1.4411352768194767, 2.103708877350535, 
1.2225773869965861, 2.208893321170597, 1.878981794430681, 2.043737027506736, 
2.2819184561854864, 2.3264563106163885, 1.9336117619172708, 2.0467265663551024, 
1.7386696457142692, 2.468795829515302, 2.069437610615317, 2.6294363202479327, 
3.7388303845193307, 2.5446615802900157, 1.7430797961918219, 3.0787440662202736, 
1.9579702057493114, 2.289523055570706, 1.5362003886162032, 2.7549569891263763, 
3.955894889757158, 2.587435396273302, 3.945844553903657, 1.003513057076781, 
3.0416264032637708, 2.248395764146843, 4.018415246738492, 2.2876164773001246, 
3.3636289340509933, 1.2438124251270097, 2.733903579928544, 3.439026951535205, 
0.6709665389201712, 0.9546224358275518, 2.8080115520822657, 2.477970205791343, 
2.2631561797299637, 3.2378087608499606, 0.36177021415584676, 
4.1083634834014315, 4.120197941048435, 2.471081544796158, 2.424147775633, 
2.92339362620, 2.9269972337044097, 3.2987413118451183, 2.383498249003407, 
4.168988105217867, 2.877691472720256, 4.233526626355437, 3.8505343740993316, 
2.3264563106163885, 2.6429318017228174, 4.260555298743357, 3.0058372954121855, 
3.8688835127675283, 3.021585652380325, 3.0295538220295017, 1.9620882623582288, 
3.469610374907285, 3.945844553903657, 3.4821105376715167, 4.3169082352944885, 
2.520329479630485, 3.609372317282444, 3.070375816549757, 4.220281399605417, 
3.985484239117, 3.6165408067610563, 3.788840805093992, 4.392131656532076, 
4.392131656532076, 2.837281934382379, 3.698984475972131, 4.331507034715641, 
2.360699334038601, 2.7368842080666815, 3.730733174286711, 3.1991566064156816, 
4.4238803548466565, 2.4665153268165767, 3.175736332207583, 3.2378087608499606, 
4.376627469996111, 3.3525177086259226, 3.28315658082842, 4.156565585219309, 
1.6462639699299098, 2.673278958112109, 4.331507034715641, 3.955894889757158, 
2.7764631943473397, 3.0497565293470212, 1.79060004880832, 3.6237610547345436, 
1.6244377066690232, 2.948895919012047, 3.175736332207583, 2.850571166501062, 
4.073677925413541, 2.725014632511298, 3.1573871935393867, 4.562030693327474, 
3.5403794457954922, 4.580722826339627, 4.580722826339627, 3.189722574182323, 
3.1665196771026594, 3.3306589148134234, 1.9745451708435238, 3.3306589148134234, 
2.795272526304836, 3.3415285870503273, 4.407880013500216, 4.4238803548466565, 
2.6902285164258823, 3.668212817305377, 4.543681554659277, 2.559550192783766, 
1.5452257206382456, 2.2631561797299637, 4.659194441781121, 3.2678110111537597, 
3.878185905429842, 3.3525177086259226, 3.374865007317919, 3.780330115426083, 
4.376627469996111, 3.433020927474993, 3.6758174166905966, 4.288334862850433, 
3.2378087608499606, 4.490571729345329, 2.9269972337044097, 4.029226162842708, 
3.0538465145985465, 4.440140875718437, 3.533734903076824, 4.659194441781121, 
4.659194441781121, 4.525663049156599, 3.706827653433157, 3.1172927363375087, 
4.490571729345329, 2.552078177945065, 2.087985282971078, 4.83744267318744, 
4.562030693327474, 4.09666744363824, 4.659194441781121, 1.802255192400069, 
4.599771021310321, 3.788840805093992, 4.8621352857778115, 4.6798137289838575, 
4.376627469996111, 3.272900080661231, 3.8970543897342247, 4.638991734463602, 
4.638991734463602, 4.813345121608379, 4.813345121608379, 4.8621352857778115, 
4.83744267318744, 3.588170109631841, 4.13217413209515, 4.599771021310321, 
4.331507034715641, 3.134914337687328, 4.525663049156599, 4.722373343402653, 
3.955894889757158, 4.967495801435638, 4.580722826339627, 4.967495801435638, 
4.9134285801653625, 4.887453093762102, 4.407880013500216, 4.246949646687578, 
2.198385343572182, 1.5963758750107606, 4.007719957621744],
"alpha_d": 7.150861416624748E-4,
"terms_ss": ["enron", "2000", "cc", "hpl", "daren", 
"http", "gas", "forwarded", "pm", "ect", "hou", "thanks", "meter", 

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17376/
Java: 64bit/jdk-9-ea+127 -XX:+UseCompressedOops -XX:+UseParallelGC

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

Error Message:
Could not get expected value  'P val' for path 'response/params/y/p' full 
output: {   "responseHeader":{ "status":0, "QTime":0},   "response":{   
  "znodeVersion":2, "params":{   "x":{ "a":"A val", 
"b":"B val", "":{"v":0}},   "y":{ "c":"CY val modified",
 "b":"BY val", "i":20, "d":[   "val 1",   
"val 2"], "e":"EY val", "":{"v":1},  from server:  
https://127.0.0.1:38818/collection1

Stack Trace:
java.lang.AssertionError: Could not get expected value  'P val' for path 
'response/params/y/p' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "response":{
"znodeVersion":2,
"params":{
  "x":{
"a":"A val",
"b":"B val",
"":{"v":0}},
  "y":{
"c":"CY val modified",
"b":"BY val",
"i":20,
"d":[
  "val 1",
  "val 2"],
"e":"EY val",
"":{"v":1},  from server:  https://127.0.0.1:38818/collection1
at 
__randomizedtesting.SeedInfo.seed([4A8D07A20755D971:C2D93878A9A9B489]: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:481)
at 
org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:215)
at 
org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:61)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1281/
Java: 64bit/jdk-9-ea+127 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

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

Error Message:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:36952/c8n_1x3_lf_shard1_replica1]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:36952/c8n_1x3_lf_shard1_replica1]
at 
__randomizedtesting.SeedInfo.seed([145995930C82BB4A:9C0DAA49A27ED6B2]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:774)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1172)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1061)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:997)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:592)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:578)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:174)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:55)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

[jira] [Commented] (SOLR-9279) Add greater than, less than, etc in Solr function queries

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-9279:


I haven't been following the updates since my last comment, but to answer your 
question...

bq.  Is there documentation on an object value source? I'm not sure what's 
expected here.

...well, per the javadocs it's "Native Java Object representation of the value" 
for the doc -- ie: whatever type makes the most sense for the given value 
source (as opposed to byteVal, intVal, floatVal, etc... where the caller says 
what type they want)

For the DocValue based FunctionValues, it's the type of the field 
(IntFieldSource.getValues returns an IntDocValues which implements objectVal by 
delegating to intVal if exists is true, etc.

For ValueSources that "wrap" other value sources, things get more complicated 
-- in the IfFunction, the FunctionValues delegates to one wrapped 
FunctionValues or the other, depending on the conditional.

practically speaking: the main place objectValue comes into play is when end 
users ask for the value of a ValueSource in the fl list, ie: 
{{fl=id,value:div(popularity,price),inStock:gte(quantityonHand,1)}}

since these new functions represent boolean concepts (even if they are wrapping 
numeric inputs), i would expect them to implement objectValue the same way 
BoolDocValues does...
{code}
  @Override
  public Object objectVal(int doc) {
return exists(doc) ? boolVal(doc) : null;
  }
{code}

...ideally you'd just extend BoolDocValues since all of it's methods should 
also apply to your usecase. (maybe you were doing that in your previous patch 
and i just missed it -- i dunno? ... from my comment it looks like i mainly 
just noticed you weren't _testing_ for this usage to return Boolean objects)



> Add greater than, less than, etc in Solr function queries
> -
>
> Key: SOLR-9279
> URL: https://issues.apache.org/jira/browse/SOLR-9279
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Doug Turnbull
> Fix For: master (7.0)
>
>
> If you use the "if" function query, you'll often expect to be able to use 
> greater than/less than functions. For example, you might want to boost books 
> written in the past 7 years. Unfortunately, there's no "greater than" 
> function query that will return non-zero when the lhs > rhs. Instead to get 
> this, you need to create really awkward function queries like I do here 
> (http://opensourceconnections.com/blog/2014/11/26/stepwise-date-boosting-in-solr/):
> if(min(0,sub(ms(mydatefield),sub(ms(NOW),315569259747))),0.8,1)
> The pull request attached to this Jira adds the following function queries
> (https://github.com/apache/lucene-solr/pull/49)
> -gt(lhs, rhs) (returns 1 if lhs > rhs, 0 otherwise)
> -lt(lhs, rhs) (returns 1 if lhs < rhs, 0 otherwise)
> -gte
> -lte
> -eq
> So instead of 
> if(min(0,sub(ms(mydatefield),sub(ms(NOW),315569259747))),0.8,1)
> one could now write
> if(lt(ms(mydatefield),315569259747,0.8,1)
> (if mydatefield < 315569259747 then 0.8 else 1)
> A bit more readable and less puzzling



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

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

[jira] [Commented] (SOLR-9279) Add greater than, less than, etc in Solr function queries

[Doug Turnbull (JIRA)]

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

Doug Turnbull commented on SOLR-9279:
-

[~hossman] Thanks for your help! Great points. -- I think I addressed your 
comments other than the Object value one. Is there documentation on an object 
value source? I'm not sure what's expected here.

> Add greater than, less than, etc in Solr function queries
> -
>
> Key: SOLR-9279
> URL: https://issues.apache.org/jira/browse/SOLR-9279
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Doug Turnbull
> Fix For: master (7.0)
>
>
> If you use the "if" function query, you'll often expect to be able to use 
> greater than/less than functions. For example, you might want to boost books 
> written in the past 7 years. Unfortunately, there's no "greater than" 
> function query that will return non-zero when the lhs > rhs. Instead to get 
> this, you need to create really awkward function queries like I do here 
> (http://opensourceconnections.com/blog/2014/11/26/stepwise-date-boosting-in-solr/):
> if(min(0,sub(ms(mydatefield),sub(ms(NOW),315569259747))),0.8,1)
> The pull request attached to this Jira adds the following function queries
> (https://github.com/apache/lucene-solr/pull/49)
> -gt(lhs, rhs) (returns 1 if lhs > rhs, 0 otherwise)
> -lt(lhs, rhs) (returns 1 if lhs < rhs, 0 otherwise)
> -gte
> -lte
> -eq
> So instead of 
> if(min(0,sub(ms(mydatefield),sub(ms(NOW),315569259747))),0.8,1)
> one could now write
> if(lt(ms(mydatefield),315569259747,0.8,1)
> (if mydatefield < 315569259747 then 0.8 else 1)
> A bit more readable and less puzzling



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

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

[jira] [Updated] (SOLR-9324) Support Secure Impersonation / Proxy User for solr authentication

[Gregory Chanan (JIRA)]

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

Gregory Chanan updated SOLR-9324:
-
Attachment: SOLR-9324.patch

Here's a patch that implements this.  Note this assumes SOLR-9200 is applied, 
which hasn't been committed yet.

> Support Secure Impersonation / Proxy User for solr authentication
> -
>
> Key: SOLR-9324
> URL: https://issues.apache.org/jira/browse/SOLR-9324
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
> Attachments: SOLR-9324.patch
>
>
> Solr should support Proxy User / Secure Impersonation for authentication, as 
> supported by hadoop 
> (http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/Superusers.html)
>  and supported by the hadoop AuthenticationFilter (which we use for the 
> KerberosPlugin).
> There are a number of use cases, but a common one is this:
> There is a front end for searches (say, Hue http://gethue.com/) that supports 
> its own login mechanisms.  If the cluster uses kerberos for authentication, 
> hue must have kerberos credentials for each user, which is a pain to manage.  
> Instead, hue can be allowed to impersonate known users from known machines so 
> it only needs its own kerberos credentials.



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

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

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1079 - Still Failing

[Apache Jenkins Server]

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

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

Error Message:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:41462/c8n_1x3_lf_shard1_replica1]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:41462/c8n_1x3_lf_shard1_replica1]
at 
__randomizedtesting.SeedInfo.seed([910E0A3ACD77E473:195A35E0638B898B]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:774)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1172)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1061)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:997)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:753)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:741)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:178)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1280/
Java: 64bit/jdk1.8.0_92 -XX:+UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader

Error Message:
No live SolrServers available to handle this 
request:[http://127.0.0.1:42890/forceleader_test_collection_shard1_replica1]

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: No live 
SolrServers available to handle this 
request:[http://127.0.0.1:42890/forceleader_test_collection_shard1_replica1]
at 
__randomizedtesting.SeedInfo.seed([7E2BF878715E79B8:98BCCCB848DC80D9]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:760)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1172)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1061)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:997)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:753)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:741)
at 
org.apache.solr.cloud.ForceLeaderTest.sendDoc(ForceLeaderTest.java:424)
at 
org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader(ForceLeaderTest.java:131)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-8335) HdfsLockFactory does not allow core to come up after a node was killed

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-8335:


[~markrmil...@gmail.com] [~varunthacker] I wonder if we can utilize 
deleteOnExit functionality in HDFS.

https://hadoop.apache.org/docs/r2.6.1/api/org/apache/hadoop/fs/FileSystem.html#deleteOnExit(org.apache.hadoop.fs.Path)

> HdfsLockFactory does not allow core to come up after a node was killed
> --
>
> Key: SOLR-8335
> URL: https://issues.apache.org/jira/browse/SOLR-8335
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.0, 5.1, 5.2, 5.2.1, 5.3, 5.3.1
>Reporter: Varun Thacker
>
> When using HdfsLockFactory if a node gets killed instead of a graceful 
> shutdown the write.lock file remains in HDFS . The next time you start the 
> node the core doesn't load up because of LockObtainFailedException .
> I was able to reproduce this in all 5.x versions of Solr . The problem wasn't 
> there when I tested it in 4.10.4
> Steps to reproduce this on 5.x
> 1. Create directory in HDFS : {{bin/hdfs dfs -mkdir /solr}}
> 2. Start Solr: {{bin/solr start -Dsolr.directoryFactory=HdfsDirectoryFactory 
> -Dsolr.lock.type=hdfs -Dsolr.data.dir=hdfs://localhost:9000/solr 
> -Dsolr.updatelog=hdfs://localhost:9000/solr}}
> 3. Create core: {{./bin/solr create -c test -n data_driven}}
> 4. Kill solr
> 5. The lock file is there in HDFS and is called {{write.lock}}
> 6. Start Solr again and you get a stack trace like this:
> {code}
> 2015-11-23 13:28:04.287 ERROR (coreLoadExecutor-6-thread-1) [   x:test] 
> o.a.s.c.CoreContainer Error creating core [test]: Index locked for write for 
> core 'test'. Solr now longer supports forceful unlocking via 
> 'unlockOnStartup'. Please verify locks manually!
> org.apache.solr.common.SolrException: Index locked for write for core 'test'. 
> Solr now longer supports forceful unlocking via 'unlockOnStartup'. Please 
> verify locks manually!
> at org.apache.solr.core.SolrCore.(SolrCore.java:820)
> at org.apache.solr.core.SolrCore.(SolrCore.java:659)
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:723)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:443)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:434)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:210)
> 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:745)
> Caused by: org.apache.lucene.store.LockObtainFailedException: Index locked 
> for write for core 'test'. Solr now longer supports forceful unlocking via 
> 'unlockOnStartup'. Please verify locks manually!
> at org.apache.solr.core.SolrCore.initIndex(SolrCore.java:528)
> at org.apache.solr.core.SolrCore.(SolrCore.java:761)
> ... 9 more
> 2015-11-23 13:28:04.289 ERROR (coreContainerWorkExecutor-2-thread-1) [   ] 
> o.a.s.c.CoreContainer Error waiting for SolrCore to be created
> java.util.concurrent.ExecutionException: 
> org.apache.solr.common.SolrException: Unable to create core [test]
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> at org.apache.solr.core.CoreContainer$2.run(CoreContainer.java:472)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:210)
> 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:745)
> Caused by: org.apache.solr.common.SolrException: Unable to create core [test]
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:737)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:443)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:434)
> ... 5 more
> Caused by: org.apache.solr.common.SolrException: Index locked for write for 
> core 'test'. Solr now longer supports forceful unlocking via 
> 'unlockOnStartup'. Please verify locks manually!
> at org.apache.solr.core.SolrCore.(SolrCore.java:820)
> at org.apache.solr.core.SolrCore.(SolrCore.java:659)
> at 

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/344/
Java: 32bit/jdk1.8.0_92 -server -XX:+UseG1GC

2 tests failed.
FAILED:  org.apache.solr.handler.TestReplicationHandler.doTestStressReplication

Error Message:
[index.20160727021716332, index.20160727021730647, index.properties, 
replication.properties] expected:<1> but was:<2>

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

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

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-9269:


[~dsmiley] Thanks for the review! I have removed the unnecessary 
synchronization and pushed the latest changes to github. I also fixed Javadocs 
related error and ensured that unit tests and precommit are passing. Please 
take a look. 

> Ability to create/delete/list snapshots for a solr core
> ---
>
> Key: SOLR-9269
> URL: https://issues.apache.org/jira/browse/SOLR-9269
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Hrishikesh Gadre
>Assignee: David Smiley
> Attachments: SOLR-9269.patch
>
>
> Support snapshot create/delete/list functionality @ the Solr core level. 
> Please refer to parent JIRA for more details.



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

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

[jira] [Commented] (SOLR-9242) Collection level backup/restore should provide a param for specifying the repository implementation it should use

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9242: Disabling TestLocalFSCloudBackupRestore on Windows till we fix it


> Collection level backup/restore should provide a param for specifying the 
> repository implementation it should use
> -
>
> Key: SOLR-9242
> URL: https://issues.apache.org/jira/browse/SOLR-9242
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hrishikesh Gadre
>Assignee: Varun Thacker
> Fix For: 6.2
>
> Attachments: SOLR-9242.patch, SOLR-9242.patch, SOLR-9242.patch, 
> SOLR-9242.patch, SOLR-9242.patch, SOLR-9242_followup.patch
>
>
> SOLR-7374 provides BackupRepository interface to enable storing Solr index 
> data to a configured file-system (e.g. HDFS, local file-system etc.). This 
> JIRA is to track the work required to extend this functionality at the 
> collection level.



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

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

[jira] [Commented] (SOLR-9242) Collection level backup/restore should provide a param for specifying the repository implementation it should use

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9242: Disabling TestLocalFSCloudBackupRestore on Windows till we fix it


> Collection level backup/restore should provide a param for specifying the 
> repository implementation it should use
> -
>
> Key: SOLR-9242
> URL: https://issues.apache.org/jira/browse/SOLR-9242
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hrishikesh Gadre
>Assignee: Varun Thacker
> Fix For: 6.2
>
> Attachments: SOLR-9242.patch, SOLR-9242.patch, SOLR-9242.patch, 
> SOLR-9242.patch, SOLR-9242.patch, SOLR-9242_followup.patch
>
>
> SOLR-7374 provides BackupRepository interface to enable storing Solr index 
> data to a configured file-system (e.g. HDFS, local file-system etc.). This 
> JIRA is to track the work required to extend this functionality at the 
> collection level.



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

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

[jira] [Resolved] (SOLR-9340) ConnectionManager Logging Tweaks

[Varun Thacker (JIRA)]

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

Varun Thacker resolved SOLR-9340.
-
   Resolution: Fixed
Fix Version/s: master (7.0)
   6.2

Thanks Shalin for the review!

> ConnectionManager Logging Tweaks
> 
>
> Key: SOLR-9340
> URL: https://issues.apache.org/jira/browse/SOLR-9340
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9340.patch
>
>
> Here are a few logging statements which deserve to be WARN instead of INFO . 
> {code}
> INFO  - TIME [   ] org.apache.solr.common.cloud.ConnectionManager; Watcher 
> org.apache.solr.common.cloud.ConnectionManager@49a818c3 
> name:ZooKeeperConnection Watcher:zk:2181 got event WatchedEvent 
> state:Disconnected type:None path:null path:null type:None
> INFO  - TIME [   ] org.apache.solr.common.cloud.ConnectionManager; zkClient 
> has disconnected
> INFO  - TIME; [   ] org.apache.solr.common.cloud.DefaultConnectionStrategy; 
> Connection expired - starting a new one...
> INFO  - TIME; [   ] org.apache.solr.common.cloud.ConnectionManager; Waiting 
> for client to connect to ZooKeeper
> INFO  - TIME; [   ] org.apache.solr.common.cloud.ConnectionManager; Our 
> previous ZooKeeper session was expired. Attempting to reconnect to recover 
> relationship with ZooKeeper...
> INFO  - TIME; [   ] org.apache.solr.common.cloud.ConnectionManager; Watcher 
> org.apache.solr.common.cloud.ConnectionManager@6484f62a 
> name:ZooKeeperConnection Watcher:zk:2181 got event WatchedEvent state:Expired 
> type:None path:null path:null type:None
> {code}



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

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

[jira] [Commented] (SOLR-9340) ConnectionManager Logging Tweaks

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9340: Change ZooKeeper disconnect and session expiry related logging from 
INFO to WARN to make debugging easier


> ConnectionManager Logging Tweaks
> 
>
> Key: SOLR-9340
> URL: https://issues.apache.org/jira/browse/SOLR-9340
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Attachments: SOLR-9340.patch
>
>
> Here are a few logging statements which deserve to be WARN instead of INFO . 
> {code}
> INFO  - TIME [   ] org.apache.solr.common.cloud.ConnectionManager; Watcher 
> org.apache.solr.common.cloud.ConnectionManager@49a818c3 
> name:ZooKeeperConnection Watcher:zk:2181 got event WatchedEvent 
> state:Disconnected type:None path:null path:null type:None
> INFO  - TIME [   ] org.apache.solr.common.cloud.ConnectionManager; zkClient 
> has disconnected
> INFO  - TIME; [   ] org.apache.solr.common.cloud.DefaultConnectionStrategy; 
> Connection expired - starting a new one...
> INFO  - TIME; [   ] org.apache.solr.common.cloud.ConnectionManager; Waiting 
> for client to connect to ZooKeeper
> INFO  - TIME; [   ] org.apache.solr.common.cloud.ConnectionManager; Our 
> previous ZooKeeper session was expired. Attempting to reconnect to recover 
> relationship with ZooKeeper...
> INFO  - TIME; [   ] org.apache.solr.common.cloud.ConnectionManager; Watcher 
> org.apache.solr.common.cloud.ConnectionManager@6484f62a 
> name:ZooKeeperConnection Watcher:zk:2181 got event WatchedEvent state:Expired 
> type:None path:null path:null type:None
> {code}



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

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

[jira] [Commented] (SOLR-9340) ConnectionManager Logging Tweaks

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9340: Change ZooKeeper disconnect and session expiry related logging from 
INFO to WARN to make debugging easier


> ConnectionManager Logging Tweaks
> 
>
> Key: SOLR-9340
> URL: https://issues.apache.org/jira/browse/SOLR-9340
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Attachments: SOLR-9340.patch
>
>
> Here are a few logging statements which deserve to be WARN instead of INFO . 
> {code}
> INFO  - TIME [   ] org.apache.solr.common.cloud.ConnectionManager; Watcher 
> org.apache.solr.common.cloud.ConnectionManager@49a818c3 
> name:ZooKeeperConnection Watcher:zk:2181 got event WatchedEvent 
> state:Disconnected type:None path:null path:null type:None
> INFO  - TIME [   ] org.apache.solr.common.cloud.ConnectionManager; zkClient 
> has disconnected
> INFO  - TIME; [   ] org.apache.solr.common.cloud.DefaultConnectionStrategy; 
> Connection expired - starting a new one...
> INFO  - TIME; [   ] org.apache.solr.common.cloud.ConnectionManager; Waiting 
> for client to connect to ZooKeeper
> INFO  - TIME; [   ] org.apache.solr.common.cloud.ConnectionManager; Our 
> previous ZooKeeper session was expired. Attempting to reconnect to recover 
> relationship with ZooKeeper...
> INFO  - TIME; [   ] org.apache.solr.common.cloud.ConnectionManager; Watcher 
> org.apache.solr.common.cloud.ConnectionManager@6484f62a 
> name:ZooKeeperConnection Watcher:zk:2181 got event WatchedEvent state:Expired 
> type:None path:null path:null type:None
> {code}



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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17374/
Java: 32bit/jdk1.8.0_92 -server -XX:+UseConcMarkSweepGC

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

Error Message:
6 threads leaked from SUITE scope at 
org.apache.solr.cloud.SaslZkACLProviderTest: 1) Thread[id=11988, 
name=changePwdReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)2) Thread[id=11989, 
name=groupCache.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest]
 at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)3) Thread[id=11992, 
name=pool-7-thread-1, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest]
 at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)4) Thread[id=11990, 
name=kdcReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)5) Thread[id=11987, 
name=apacheds, state=WAITING, group=TGRP-SaslZkACLProviderTest] at 
java.lang.Object.wait(Native Method) at 
java.lang.Object.wait(Object.java:502) at 
java.util.TimerThread.mainLoop(Timer.java:526) at 
java.util.TimerThread.run(Timer.java:505)6) Thread[id=11991, 
name=ou=system.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  

[jira] [Updated] (LUCENE-7396) Speed up flush of 1-dimension points

[Adrien Grand (JIRA)]

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

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

Here is a patch that uses a different approach. Flush passes a special 
implementation of a PointsReader that allows points to be reordered, so that 
codecs can sort points in the order that they are interested in. The benefit 
compared to the previous patch is that it is not specific to a codec anymore 
and also that it can be used in the multi-dimensional case. I got the following 
flush times (as reported by the IndexWriter log) with a 1GB buffer:

|| Flush time (ms)||master||patch||
|IndexAndSearchOpenStreetMaps1D (1 dim)|31089|18954 
({color:green}-39.0%{color})|
|IndexAndSearchOpenStreetMaps (2 dims)|123461|85235 
({color:green}-30.1%{color})|

This looks encouraging, especially given that it also uses less memory than the 
current approach. However the patch is a bit disappointing in that it has a 
completely different implementation of the writing of the tree depending on 
whether the input can be reordered or not. I'll look into whether I can clean 
this up a bit.

> Speed up flush of 1-dimension points
> 
>
> Key: LUCENE-7396
> URL: https://issues.apache.org/jira/browse/LUCENE-7396
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7396.patch, LUCENE-7396.patch
>
>
> 1D points already have an optimized merge implementation which works when 
> points come in order. So maybe we could make IndexWriter's PointValuesWriter 
> sort before feeding the PointsFormat and somehow propagate the information to 
> the PointsFormat?
> The benefit is that flushing could directly stream points to disk with little 
> memory usage.



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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6007/
Java: 32bit/jdk1.8.0_92 -server -XX:+UseG1GC

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

Error Message:
expected: but was:

Stack Trace:
java.lang.AssertionError: expected: but was:
at 
__randomizedtesting.SeedInfo.seed([7280A8B6CCB15790:FAD4976C624D3A68]: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:147)
at 
org.apache.solr.cloud.AbstractCloudBackupRestoreTestCase.testBackupAndRestore(AbstractCloudBackupRestoreTestCase.java:208)
at 
org.apache.solr.cloud.AbstractCloudBackupRestoreTestCase.test(AbstractCloudBackupRestoreTestCase.java:126)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




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

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

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-6246:
-

Hi Shamik,

I don't think anyone is currently working on it. But patches are always welcome 
:)

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



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

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

[jira] [Commented] (SOLR-9279) Add greater than, less than, etc in Solr function queries

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-9279:
--

Github user dsmiley commented on the issue:

https://github.com/apache/lucene-solr/pull/49
  
Ok; this is fine.  It could be optimized later :-)  Did you see Hoss's 
comments on implementing exists() ?


> Add greater than, less than, etc in Solr function queries
> -
>
> Key: SOLR-9279
> URL: https://issues.apache.org/jira/browse/SOLR-9279
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Doug Turnbull
> Fix For: master (7.0)
>
>
> If you use the "if" function query, you'll often expect to be able to use 
> greater than/less than functions. For example, you might want to boost books 
> written in the past 7 years. Unfortunately, there's no "greater than" 
> function query that will return non-zero when the lhs > rhs. Instead to get 
> this, you need to create really awkward function queries like I do here 
> (http://opensourceconnections.com/blog/2014/11/26/stepwise-date-boosting-in-solr/):
> if(min(0,sub(ms(mydatefield),sub(ms(NOW),315569259747))),0.8,1)
> The pull request attached to this Jira adds the following function queries
> (https://github.com/apache/lucene-solr/pull/49)
> -gt(lhs, rhs) (returns 1 if lhs > rhs, 0 otherwise)
> -lt(lhs, rhs) (returns 1 if lhs < rhs, 0 otherwise)
> -gte
> -lte
> -eq
> So instead of 
> if(min(0,sub(ms(mydatefield),sub(ms(NOW),315569259747))),0.8,1)
> one could now write
> if(lt(ms(mydatefield),315569259747,0.8,1)
> (if mydatefield < 315569259747 then 0.8 else 1)
> A bit more readable and less puzzling



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

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

[GitHub] lucene-solr issue #49: SOLR-9279 Adds comparison function queries

[dsmiley]

Github user dsmiley commented on the issue:

https://github.com/apache/lucene-solr/pull/49
  
Ok; this is fine.  It could be optimized later :-)  Did you see Hoss's 
comments on implementing exists() ?


---
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-9120) Luke NoSuchFileException

[Tomasz Oliwa (JIRA)]

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

Tomasz Oliwa commented on SOLR-9120:


I also see this on Solr 6.1.0

> Luke NoSuchFileException
> 
>
> Key: SOLR-9120
> URL: https://issues.apache.org/jira/browse/SOLR-9120
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Markus Jelsma
> Fix For: 6.2, master (7.0)
>
>
> On Solr 6.0, we frequently see the following errors popping up:
> {code}
> java.nio.file.NoSuchFileException: 
> /var/lib/solr/logs_shard2_replica1/data/index/segments_2c5
>   at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
>   at 
> sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
>   at 
> sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:144)
>   at 
> sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
>   at java.nio.file.Files.readAttributes(Files.java:1737)
>   at java.nio.file.Files.size(Files.java:2332)
>   at org.apache.lucene.store.FSDirectory.fileLength(FSDirectory.java:243)
>   at 
> org.apache.lucene.store.NRTCachingDirectory.fileLength(NRTCachingDirectory.java:131)
>   at 
> org.apache.solr.handler.admin.LukeRequestHandler.getFileLength(LukeRequestHandler.java:597)
>   at 
> org.apache.solr.handler.admin.LukeRequestHandler.getIndexInfo(LukeRequestHandler.java:585)
>   at 
> org.apache.solr.handler.admin.LukeRequestHandler.handleRequestBody(LukeRequestHandler.java:137)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2033)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:652)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
>   at org.eclipse.jetty.server.Server.handle(Server.java:518)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
>   at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
>   at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
>   at 
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
>   at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
>   at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
>   at java.lang.Thread.run(Thread.java:745)
> {code}



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

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

[jira] [Issue Comment Deleted] (SOLR-8793) Fix stale commit files' size computation in LukeRequestHandler

[Tomasz Oliwa (JIRA)]

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

Tomasz Oliwa updated SOLR-8793:
---
Comment: was deleted

(was: This problem is not fixed.

I setup a fresh Solr 6.1.0, created a core with the basic config and used curl 
to push several thousand JSON files to the Solr core. In the Solr Admin UI:

WARN true LukeRequestHandler Error getting file length for [segments_1g]

java.nio.file.NoSuchFileException: 
/home/user1/solr-6.1.0/server/solr/testingcore/data/index/segments_1g
at 
sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
[...])

> Fix stale commit files' size computation in LukeRequestHandler
> --
>
> Key: SOLR-8793
> URL: https://issues.apache.org/jira/browse/SOLR-8793
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.5
>Reporter: Shai Erera
>Assignee: Shai Erera
>Priority: Minor
> Fix For: 5.5.1, 6.0
>
> Attachments: SOLR-8793.patch
>
>
> SOLR-8587 added segments file information and its size to core admin status 
> API. However in case of stale commits, calling that API may result on 
> {{FileNotFoundException}} or {{NoSuchFileException}}, if the segments file no 
> longer exists due to a new commit. We should fix that by returning a proper 
> value for the file's length in this case, maybe -1.



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

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

[jira] [Commented] (SOLR-8793) Fix stale commit files' size computation in LukeRequestHandler

[Tomasz Oliwa (JIRA)]

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

Tomasz Oliwa commented on SOLR-8793:


This problem is not fixed.

I setup a fresh Solr 6.1.0, created a core with the basic config and used curl 
to push several thousand JSON files to the Solr core. In the Solr Admin UI:

WARN true LukeRequestHandler Error getting file length for [segments_1g]

java.nio.file.NoSuchFileException: 
/home/user1/solr-6.1.0/server/solr/testingcore/data/index/segments_1g
at 
sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
[...]

> Fix stale commit files' size computation in LukeRequestHandler
> --
>
> Key: SOLR-8793
> URL: https://issues.apache.org/jira/browse/SOLR-8793
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.5
>Reporter: Shai Erera
>Assignee: Shai Erera
>Priority: Minor
> Fix For: 5.5.1, 6.0
>
> Attachments: SOLR-8793.patch
>
>
> SOLR-8587 added segments file information and its size to core admin status 
> API. However in case of stale commits, calling that API may result on 
> {{FileNotFoundException}} or {{NoSuchFileException}}, if the segments file no 
> longer exists due to a new commit. We should fix that by returning a proper 
> value for the file's length in this case, maybe -1.



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

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

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

[Shamik Bandopadhyay (JIRA)]

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

Shamik Bandopadhyay commented on SOLR-6246:
---

Any update on this ?

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



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

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

[jira] [Updated] (SOLR-8995) Use lambdas to simplify code

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-8995:
-
Summary: Use lambdas to simplify code  (was: Minimize code with Lambdas)

> Use lambdas to simplify code
> 
>
> Key: SOLR-8995
> URL: https://issues.apache.org/jira/browse/SOLR-8995
> Project: Solr
>  Issue Type: Task
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-8995.patch
>
>




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

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

[jira] [Commented] (SOLR-8995) Use lambdas to simplify code

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-8995:
--

Had the same confusion for a bit, even though I knew better. Changed.

> Use lambdas to simplify code
> 
>
> Key: SOLR-8995
> URL: https://issues.apache.org/jira/browse/SOLR-8995
> Project: Solr
>  Issue Type: Task
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-8995.patch
>
>




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

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

[jira] [Comment Edited] (SOLR-6399) Implement unloadCollection in the Collections API

[Yago Riveiro (JIRA)]

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

Yago Riveiro edited comment on SOLR-6399 at 7/26/16 4:24 PM:
-

With a flag in the core.properties saying that the core is not loaded on 
startup, a new state in zookeeper saying that collection is unloaded to not 
route queries and not trigger recoveries or notify that collection is down, and 
a command to load the collection on demand It's enough.

I don't want to do a backup with a restore, I want notify the cluster to not 
load data to memory to save resources, but if necessary loading the collection 
on the fly.

Backup data involve extra space somewhere, with 1T collection you needs 1T in 
other location to backup, to say nothing of transfer data over the network ...

Backup and restore is a nice feature, but in huge clusters with a lot of data 
you not always can do it without huge amount of resources.


was (Author: yriveiro):
With a flag in the core.properties saying that the core is not loaded on 
startup, a new state in zookeeper saying that collection is unloaded to not 
route queries and not trigger recoveries or notify that collection is down, and 
a command to load the collection on demand It's enough.

I don't want to do a backup with a restore, I want notify the cluster to not 
load data to memory to save resources, but if necessary loading the collection 
on the fly.

Backup data involve extra space somewhere, with 1T collection you needs 1T in 
other location to backup, to say nothing of transfer data over the network ...

> Implement unloadCollection in the Collections API
> -
>
> Key: SOLR-6399
> URL: https://issues.apache.org/jira/browse/SOLR-6399
> Project: Solr
>  Issue Type: New Feature
>Reporter: dfdeshom
>Assignee: Shalin Shekhar Mangar
> Fix For: 6.0
>
>
> There is currently no way to unload a collection without deleting its 
> contents. There should be a way in the collections API to unload a collection 
> and reload it later, as needed.
> A use case for this is the following: you store logs by day, with each day 
> having its own collection. You are required to store up to 2 years of data, 
> which adds up to 730 collections.  Most of the time, you'll want to have 3 
> days of data loaded for search. Having just 3 collections loaded into memory, 
> instead of 730 will make managing Solr easier.



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

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

[jira] [Commented] (SOLR-6399) Implement unloadCollection in the Collections API

[Yago Riveiro (JIRA)]

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

Yago Riveiro commented on SOLR-6399:


With a flag in the core.properties saying that the core is not loaded on 
startup, a new state in zookeeper saying that collection is unloaded to not 
route queries and not trigger recoveries or notify that collection is down, and 
a command to load the collection on demand It's enough.

I don't want to do a backup with a restore, I want notify the cluster to not 
load data to memory to save resources, but if necessary loading the collection 
on the fly.

Backup data involve extra space somewhere, with 1T collection you needs 1T in 
other location to backup, to say nothing of transfer data over the network ...

> Implement unloadCollection in the Collections API
> -
>
> Key: SOLR-6399
> URL: https://issues.apache.org/jira/browse/SOLR-6399
> Project: Solr
>  Issue Type: New Feature
>Reporter: dfdeshom
>Assignee: Shalin Shekhar Mangar
> Fix For: 6.0
>
>
> There is currently no way to unload a collection without deleting its 
> contents. There should be a way in the collections API to unload a collection 
> and reload it later, as needed.
> A use case for this is the following: you store logs by day, with each day 
> having its own collection. You are required to store up to 2 years of data, 
> which adds up to 730 collections.  Most of the time, you'll want to have 3 
> days of data loaded for search. Having just 3 collections loaded into memory, 
> instead of 730 will make managing Solr easier.



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

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

[jira] [Created] (SOLR-9344) BasicAuthIntegrationTest test failures on update

[Gregory Chanan (JIRA)]

Gregory Chanan created SOLR-9344:


 Summary: BasicAuthIntegrationTest test failures on update
 Key: SOLR-9344
 URL: https://issues.apache.org/jira/browse/SOLR-9344
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: security, Tests
Affects Versions: trunk
Reporter: Gregory Chanan


I've seen this a number of times while developing SOLR-9200 and SOLR-9324; 
there's also a public failure here: 
http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17372/

{code}
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: IOException 
occured when talking to server at: 
http://127.0.0.1:45882/solr/testSolrCloudCollection_shard1_replica2
at 
__randomizedtesting.SeedInfo.seed([99BB0D0378978FA8:A463A32F4079D1D8]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:760)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1172)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1061)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:997)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.security.BasicAuthIntegrationTest.doExtraTests(BasicAuthIntegrationTest.java:193)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testCollectionCreateSearchDelete(TestMiniSolrCloudClusterBase.java:196)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testBasics(TestMiniSolrCloudClusterBase.java:79)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

[jira] [Commented] (SOLR-9279) Add greater than, less than, etc in Solr function queries

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-9279:
--

Github user softwaredoug commented on the issue:

https://github.com/apache/lucene-solr/pull/49
  
I believe I've done what you requested. There's a lot of value sources that 
inherit directly from FunctionValues, so without cataloging which ones are best 
treated as longs and which are best treated as floats, its going to be 
impossible to always do the safest comparison. The best we can do is test for 
Long or Int values


> Add greater than, less than, etc in Solr function queries
> -
>
> Key: SOLR-9279
> URL: https://issues.apache.org/jira/browse/SOLR-9279
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Doug Turnbull
> Fix For: master (7.0)
>
>
> If you use the "if" function query, you'll often expect to be able to use 
> greater than/less than functions. For example, you might want to boost books 
> written in the past 7 years. Unfortunately, there's no "greater than" 
> function query that will return non-zero when the lhs > rhs. Instead to get 
> this, you need to create really awkward function queries like I do here 
> (http://opensourceconnections.com/blog/2014/11/26/stepwise-date-boosting-in-solr/):
> if(min(0,sub(ms(mydatefield),sub(ms(NOW),315569259747))),0.8,1)
> The pull request attached to this Jira adds the following function queries
> (https://github.com/apache/lucene-solr/pull/49)
> -gt(lhs, rhs) (returns 1 if lhs > rhs, 0 otherwise)
> -lt(lhs, rhs) (returns 1 if lhs < rhs, 0 otherwise)
> -gte
> -lte
> -eq
> So instead of 
> if(min(0,sub(ms(mydatefield),sub(ms(NOW),315569259747))),0.8,1)
> one could now write
> if(lt(ms(mydatefield),315569259747,0.8,1)
> (if mydatefield < 315569259747 then 0.8 else 1)
> A bit more readable and less puzzling



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

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

[GitHub] lucene-solr issue #49: SOLR-9279 Adds comparison function queries

[softwaredoug]

Github user softwaredoug commented on the issue:

https://github.com/apache/lucene-solr/pull/49
  
I believe I've done what you requested. There's a lot of value sources that 
inherit directly from FunctionValues, so without cataloging which ones are best 
treated as longs and which are best treated as floats, its going to be 
impossible to always do the safest comparison. The best we can do is test for 
Long or Int values


---
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-9340) ConnectionManager Logging Tweaks

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-9340:
-

+1. Knowing about ZK disconnection or session expiration helps a lot during 
debugging.

> ConnectionManager Logging Tweaks
> 
>
> Key: SOLR-9340
> URL: https://issues.apache.org/jira/browse/SOLR-9340
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Attachments: SOLR-9340.patch
>
>
> Here are a few logging statements which deserve to be WARN instead of INFO . 
> {code}
> INFO  - TIME [   ] org.apache.solr.common.cloud.ConnectionManager; Watcher 
> org.apache.solr.common.cloud.ConnectionManager@49a818c3 
> name:ZooKeeperConnection Watcher:zk:2181 got event WatchedEvent 
> state:Disconnected type:None path:null path:null type:None
> INFO  - TIME [   ] org.apache.solr.common.cloud.ConnectionManager; zkClient 
> has disconnected
> INFO  - TIME; [   ] org.apache.solr.common.cloud.DefaultConnectionStrategy; 
> Connection expired - starting a new one...
> INFO  - TIME; [   ] org.apache.solr.common.cloud.ConnectionManager; Waiting 
> for client to connect to ZooKeeper
> INFO  - TIME; [   ] org.apache.solr.common.cloud.ConnectionManager; Our 
> previous ZooKeeper session was expired. Attempting to reconnect to recover 
> relationship with ZooKeeper...
> INFO  - TIME; [   ] org.apache.solr.common.cloud.ConnectionManager; Watcher 
> org.apache.solr.common.cloud.ConnectionManager@6484f62a 
> name:ZooKeeperConnection Watcher:zk:2181 got event WatchedEvent state:Expired 
> type:None path:null path:null type:None
> {code}



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

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

[jira] [Commented] (SOLR-8995) Minimize code with Lambdas

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-8995:


I think the issue title is a bit confusing.  When I read "Minimize code with 
Lambdas" in the subject of several emails from Jira, I pretty much assumed its 
meaning was "minimize the use of code containing lambdas" ... but that doesn't 
really make sense given that we now require Java 8, and it's the *opposite* of 
what's actually happening.  A more meaningful title might be "Use lambdas to 
simplify code".  Is the "anonymous" part of the original issue title important 
in any way?

> Minimize code with Lambdas
> --
>
> Key: SOLR-8995
> URL: https://issues.apache.org/jira/browse/SOLR-8995
> Project: Solr
>  Issue Type: Task
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-8995.patch
>
>




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

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

[jira] [Resolved] (SOLR-9343) facet not working after implementing filters and stopwords

[Erik Hatcher (JIRA)]

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

Erik Hatcher resolved SOLR-9343.

Resolution: Not A Problem

Please use the Solr the solr-user mailing list for questions.  JIRA is for bug 
reports or enhancement requests.  See 
http://lucene.apache.org/solr/resources.html#community

> facet not working after implementing filters and stopwords
> --
>
> Key: SOLR-9343
> URL: https://issues.apache.org/jira/browse/SOLR-9343
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module, faceting
>Affects Versions: 5.4
>Reporter: kranthi
>Priority: Blocker
>
> i m very new to solr search engine.I m working on solr 5.4 version.
> when i m working on faceting its seems everything cool.
> after i moved to complex level of searching, i implemented filters and 
> stopwords facet not working.
> can any one suggest is there any relation between filters and faceting.
> or any limitations are there for faceting.



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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17373/
Java: 32bit/jdk1.8.0_92 -server -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.security.BasicAuthIntegrationTest.testBasics

Error Message:
IOException occured when talking to server at: 
http://127.0.0.1:42093/solr/testSolrCloudCollection_shard1_replica2

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: IOException 
occured when talking to server at: 
http://127.0.0.1:42093/solr/testSolrCloudCollection_shard1_replica2
at 
__randomizedtesting.SeedInfo.seed([C85EFB6ABC86BC09:F58655468468E279]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:760)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1172)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1061)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:997)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.security.BasicAuthIntegrationTest.doExtraTests(BasicAuthIntegrationTest.java:193)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testCollectionCreateSearchDelete(TestMiniSolrCloudClusterBase.java:196)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testBasics(TestMiniSolrCloudClusterBase.java:79)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 

[jira] [Commented] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[Pushkar Raste (JIRA)]

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

Pushkar Raste commented on SOLR-9310:
-

Parallel indexing unfortunately does not work, it is a race condition where 
things could diverge on the leader during call to get index fingerprint and get 
versions. I think fingerprint check is mostly likely to fail if documents are 
being indexed while node is recovering and if a commits (or softCommits) get 
issued/triggered.

> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Attachments: SOLR-9310.patch, SOLR-9310.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



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

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

[jira] [Updated] (SOLR-9343) facet not working after implementing filters and stopwords

[kranthi (JIRA)]

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

kranthi updated SOLR-9343:
--
Priority: Blocker  (was: Major)

> facet not working after implementing filters and stopwords
> --
>
> Key: SOLR-9343
> URL: https://issues.apache.org/jira/browse/SOLR-9343
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module, faceting
>Affects Versions: 5.4
>Reporter: kranthi
>Priority: Blocker
>
> i m very new to solr search engine.I m working on solr 5.4 version.
> when i m working on faceting its seems everything cool.
> after i moved to complex level of searching, i implemented filters and 
> stopwords facet not working.
> can any one suggest is there any relation between filters and faceting.
> or any limitations are there for faceting.



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

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

[jira] [Created] (SOLR-9343) facet not working after implementing filters and stopwords

[kranthi (JIRA)]

kranthi created SOLR-9343:
-

 Summary: facet not working after implementing filters and stopwords
 Key: SOLR-9343
 URL: https://issues.apache.org/jira/browse/SOLR-9343
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Facet Module, faceting
Affects Versions: 5.4
Reporter: kranthi


i m very new to solr search engine.I m working on solr 5.4 version.
when i m working on faceting its seems everything cool.
after i moved to complex level of searching, i implemented filters and 
stopwords facet not working.
can any one suggest is there any relation between filters and faceting.
or any limitations are there for faceting.



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

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

[jira] [Commented] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-9310:
--

[~praste] I have tried a few approaches and only your approach (as given in the 
patch) seems to yield results. I'll do some more testing anyway. Your test has 
some commented out stuff, parallel indexing. Does it work too?

> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Attachments: SOLR-9310.patch, SOLR-9310.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



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

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

[jira] [Commented] (SOLR-9279) Add greater than, less than, etc in Solr function queries

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-9279:
--

Github user softwaredoug commented on the issue:

https://github.com/apache/lucene-solr/pull/49
  
I can do that, but in the Solr version I will end up overriding compare, 
then providing further abstract methods to do numerical comparisons. Otherwise 
I'm going to just end up with lots of boiler plate repeated in the 
ValueSourceParser


> Add greater than, less than, etc in Solr function queries
> -
>
> Key: SOLR-9279
> URL: https://issues.apache.org/jira/browse/SOLR-9279
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Doug Turnbull
> Fix For: master (7.0)
>
>
> If you use the "if" function query, you'll often expect to be able to use 
> greater than/less than functions. For example, you might want to boost books 
> written in the past 7 years. Unfortunately, there's no "greater than" 
> function query that will return non-zero when the lhs > rhs. Instead to get 
> this, you need to create really awkward function queries like I do here 
> (http://opensourceconnections.com/blog/2014/11/26/stepwise-date-boosting-in-solr/):
> if(min(0,sub(ms(mydatefield),sub(ms(NOW),315569259747))),0.8,1)
> The pull request attached to this Jira adds the following function queries
> (https://github.com/apache/lucene-solr/pull/49)
> -gt(lhs, rhs) (returns 1 if lhs > rhs, 0 otherwise)
> -lt(lhs, rhs) (returns 1 if lhs < rhs, 0 otherwise)
> -gte
> -lte
> -eq
> So instead of 
> if(min(0,sub(ms(mydatefield),sub(ms(NOW),315569259747))),0.8,1)
> one could now write
> if(lt(ms(mydatefield),315569259747,0.8,1)
> (if mydatefield < 315569259747 then 0.8 else 1)
> A bit more readable and less puzzling



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

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

[GitHub] lucene-solr issue #49: SOLR-9279 Adds comparison function queries

[softwaredoug]

Github user softwaredoug commented on the issue:

https://github.com/apache/lucene-solr/pull/49
  
I can do that, but in the Solr version I will end up overriding compare, 
then providing further abstract methods to do numerical comparisons. Otherwise 
I'm going to just end up with lots of boiler plate repeated in the 
ValueSourceParser


---
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-9341) GC Logs on windows should go to Solr_Logs_Dir, rather than hardcoded to /server/logs/

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-9341:
--

bq: Sorry, I didn't realise a jira issue was required - it's not completely 
clear from

NP, I just added some clarification to that page so it should be clearer for 
the next person.

> GC Logs on windows should go to Solr_Logs_Dir, rather than hardcoded to 
> /server/logs/
> -
>
> Key: SOLR-9341
> URL: https://issues.apache.org/jira/browse/SOLR-9341
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.1
> Environment: Windows
>Reporter: Alex Crome
>
> The windows batch script is hard coded to store the gc logs in server/logs, 
> whereas the batch start script stores them in $SOLR_LOGS_DIR



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

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

[jira] [Created] (SOLR-9342) Solr GC logging not respecting user timezone

[Varun Thacker (JIRA)]

Varun Thacker created SOLR-9342:
---

 Summary: Solr GC logging not respecting user timezone 
 Key: SOLR-9342
 URL: https://issues.apache.org/jira/browse/SOLR-9342
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Varun Thacker


When I start Solr with say {{-Duser.timezone=PST}} the solr logging correctly 
logs in the specified timezone.
However the solr gc logging is still using my machines default timezone. This 
can be very confusing and make debugging very tough.




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

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

[GitHub] lucene-solr pull request #54: SOLR-8911: Angular Admin UI: Fix cut-off overf...

[arafalov]

GitHub user arafalov opened a pull request:

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

SOLR-8911: Angular Admin UI: Fix cut-off overflow strings on dashboard page

Fix too long value strings in the dashboard page (primarily versions and 
args sections) by adding overflow scrolling. The scrollbar appears when hovered 
or touched on the individual value area.

Tested on several browsers on Mac, Windows and Android. On Windows, the 
scrollbar makes the page jump a little bit for the args section, but is quite 
usable. On Mac and Android, the scrollbar is inside the area and does not cause 
a jump.

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

$ git pull https://github.com/arafalov/lucene-solr-contributions master

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

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


commit 3c4b5db04935499972c281cc28cce8fb3e529a4a
Author: Alexandre Rafalovitch 
Date:   2016-07-26T14:33:09Z

Angular Admin UI: Fix cut-off overflow strings on dashboard page (FIX
SOLR-8911)




---
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-8911) Admin UI: solr-impl and lucene-impl versions are cut off in SNAPSHOT versions

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-8911:
--

GitHub user arafalov opened a pull request:

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

SOLR-8911: Angular Admin UI: Fix cut-off overflow strings on dashboard page

Fix too long value strings in the dashboard page (primarily versions and 
args sections) by adding overflow scrolling. The scrollbar appears when hovered 
or touched on the individual value area.

Tested on several browsers on Mac, Windows and Android. On Windows, the 
scrollbar makes the page jump a little bit for the args section, but is quite 
usable. On Mac and Android, the scrollbar is inside the area and does not cause 
a jump.

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

$ git pull https://github.com/arafalov/lucene-solr-contributions master

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

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


commit 3c4b5db04935499972c281cc28cce8fb3e529a4a
Author: Alexandre Rafalovitch 
Date:   2016-07-26T14:33:09Z

Angular Admin UI: Fix cut-off overflow strings on dashboard page (FIX
SOLR-8911)




> Admin UI: solr-impl and lucene-impl versions are cut off in SNAPSHOT versions
> -
>
> Key: SOLR-8911
> URL: https://issues.apache.org/jira/browse/SOLR-8911
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: 5.5
>Reporter: Shawn Heisey
>Priority: Minor
> Attachments: solr-version-cutoff.png
>
>
> I just tried to see Solr's "compiled on" date on my dev Solr server, which is 
> running a 5.5.1-SNAPSHOT version, compiled from the branch_5_5 source.
> The "impl" strings are so long that the only thing I could tell is that it 
> was compiled this year.  I will attach a screenshot.
> It wasn't possible to see or highlight the full string.  I did manage to see 
> it all when I maximized my browser window (on a 1680x1050 screen), but I 
> really dislike running with windows maximized.  It's not like I keep the 
> windows *small* either -- the screenshot will reflect this.



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

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

[jira] [Commented] (SOLR-9336) ReRankQuery.(hashCode|equalsTo) to consider length

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-9336:
---

Added notes to SOLR-9331 and based on them considering {{length}} as part of 
{{hashCode}} and {{equalsTo}} would reduce the number of (perfectly useable) 
cache hits, and so length should not be added but SOLR-9331 itself seems 
supported.

> ReRankQuery.(hashCode|equalsTo) to consider length
> --
>
> Key: SOLR-9336
> URL: https://issues.apache.org/jira/browse/SOLR-9336
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9336.patch
>
>




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

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

[jira] [Commented] (SOLR-9331) Can we remove ReRankQuery's length constructor argument?

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-9331:
---


Been reading and investigating some more w.r.t. SOLR-9331 here and SOLR-9336 
also - here's my now improved understanding of how the request parameters 
{{rows}}, {{start}} and {{reRankDocs}} and the solrconfig.xml element 
{{queryResultWindowSize}} combine as far as the {{ReRank(Query|Collector)}} and 
the {{QueryResultCache}} are concerned.

The {{start}} parameter defaults to 0 if not supplied and combined with the 
{{rows}} parameter it is used for paging, for example if each page is to 
contain five documents then the requests would be:
{code}
# page 1
...=5
# page 2
...=5=5
# page 3
...=5=10
{code}

Next, let's say we wish to apply some sort of reranking to improve search 
relevance.
* Here's what the requests would look like if we were to rerank/reorder just 
the first page of documents:
{code}
# page 1
...={!rerank+reRankDocs=5+reRankQuery=$rrq+...}=...=5
# cost: 5 docs retrieved, 5 docs reordered, 5 docs returned
#
# page 2
...={!rerank+reRankDocs=5+reRankQuery=$rrq+...}=...=5=5
# cost: 10 docs retrieved, 5 docs reordered, 5 docs skipped and then 5 docs 
returned
#
# page 3
...={!rerank+reRankDocs=5+reRankQuery=$rrq+...}=...=5=10
# cost: 15 docs retrieved, 5 docs reordered, 10 docs skipped and then 5 docs 
returned
{code}
* Here's what the requests would look like if we were to rerank/reorder the 
first five pages of documents:
{code}
# page 1
...={!rerank+reRankDocs=25+reRankQuery=$rrq+...}=...=5
# cost: 25 docs retrieved, 25 docs reordered, 5 docs returned
#
# page 2
...={!rerank+reRankDocs=25+reRankQuery=$rrq+...}=...=5=5
# cost: 25 docs retrieved, 25 docs reordered, 5 docs skipped and then 5 docs 
returned
#
# page 3
...={!rerank+reRankDocs=25+reRankQuery=$rrq+...}=...=5=10
# cost: 25 docs retrieved, 25 docs reordered, 10 docs skipped and then 5 docs 
returned
{code}

Next, let's think about query result caching and demonstrate why {{reRankDocs}} 
needs to be part of the 
[ReRankQuery.equalTo|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/search/ReRankQParserPlugin.java#L117]
 formula:
{code}
# reranking logic: 'odd ahead of even'
# results withoutreranking: 1 2 3 4 5 6 7 8 9 10
# results with reRankDocs=7  reranking: 1 3 5 7 2 4 6 8 9 10
# results with reRankDocs=10 reranking: 1 3 5 7 9 2 4 6 8 10
{code}
* conclusion: reRankDocs influences the end result and thus it must form part 
of the query result caching logic.

Next, let's consider query result caching, with {{rows}}+{{start}} combined 
into a {{length}} variable:
{code}
# reranking logic: 'odd ahead of even'
#
#  input: reRankDocs=3=0=6=...
# output: [ 1 3 2 4 5 6 ] // populate cache (length=6)
#
#  input: reRankDocs=3=0=3=...
# output: [ 1 3 2 ] // use (length=6) cache (we need only first half subset of 
what is cached)
#
#  input: reRankDocs=3=3=3=...
# output: [ 4 5 6 ] // use (length=6) cache (we need only second half subset of 
what is cached)
#
#  input: reRankDocs=3=0=4=...
# output: [ 1 3 2 4 ] // use (length=6) cache (we need only first two thirds 
subset of what is cached)
#
#  input: reRankDocs=3=3=4=...
# output: cache lookup returns (length=6) cache entry with too few elements and 
so no cache use here
#  cache: [ 1 3 2 4 5 6 7 ] // populate cache (length=7)
# output: [ 4 5 6 7 ]
{code}
* conclusions: {{length}} not being part of the query result caching logic 
means that
** a length=6 cache entry can be used by some (but not all) subsequent 
length!=6 requests  
** the cache entry's length must be considered relative to the request's length 
and a cache hit is not always a _useable_ cache hit

Following on from this, we can think of the {{queryResultWindowSize}} config 
element as a 'rounded up' version of the {{length}} variable:
{code}
# reranking logic: 'odd ahead of even'
#
#  input: reRankDocs=3=0=6=...
# config: queryResultWindowSize=8
#  cache: [ 1 3 2 4 5 6 7 8 ] // populate cache (length=8)
# output: [ 1 3 2 4 5 6 ]
#
#  input: reRankDocs=3=3=4=...
# output: [ 4 5 6 7 ] // use (length=8) cache (we need only a middle subset of 
what is cached)
{code}
* notes:
** the first query slightly overpopulated the cache and thus the second query 
could use the cache
** the first query became slightly more expensive (8 vs. 6 docs retrieved)
** the second query became cheaper since the query result cache could be used

Finally, let's reassure ourselves that the {{queryResultWindowSize}} 'rounding 
up' does not alter query results themselves:
* The 
[mainCollector|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/search/ReRankQParserPlugin.java#L209]
 is used to retrieve documents. The ReRankCollector 

[jira] [Commented] (SOLR-9279) Add greater than, less than, etc in Solr function queries

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-9279:
--

Github user dsmiley commented on the issue:

https://github.com/apache/lucene-solr/pull/49
  
I think at the Lucene level we should make this widely useful by simply 
exposing a boolean compare(FunctionValues lhs, FunctionValues rhs).  If we go 
the way of your latest commit, it would be less useful as some potential users 
would skip over it to avoid the performance overhead of calling double & 
longVal, or because they have more interesting requirements and want to call 
some other method on functionValues.  So lets not tie their hands.

Yes my concern is definitely performance based.  These things are 
super-sensitive to it as it operates once per matching document, which could be 
a ton.

What you could perhaps do at the Solr layer is check if both the lhs & rhs 
extend from LongDocValues and if so then use the Long version... otherwise use 
the Double version which I think can represent Integer completely.  But it'd be 
very nice not to do that double instanceof check at every comparison... so 
perhaps that would lead to actually implementing getValues().


> Add greater than, less than, etc in Solr function queries
> -
>
> Key: SOLR-9279
> URL: https://issues.apache.org/jira/browse/SOLR-9279
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Doug Turnbull
> Fix For: master (7.0)
>
>
> If you use the "if" function query, you'll often expect to be able to use 
> greater than/less than functions. For example, you might want to boost books 
> written in the past 7 years. Unfortunately, there's no "greater than" 
> function query that will return non-zero when the lhs > rhs. Instead to get 
> this, you need to create really awkward function queries like I do here 
> (http://opensourceconnections.com/blog/2014/11/26/stepwise-date-boosting-in-solr/):
> if(min(0,sub(ms(mydatefield),sub(ms(NOW),315569259747))),0.8,1)
> The pull request attached to this Jira adds the following function queries
> (https://github.com/apache/lucene-solr/pull/49)
> -gt(lhs, rhs) (returns 1 if lhs > rhs, 0 otherwise)
> -lt(lhs, rhs) (returns 1 if lhs < rhs, 0 otherwise)
> -gte
> -lte
> -eq
> So instead of 
> if(min(0,sub(ms(mydatefield),sub(ms(NOW),315569259747))),0.8,1)
> one could now write
> if(lt(ms(mydatefield),315569259747,0.8,1)
> (if mydatefield < 315569259747 then 0.8 else 1)
> A bit more readable and less puzzling



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

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

[GitHub] lucene-solr issue #49: SOLR-9279 Adds comparison function queries

[dsmiley]

Github user dsmiley commented on the issue:

https://github.com/apache/lucene-solr/pull/49
  
I think at the Lucene level we should make this widely useful by simply 
exposing a boolean compare(FunctionValues lhs, FunctionValues rhs).  If we go 
the way of your latest commit, it would be less useful as some potential users 
would skip over it to avoid the performance overhead of calling double & 
longVal, or because they have more interesting requirements and want to call 
some other method on functionValues.  So lets not tie their hands.

Yes my concern is definitely performance based.  These things are 
super-sensitive to it as it operates once per matching document, which could be 
a ton.

What you could perhaps do at the Solr layer is check if both the lhs & rhs 
extend from LongDocValues and if so then use the Long version... otherwise use 
the Double version which I think can represent Integer completely.  But it'd be 
very nice not to do that double instanceof check at every comparison... so 
perhaps that would lead to actually implementing getValues().


---
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-9279) Add greater than, less than, etc in Solr function queries

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-9279:
--

Github user softwaredoug commented on the issue:

https://github.com/apache/lucene-solr/pull/49
  
I just think we have to tread carefully. Comparing two 64 bit timestamps 
could result in surprising bugs where an event seconds after another isn't 
greater than the earlier event due to a loss of precision casting to double. So 
I'd rather enforce the safest possible and most correct comparison and make the 
interface not that general.

Is your concern performance based? Can we reduce the number of times we 
call doubleVal/longVal. Sorry I was not aware of the performance implications.

We could also make the values themselves implement Comparable and let them 
be compared to other function values. But this seems complex and we'd still 
need to enforce the correct comparison. 


> Add greater than, less than, etc in Solr function queries
> -
>
> Key: SOLR-9279
> URL: https://issues.apache.org/jira/browse/SOLR-9279
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Doug Turnbull
> Fix For: master (7.0)
>
>
> If you use the "if" function query, you'll often expect to be able to use 
> greater than/less than functions. For example, you might want to boost books 
> written in the past 7 years. Unfortunately, there's no "greater than" 
> function query that will return non-zero when the lhs > rhs. Instead to get 
> this, you need to create really awkward function queries like I do here 
> (http://opensourceconnections.com/blog/2014/11/26/stepwise-date-boosting-in-solr/):
> if(min(0,sub(ms(mydatefield),sub(ms(NOW),315569259747))),0.8,1)
> The pull request attached to this Jira adds the following function queries
> (https://github.com/apache/lucene-solr/pull/49)
> -gt(lhs, rhs) (returns 1 if lhs > rhs, 0 otherwise)
> -lt(lhs, rhs) (returns 1 if lhs < rhs, 0 otherwise)
> -gte
> -lte
> -eq
> So instead of 
> if(min(0,sub(ms(mydatefield),sub(ms(NOW),315569259747))),0.8,1)
> one could now write
> if(lt(ms(mydatefield),315569259747,0.8,1)
> (if mydatefield < 315569259747 then 0.8 else 1)
> A bit more readable and less puzzling



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

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

[GitHub] lucene-solr issue #49: SOLR-9279 Adds comparison function queries

[softwaredoug]

Github user softwaredoug commented on the issue:

https://github.com/apache/lucene-solr/pull/49
  
I just think we have to tread carefully. Comparing two 64 bit timestamps 
could result in surprising bugs where an event seconds after another isn't 
greater than the earlier event due to a loss of precision casting to double. So 
I'd rather enforce the safest possible and most correct comparison and make the 
interface not that general.

Is your concern performance based? Can we reduce the number of times we 
call doubleVal/longVal. Sorry I was not aware of the performance implications.

We could also make the values themselves implement Comparable and let them 
be compared to other function values. But this seems complex and we'd still 
need to enforce the correct comparison. 


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

[JENKINS] Lucene-Solr-Tests-master - Build # 1284 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1284/

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

Error Message:
Could not get expected value  'CY val' for path 'response/params/y/c' full 
output: {   "responseHeader":{ "status":0, "QTime":0},   "response":{   
  "znodeVersion":0, "params":{"x":{ "a":"A val", "b":"B 
val", "":{"v":0},  from server:  https://127.0.0.1:49228/collection1

Stack Trace:
java.lang.AssertionError: Could not get expected value  'CY val' for path 
'response/params/y/c' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "response":{
"znodeVersion":0,
"params":{"x":{
"a":"A val",
"b":"B val",
"":{"v":0},  from server:  https://127.0.0.1:49228/collection1
at 
__randomizedtesting.SeedInfo.seed([32827005C5F61ABC:BAD64FDF6B0A7744]: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:481)
at 
org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:159)
at 
org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:61)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-9341) GC Logs on windows should go to Solr_Logs_Dir, rather than hardcoded to /server/logs/

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-9341:
--

Github user afscrome commented on the issue:

https://github.com/apache/lucene-solr/pull/53
  
Sorry, I didn't realise a jira issue was required - it's not completely 
clear from https://wiki.apache.org/solr/HowToContribute#Working_with_GitHub .

I've created a new issue and linked it in the PR title.


> GC Logs on windows should go to Solr_Logs_Dir, rather than hardcoded to 
> /server/logs/
> -
>
> Key: SOLR-9341
> URL: https://issues.apache.org/jira/browse/SOLR-9341
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.1
> Environment: Windows
>Reporter: Alex Crome
>
> The windows batch script is hard coded to store the gc logs in server/logs, 
> whereas the batch start script stores them in $SOLR_LOGS_DIR



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

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

[GitHub] lucene-solr issue #53: [SOLR-9341] GC logs go to SOLR_LOGS_DIR on Windows

[afscrome]

Github user afscrome commented on the issue:

https://github.com/apache/lucene-solr/pull/53
  
Sorry, I didn't realise a jira issue was required - it's not completely 
clear from https://wiki.apache.org/solr/HowToContribute#Working_with_GitHub .

I've created a new issue and linked it in the PR title.


---
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] [Updated] (SOLR-9341) GC Logs on windows should go to Solr_Logs_Dir, rather than hardcoded to /server/logs/

[Alex Crome (JIRA)]

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

Alex Crome updated SOLR-9341:
-
Description: The windows batch script is hard coded to store the gc logs in 
server/logs, whereas the batch start script stores them in $SOLR_LOGS_DIR  
(was: The windows batch script is hard coded to store the gc logs in )

> GC Logs on windows should go to Solr_Logs_Dir, rather than hardcoded to 
> /server/logs/
> -
>
> Key: SOLR-9341
> URL: https://issues.apache.org/jira/browse/SOLR-9341
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.1
> Environment: Windows
>Reporter: Alex Crome
>
> The windows batch script is hard coded to store the gc logs in server/logs, 
> whereas the batch start script stores them in $SOLR_LOGS_DIR



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

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

[jira] [Updated] (SOLR-9341) GC Logs on windows should go to Solr_Logs_Dir, rather than hardcoded to /server/logs/

[Alex Crome (JIRA)]

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

Alex Crome updated SOLR-9341:
-
Description: The windows batch script is hard coded to store the gc logs in 

> GC Logs on windows should go to Solr_Logs_Dir, rather than hardcoded to 
> /server/logs/
> -
>
> Key: SOLR-9341
> URL: https://issues.apache.org/jira/browse/SOLR-9341
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.1
> Environment: Windows
>Reporter: Alex Crome
>
> The windows batch script is hard coded to store the gc logs in 



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

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

[jira] [Created] (SOLR-9341) GC Logs on windows should go to Solr_Logs_Dir, rather than hardcoded to /server/logs/

[Alex Crome (JIRA)]

Alex Crome created SOLR-9341:


 Summary: GC Logs on windows should go to Solr_Logs_Dir, rather 
than hardcoded to /server/logs/
 Key: SOLR-9341
 URL: https://issues.apache.org/jira/browse/SOLR-9341
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.1
 Environment: Windows
Reporter: Alex Crome






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

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

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.solr.core.TestArbitraryIndexDir.testLoadNewIndexDir

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([CA256DAED01806DF:237FD6964E819677]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:782)
at 
org.apache.solr.core.TestArbitraryIndexDir.testLoadNewIndexDir(TestArbitraryIndexDir.java:107)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=*[count(//doc)=1]
xml response was: 

032


request was:q=id:2=standard=0=20=2.2
at 

[jira] [Commented] (SOLR-9279) Add greater than, less than, etc in Solr function queries

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-9279:
--

Github user dsmiley commented on the issue:

https://github.com/apache/lucene-solr/pull/49
  
Sorry but I think it's terrible to invoke both doubleVal & longVal 
potentially twice per doc on the same FunctionValues.  I think what I suggested 
in earlier feedback is much closer -- let the subclass choose which 
longVal/doubleVal/whatever to call and to make whatever comparison needed.  On 
the Solr end... we could always work with the doubles, even though some 'long' 
values are out of range.  I believe some other FunctionValue impls are 
implemented similarly as well (?), despite not representing say Long.MAX_VALUE.


> Add greater than, less than, etc in Solr function queries
> -
>
> Key: SOLR-9279
> URL: https://issues.apache.org/jira/browse/SOLR-9279
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Doug Turnbull
> Fix For: master (7.0)
>
>
> If you use the "if" function query, you'll often expect to be able to use 
> greater than/less than functions. For example, you might want to boost books 
> written in the past 7 years. Unfortunately, there's no "greater than" 
> function query that will return non-zero when the lhs > rhs. Instead to get 
> this, you need to create really awkward function queries like I do here 
> (http://opensourceconnections.com/blog/2014/11/26/stepwise-date-boosting-in-solr/):
> if(min(0,sub(ms(mydatefield),sub(ms(NOW),315569259747))),0.8,1)
> The pull request attached to this Jira adds the following function queries
> (https://github.com/apache/lucene-solr/pull/49)
> -gt(lhs, rhs) (returns 1 if lhs > rhs, 0 otherwise)
> -lt(lhs, rhs) (returns 1 if lhs < rhs, 0 otherwise)
> -gte
> -lte
> -eq
> So instead of 
> if(min(0,sub(ms(mydatefield),sub(ms(NOW),315569259747))),0.8,1)
> one could now write
> if(lt(ms(mydatefield),315569259747,0.8,1)
> (if mydatefield < 315569259747 then 0.8 else 1)
> A bit more readable and less puzzling



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

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

[GitHub] lucene-solr issue #49: SOLR-9279 Adds comparison function queries

[dsmiley]

Github user dsmiley commented on the issue:

https://github.com/apache/lucene-solr/pull/49
  
Sorry but I think it's terrible to invoke both doubleVal & longVal 
potentially twice per doc on the same FunctionValues.  I think what I suggested 
in earlier feedback is much closer -- let the subclass choose which 
longVal/doubleVal/whatever to call and to make whatever comparison needed.  On 
the Solr end... we could always work with the doubles, even though some 'long' 
values are out of range.  I believe some other FunctionValue impls are 
implemented similarly as well (?), despite not representing say Long.MAX_VALUE.


---
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-9279) Add greater than, less than, etc in Solr function queries

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-9279:
--

Github user tflobbe commented on the issue:

https://github.com/apache/lucene-solr/pull/53
  
This PR doesn't seem to be linked to any Jira. Is there one? If you include 
the Jira issue id in the title of the PR it will automatically show in Jira 
(e.g. https://issues.apache.org/jira/browse/SOLR-9279 ). You can create a new 
Jira issue if there isn't one for this fix


> Add greater than, less than, etc in Solr function queries
> -
>
> Key: SOLR-9279
> URL: https://issues.apache.org/jira/browse/SOLR-9279
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Doug Turnbull
> Fix For: master (7.0)
>
>
> If you use the "if" function query, you'll often expect to be able to use 
> greater than/less than functions. For example, you might want to boost books 
> written in the past 7 years. Unfortunately, there's no "greater than" 
> function query that will return non-zero when the lhs > rhs. Instead to get 
> this, you need to create really awkward function queries like I do here 
> (http://opensourceconnections.com/blog/2014/11/26/stepwise-date-boosting-in-solr/):
> if(min(0,sub(ms(mydatefield),sub(ms(NOW),315569259747))),0.8,1)
> The pull request attached to this Jira adds the following function queries
> (https://github.com/apache/lucene-solr/pull/49)
> -gt(lhs, rhs) (returns 1 if lhs > rhs, 0 otherwise)
> -lt(lhs, rhs) (returns 1 if lhs < rhs, 0 otherwise)
> -gte
> -lte
> -eq
> So instead of 
> if(min(0,sub(ms(mydatefield),sub(ms(NOW),315569259747))),0.8,1)
> one could now write
> if(lt(ms(mydatefield),315569259747,0.8,1)
> (if mydatefield < 315569259747 then 0.8 else 1)
> A bit more readable and less puzzling



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

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

[GitHub] lucene-solr issue #53: GC logs go to SOLR_LOGS_DIR on Windows

[tflobbe]

Github user tflobbe commented on the issue:

https://github.com/apache/lucene-solr/pull/53
  
This PR doesn't seem to be linked to any Jira. Is there one? If you include 
the Jira issue id in the title of the PR it will automatically show in Jira 
(e.g. https://issues.apache.org/jira/browse/SOLR-9279 ). You can create a new 
Jira issue if there isn't one for this fix


---
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] [Updated] (SOLR-9340) ConnectionManager Logging Tweaks

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-9340:

Attachment: SOLR-9340.patch

> ConnectionManager Logging Tweaks
> 
>
> Key: SOLR-9340
> URL: https://issues.apache.org/jira/browse/SOLR-9340
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Attachments: SOLR-9340.patch
>
>
> Here are a few logging statements which deserve to be WARN instead of INFO . 
> {code}
> INFO  - TIME [   ] org.apache.solr.common.cloud.ConnectionManager; Watcher 
> org.apache.solr.common.cloud.ConnectionManager@49a818c3 
> name:ZooKeeperConnection Watcher:zk:2181 got event WatchedEvent 
> state:Disconnected type:None path:null path:null type:None
> INFO  - TIME [   ] org.apache.solr.common.cloud.ConnectionManager; zkClient 
> has disconnected
> INFO  - TIME; [   ] org.apache.solr.common.cloud.DefaultConnectionStrategy; 
> Connection expired - starting a new one...
> INFO  - TIME; [   ] org.apache.solr.common.cloud.ConnectionManager; Waiting 
> for client to connect to ZooKeeper
> INFO  - TIME; [   ] org.apache.solr.common.cloud.ConnectionManager; Our 
> previous ZooKeeper session was expired. Attempting to reconnect to recover 
> relationship with ZooKeeper...
> INFO  - TIME; [   ] org.apache.solr.common.cloud.ConnectionManager; Watcher 
> org.apache.solr.common.cloud.ConnectionManager@6484f62a 
> name:ZooKeeperConnection Watcher:zk:2181 got event WatchedEvent state:Expired 
> type:None path:null path:null type:None
> {code}



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

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