[jira] [Commented] (SOLR-9692) BlockUnknown property still breaks the internode communication

[JIRA]

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

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

Yea, did a quick test, looks OK.

> BlockUnknown property still breaks the internode communication
> --
>
> Key: SOLR-9692
> URL: https://issues.apache.org/jira/browse/SOLR-9692
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>  Labels: BasicAuth, security
> Fix For: 6.3
>
>
> This is  still broken after fixing SOLR-9188



--
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-5344) SpellCheckCollatorTest.testEstimatedHitCounts fails in jenkins from time to time

[James Dyer (JIRA)]

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

James Dyer commented on SOLR-5344:
--

ok, I think I know what's going here.  This feature is supposed to estimate hit 
counts for spelling corrections for cases where the client doesn't care about 
the exact # of hits, only that a partcular collation, if re-queried, would 
return something.  To gets estimates, you tell it the max # of documents you 
would like it to collect before quitting.  It then estimates how many hits it 
would have counted with this:

{noformat}
maximum-doc-id * number-of-docs-collected / (# visited docs + last-doc-id + 1)
{noformat}

In the failing test, we ask it to collect between 5 and 20 documents.  The 
max-doc-id is always 17 (there are 17 documents and no deletions).

But the denominator is controlled by the # of visited documents, and also the 
doc id of the one that happened to be visited last.  But in the face of 
randomized testing and release-specific index behavior, I think the best we can 
hope for is a worse-case scenario, between 2 and 15.  The actual correct value 
is 8.

So unless there are objections, I am going to relax the requirement of 6 <= 
hits <= 10 , and use 2 <= hits <= 15.  Maybe we could do better than this, but 
I would think anyone using this feature probably does not need to know more 
than whether or not hits can be produced, or the relative # between several 
collations returned.

> SpellCheckCollatorTest.testEstimatedHitCounts fails in jenkins from time to 
> time
> 
>
> Key: SOLR-5344
> URL: https://issues.apache.org/jira/browse/SOLR-5344
> Project: Solr
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: James Dyer
>
> Doesn't happen very often, but maybe one I can fix. I'll look into it.



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

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

[jira] [Commented] (SOLR-9712) Saner default for maxWarmingSearchers

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-9712:
--

Also, I _think_ there's some kind weird issue where opening a searcher or 
loading a core or something seems to open two searchers so a default of 1 would 
generate the log warning messages every time which is disconcerting to the 
users. I don't recall the exact Solr JIRA or whether it's been fixed so FYI, so 
that's something to check.


> Saner default for maxWarmingSearchers
> -
>
> Key: SOLR-9712
> URL: https://issues.apache.org/jira/browse/SOLR-9712
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Shalin Shekhar Mangar
> Fix For: master (7.0), 6.4
>
>
> As noted in SOLR-9710, the default for maxWarmingSearchers is 
> Integer.MAX_VALUE which is just crazy. Let's have a saner default. Today we 
> log a performance warning when the number of on deck searchers goes over 1. 
> What if we had the default as 1 that expert users can increase if needed?



--
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-9719) Admin UI: When reporting errors on core startup, also show the path to the Solr log file

[Erick Erickson (JIRA)]

Erick Erickson created SOLR-9719:


 Summary: Admin UI: When reporting errors on core startup, also 
show the path to the Solr log file
 Key: SOLR-9719
 URL: https://issues.apache.org/jira/browse/SOLR-9719
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.3, trunk
Reporter: Erick Erickson
Priority: Minor


Minor, but also easy. When a core fails to load, the admin UI puts up a big red 
error box with messages like "core collection_shard1_replica1 failed to load"

Then at the bottom something like:
look at the log file for additional information.

The trouble is that the operations folks who have to respond to this aren't 
always the ones who, say, configured the log file location in log4j. Printing 
the path to the log file directory would help.



--
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-5344) SpellCheckCollatorTest.testEstimatedHitCounts fails in jenkins from time to time

[James Dyer (JIRA)]

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

James Dyer updated SOLR-5344:
-
Attachment: SOLR-5344.patch

> SpellCheckCollatorTest.testEstimatedHitCounts fails in jenkins from time to 
> time
> 
>
> Key: SOLR-5344
> URL: https://issues.apache.org/jira/browse/SOLR-5344
> Project: Solr
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: James Dyer
> Attachments: SOLR-5344.patch
>
>
> Doesn't happen very often, but maybe one I can fix. I'll look into it.



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

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

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1145 - Still Unstable

[Apache Jenkins Server]

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

5 tests failed.
FAILED:  
org.apache.solr.cloud.CdcrReplicationDistributedZkTest.testResilienceWithDeleteByQueryOnTarget

Error Message:
Timeout while trying to assert number of documents @ target_collection

Stack Trace:
java.lang.AssertionError: Timeout while trying to assert number of documents @ 
target_collection
at 
__randomizedtesting.SeedInfo.seed([48CC68FC1BA3FC71:E8AEFA66CBFA3934]:0)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.assertNumDocs(BaseCdcrDistributedZkTest.java:273)
at 
org.apache.solr.cloud.CdcrReplicationDistributedZkTest.testResilienceWithDeleteByQueryOnTarget(CdcrReplicationDistributedZkTest.java:595)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java: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:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Comment Edited] (SOLR-9636) Use javabin for /stream, /sql internode communication

[Noble Paul (JIRA)]

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

Noble Paul edited comment on SOLR-9636 at 11/2/16 8:36 PM:
---

Nobody ever said there was a bottleneck. We do all our internode communications 
in binary format for a reason. It offers real performance improvements and 
memory efficiency.  That's not to say that we should stop at this. The code has 
so many other inefficiencies too. All of them add up.  You should look at 
SOLR-486 to see the history of binary format.




was (Author: noble.paul):
Nobody ever said there was a bottleneck. We do all our internode communications 
in binary format for a reason. It offers real performance improvements and 
memory efficiency.  That's not to say that wet should stop at this. The code 
has so many other inefficiencies too. All of them add up.  You should look at 
SOLR-486 to see the history of binary format.

> Use javabin for /stream, /sql internode communication
> -
>
> Key: SOLR-9636
> URL: https://issues.apache.org/jira/browse/SOLR-9636
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9636.patch
>
>
> currently it uses json, which is verbose and slow



--
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-9636) Use javabin for /stream, /sql internode communication

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-9636:
--

Nobody ever said there was a bottleneck. We do all our internode communications 
in binary format for a reason. It offers real performance improvements and 
memory efficiency.  That's not to say that wet should stop at this. The code 
has do many other inefficiencies too. All of them add up.  You should look at 
SOLR-486 

> Use javabin for /stream, /sql internode communication
> -
>
> Key: SOLR-9636
> URL: https://issues.apache.org/jira/browse/SOLR-9636
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9636.patch
>
>
> currently it uses json, which is verbose and slow



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

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

Re: [VOTE] - Release Lucene/Solr 6.3.0 RC3

[Jan Høydahl]

SUCCESS! [1:05:53.149540] (macOS)
+1

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

> 2. nov. 2016 kl. 17.34 skrev Shalin Shekhar Mangar :
> 
> Please vote for the third release candidate for Lucene/Solr 6.3.0
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC3-reva66a44513ee8191e25b477372094bfa846450316
> 
> You can run the smoke tester directly with this command:
> python3 -u dev-tools/scripts/smokeTestRelease.py
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC3-reva66a44513ee8191e25b477372094bfa846450316
> 
> Smoke tester passed for me:
> SUCCESS! [0:36:45.760510]
> 
> Here's my +1 to release.
> 
> -- 
> Regards,
> Shalin Shekhar Mangar.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

[jira] [Commented] (SOLR-9709) move http://wiki.apache.org/solr/SolJSON ('JSON specific parameters' +) to Solr Ref Guide

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-9709:
-

Good questions, and I wish I had hard & true answers but I tend to evaluate as 
I go.

I took a crack at stubbing out the page, and I'll explain my thought process a 
bit:

* Since you added the params to the Ref Guide, I removed the content in that 
section, but left the header in case someone has any tips about params.
* The example was long, so I came up with a shorter one and added that to the 
Ref Guide and removed the old example from the Wiki. 
* I left the link to updating docs, but changed it so it pointed to the Ref 
Guide. 
* I left the section on AJAX as-is, because I wasn't really sure if it still 
worked, and don't have time to try to find out. 
* I added a header to the top pointing people to the Ref Guide in general. 

Thanks for helping out with this!

> move http://wiki.apache.org/solr/SolJSON ('JSON specific parameters' +) to 
> Solr Ref Guide
> -
>
> Key: SOLR-9709
> URL: https://issues.apache.org/jira/browse/SOLR-9709
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Response Writers
>Reporter: Christine Poerschke
>Priority: Minor
>
> Currently http://wiki.apache.org/solr/SolJSON#JSON_specific_parameters 
> documents
> * json.nl=flat
> * json.nl=map
> * json.nl=arrarr
> but choices
> * json.nl=arrmap
> * json.nl=arrnvp
> are not documented.
> This ticket is to document {{json.nl=arrnvp}} added by SOLR-9442 and also 
> {{json.nl=arrmap}} which already exists.
> link to relevant code: 
> [JSONResponseWriter.java#L85-L89|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/response/JSONResponseWriter.java#L85-L89]



--
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-7535) Improve Javadoc of PointValues

[Florian Hopf (JIRA)]

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

Florian Hopf updated LUCENE-7535:
-
Description: I was a bit confused by the performance characteristics of the 
new point queries for exact matches. It might make sense to add an explanation 
to the Javadoc.

> Improve Javadoc of PointValues
> --
>
> Key: LUCENE-7535
> URL: https://issues.apache.org/jira/browse/LUCENE-7535
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/javadocs
>Affects Versions: 6.2.1
>Reporter: Florian Hopf
>
> I was a bit confused by the performance characteristics of the new point 
> queries for exact matches. It might make sense to add an explanation to the 
> Javadoc.



--
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-7535) Improve Javadoc of PointValues

[Florian Hopf (JIRA)]

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

Florian Hopf commented on LUCENE-7535:
--

Not sure if this is considered to be an implementation detail though.

> Improve Javadoc of PointValues
> --
>
> Key: LUCENE-7535
> URL: https://issues.apache.org/jira/browse/LUCENE-7535
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/javadocs
>Affects Versions: 6.2.1
>Reporter: Florian Hopf
> Attachments: LUCENE-7535.patch
>
>
> I was a bit confused by the performance characteristics of the new point 
> queries for exact matches. It might make sense to add an explanation to the 
> Javadoc.



--
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-9636) Use javabin for /stream, /sql internode communication

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-9636:
--

And if we decide as a group that this is worth while doing, let's do it in a 
careful, fully thought through way. 

I'd like to see more details in the ticket as to approaches being taken.

> Use javabin for /stream, /sql internode communication
> -
>
> Key: SOLR-9636
> URL: https://issues.apache.org/jira/browse/SOLR-9636
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9636.patch
>
>
> currently it uses json, which is verbose and slow



--
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-7535) Improve Javadoc of PointValues

[Florian Hopf (JIRA)]

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

Florian Hopf updated LUCENE-7535:
-
Attachment: LUCENE-7535.patch

> Improve Javadoc of PointValues
> --
>
> Key: LUCENE-7535
> URL: https://issues.apache.org/jira/browse/LUCENE-7535
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/javadocs
>Affects Versions: 6.2.1
>Reporter: Florian Hopf
> Attachments: LUCENE-7535.patch
>
>
> I was a bit confused by the performance characteristics of the new point 
> queries for exact matches. It might make sense to add an explanation to the 
> Javadoc.



--
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-9636) Use javabin for /stream, /sql internode communication

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-9636 at 11/2/16 7:36 PM:
---

Also, I'm not convinced that the performance bottlenecks are caused by json.

It could be caused by low level docValues hotspots and it could be caused by 
network bottlenecks.

So, before doing anything let's understand where the bottlenecks actually are.




was (Author: joel.bernstein):
Also, I'm not convinced that the performance bottlenecks are caused by json.

It could be caused by low level level docValues hotspots and it could be caused 
by network bottlenecks.

So, before doing anything let's understand where the bottlenecks actually are.



> Use javabin for /stream, /sql internode communication
> -
>
> Key: SOLR-9636
> URL: https://issues.apache.org/jira/browse/SOLR-9636
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9636.patch
>
>
> currently it uses json, which is verbose and slow



--
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-9636) Use javabin for /stream, /sql internode communication

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-9636:
--

Also, I'm not convinced that the performance bottlenecks are caused by json.

It could be caused by low level level docValues hotspots and it could be caused 
by network bottlenecks.

So, before doing anything let's understand where the bottlenecks actually are.



> Use javabin for /stream, /sql internode communication
> -
>
> Key: SOLR-9636
> URL: https://issues.apache.org/jira/browse/SOLR-9636
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9636.patch
>
>
> currently it uses json, which is verbose and slow



--
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-7527) Facing unsafe memory access operation error while calling searcherManager.maybeReopen()

[Jagmohan Singh (JIRA)]

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

Jagmohan Singh commented on LUCENE-7527:


Michael thanks for replying. We have mounts in different location and NIOFS 
will surely degrade more. The exception is coming while i am trying to call 
maybeReopen() method explicitly under SearcherManager as i want to get the 
latest data before i could do any search. After calling  maybeReopen() we do 
call acquire() and then search and then release at the end of search call.

> Facing unsafe memory access operation error while calling 
> searcherManager.maybeReopen()
> ---
>
> Key: LUCENE-7527
> URL: https://issues.apache.org/jira/browse/LUCENE-7527
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 3.5
>Reporter: Jagmohan Singh
>
> We are getting below error while calling searcherManager.maybeReopen() 
> method. We are using MMAP implementation to read NFS index directory mounted 
> against 3 servers. We have a different process to update the indices and 3 
> other processes to read from the same index. What we believe is that this 
> issue occurs when we call maybeReopen() method during heavy writes to the 
> indices and MMap implementation is not able to coop with it..
> Caused by: java.lang.InternalError: a fault occurred in a recent unsafe 
> memory access operation in compiled Java code
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> org.apache.lucene.store.MMapDirectory.cleanMapping(MMapDirectory.java:158)
> at 
> org.apache.lucene.store.MMapDirectory$MMapIndexInput.close(MMapDirectory.java:389)
> at 
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:690)
> at 
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:593)
> at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:359)
> at 
> org.apache.lucene.index.SegmentInfos.readCurrentVersion(SegmentInfos.java:480)
> at 
> org.apache.lucene.index.DirectoryReader.isCurrent(DirectoryReader.java:901)
> at 
> org.apache.lucene.index.DirectoryReader.doOpenNoWriter(DirectoryReader.java:471)
> at 
> org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:450)
> at 
> org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:391)
> at 
> org.apache.lucene.index.IndexReader.openIfChanged(IndexReader.java:497)
> at 
> org.apache.lucene.search.SearcherManager.maybeReopen(SearcherManager.java:162)



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

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

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

[Shalin Shekhar Mangar]

This is a new test I added in SOLR-9433. I'll fix.

On Thu, Nov 3, 2016 at 12:11 AM, Policeman Jenkins Server
 wrote:
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6221/
> Java: 32bit/jdk1.8.0_102 -server -XX:+UseConcMarkSweepGC
>
> 1 tests failed.
> FAILED:  
> org.apache.solr.handler.admin.CoreAdminHandlerTest.testDeleteInstanceDirAfterCreateFailure
>
> Error Message:
> The data directory was not cleaned up on unload after a failed core reload
>
> Stack Trace:
> java.lang.AssertionError: The data directory was not cleaned up on unload 
> after a failed core reload
> at 
> __randomizedtesting.SeedInfo.seed([9BF1769E0C53944F:E038D4D22F71464E]:0)
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at 
> org.apache.solr.handler.admin.CoreAdminHandlerTest.testDeleteInstanceDirAfterCreateFailure(CoreAdminHandlerTest.java:334)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
> at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
> at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
> at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
> at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
> at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
> at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
> at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
> at 
> org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
> at 
> 

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6221/
Java: 32bit/jdk1.8.0_102 -server -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.solr.handler.admin.CoreAdminHandlerTest.testDeleteInstanceDirAfterCreateFailure

Error Message:
The data directory was not cleaned up on unload after a failed core reload

Stack Trace:
java.lang.AssertionError: The data directory was not cleaned up on unload after 
a failed core reload
at 
__randomizedtesting.SeedInfo.seed([9BF1769E0C53944F:E038D4D22F71464E]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.admin.CoreAdminHandlerTest.testDeleteInstanceDirAfterCreateFailure(CoreAdminHandlerTest.java:334)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11805 lines...]
   [junit4] Suite: org.apache.solr.handler.admin.CoreAdminHandlerTest
   [junit4]   2> Creating 

[jira] [Created] (LUCENE-7535) Improve Javadoc of PointValues

[Florian Hopf (JIRA)]

Florian Hopf created LUCENE-7535:


 Summary: Improve Javadoc of PointValues
 Key: LUCENE-7535
 URL: https://issues.apache.org/jira/browse/LUCENE-7535
 Project: Lucene - Core
  Issue Type: Improvement
  Components: general/javadocs
Affects Versions: 6.2.1
Reporter: Florian Hopf






--
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-7287) New lemma-tizer plugin for ukrainian language.

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on LUCENE-7287:
---

I missed it last go-around. I don't know if I will have time to add it for 6.3, 
but I added it to the TODO list 
(https://cwiki.apache.org/confluence/display/solr/Internal+-+TODO+List) so 
we'll at least know it needs to get done.

> New lemma-tizer plugin for ukrainian language.
> --
>
> Key: LUCENE-7287
> URL: https://issues.apache.org/jira/browse/LUCENE-7287
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/analysis
>Reporter: Dmytro Hambal
>Priority: Minor
>  Labels: analysis, language, plugin
> Fix For: master (7.0), 6.2
>
> Attachments: LUCENE-7287.patch, Screen Shot 2016-06-23 at 8.23.01 
> PM.png, Screen Shot 2016-06-23 at 8.41.28 PM.png
>
>
> Hi all,
> I wonder whether you are interested in supporting a plugin which provides a 
> mapping between ukrainian word forms and their lemmas. Some tests and docs go 
> out-of-the-box =) .
> https://github.com/mrgambal/elasticsearch-ukrainian-lemmatizer
> It's really simple but still works and generates some value for its users.
> More: https://github.com/elastic/elasticsearch/issues/18303



--
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-9636) Use javabin for /stream, /sql internode communication

[Noble Paul (JIRA)]

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

Noble Paul edited comment on SOLR-9636 at 11/2/16 8:30 PM:
---

Nobody ever said there was a bottleneck. We do all our internode communications 
in binary format for a reason. It offers real performance improvements and 
memory efficiency.  That's not to say that wet should stop at this. The code 
has so many other inefficiencies too. All of them add up.  You should look at 
SOLR-486 to see the history of binary format.


was (Author: noble.paul):
Nobody ever said there was a bottleneck. We do all our internode communications 
in binary format for a reason. It offers real performance improvements and 
memory efficiency.  That's not to say that wet should stop at this. The code 
has do many other inefficiencies too. All of them add up.  You should look at 
SOLR-486 

> Use javabin for /stream, /sql internode communication
> -
>
> Key: SOLR-9636
> URL: https://issues.apache.org/jira/browse/SOLR-9636
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9636.patch
>
>
> currently it uses json, which is verbose and slow



--
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-9636) Use javabin for /stream, /sql internode communication

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-9636:
--

I'm not sure that I agree this needs to be done. 

How much performance improvements will we see in real world examples?

> Use javabin for /stream, /sql internode communication
> -
>
> Key: SOLR-9636
> URL: https://issues.apache.org/jira/browse/SOLR-9636
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9636.patch
>
>
> currently it uses json, which is verbose and slow



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

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

Re: [VOTE] - Release Lucene/Solr 6.3.0 RC3

[Tommaso Teofili]

SUCCESS! [1:54:38.816517]

+1

Tommaso

Il giorno mer 2 nov 2016 alle ore 19:56 Jan Høydahl 
ha scritto:

> SUCCESS! [1:05:53.149540] (macOS)
> +1
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> 2. nov. 2016 kl. 17.34 skrev Shalin Shekhar Mangar :
>
> Please vote for the third release candidate for Lucene/Solr 6.3.0
>
> The artifacts can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC3-reva66a44513ee8191e25b477372094bfa846450316
>
> You can run the smoke tester directly with this command:
> python3 -u dev-tools/scripts/smokeTestRelease.py
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC3-reva66a44513ee8191e25b477372094bfa846450316
>
> Smoke tester passed for me:
> SUCCESS! [0:36:45.760510]
>
> Here's my +1 to release.
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.spelling.DirectSolrSpellCheckerTest

Error Message:
Error opening new searcher. exceeded limit of maxWarmingSearchers=1, try again 
later.

Stack Trace:
org.apache.solr.common.SolrException: Error opening new searcher. exceeded 
limit of maxWarmingSearchers=1, try again later.
at __randomizedtesting.SeedInfo.seed([14BB9C9E0816C843]:0)
at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1933)
at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1693)
at 
org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:638)
at 
org.apache.solr.update.processor.RunUpdateProcessor.processCommit(RunUpdateProcessorFactory.java:93)
at 
org.apache.solr.update.processor.UpdateRequestProcessor.processCommit(UpdateRequestProcessor.java:61)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalCommit(DistributedUpdateProcessor.java:1664)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.processCommit(DistributedUpdateProcessor.java:1641)
at 
org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processCommit(LogUpdateProcessorFactory.java:160)
at 
org.apache.solr.handler.loader.XMLLoader.processUpdate(XMLLoader.java:270)
at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:177)
at 
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97)
at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:153)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2229)
at 
org.apache.solr.servlet.DirectSolrConnection.request(DirectSolrConnection.java:124)
at org.apache.solr.util.TestHarness.update(TestHarness.java:257)
at 
org.apache.solr.util.BaseTestHarness.checkUpdateStatus(BaseTestHarness.java:281)
at 
org.apache.solr.util.BaseTestHarness.validateUpdate(BaseTestHarness.java:251)
at 
org.apache.solr.spelling.DirectSolrSpellCheckerTest.beforeClass(DirectSolrSpellCheckerTest.java:51)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:847)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(java.base@9-ea/Thread.java:843)


FAILED:  

[jira] [Commented] (LUCENE-7501) Do not encode the split dimension in the index in the 1D case

[ASF subversion and git services (JIRA)]

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

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

Commit 35f3cd9bd95607983fa4704c66f61bf59cd40860 in lucene-solr's branch 
refs/heads/branch_6x from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=35f3cd9 ]

LUCENE-7501: fix back-compat bug; add test


> Do not encode the split dimension in the index in the 1D case
> -
>
> Key: LUCENE-7501
> URL: https://issues.apache.org/jira/browse/LUCENE-7501
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Blocker
> Fix For: master (7.0), 6.3
>
> Attachments: LUCENE-7501.patch, LUCENE-7501.patch, LUCENE-7501.patch
>
>
> When there is a single dimension, the split dimension is always 0, so we do 
> not need to encode it in the index of the BKD tree. This would be 33% memory 
> saving for half floats, 20% for ints/floats, 11% for longs/doubles and 6% for 
> ip addresses.



--
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-7501) Do not encode the split dimension in the index in the 1D case

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7501:


Hmm I'm not sure why the commit bot doesn't show my push to branch_6_3, but I 
did push the fix there too!

> Do not encode the split dimension in the index in the 1D case
> -
>
> Key: LUCENE-7501
> URL: https://issues.apache.org/jira/browse/LUCENE-7501
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Blocker
> Fix For: master (7.0), 6.3
>
> Attachments: LUCENE-7501.patch, LUCENE-7501.patch, LUCENE-7501.patch
>
>
> When there is a single dimension, the split dimension is always 0, so we do 
> not need to encode it in the index of the BKD tree. This would be 33% memory 
> saving for half floats, 20% for ints/floats, 11% for longs/doubles and 6% for 
> ip addresses.



--
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-9715) Add function for string length

[Mats Lindh (JIRA)]

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

Mats Lindh updated SOLR-9715:
-
Description: 
This allows a query to use the string length in a Solr query, without having to 
index a separate field with the length. The function is named "strlen" in the 
patch, but another option is "stringlength".

Since this also introduced a new ValueSource in Lucene, I'm not sure if I 
should split the patch up into two separate issues, but as the Solr patch would 
rely on the Lucene patch being accepted, I've included them both in this issue 
for now. 

Patch includes two tests in TestFunctionQuery. Patch is against the current 
HEAD from github/lucene-solr.

  was:
This allows a query to use the string length in a Solr query, without having to 
index a separate field with the length.

Since this also introduced a new ValueSource in Lucene, I'm not sure if I 
should split the patch up into two separate issues, but as the Solr patch would 
rely on the Lucene patch being accepted, I've included them both in this issue 
for now. 

Patch includes two tests in TestFunctionQuery. Patch is against the current 
HEAD from github/lucene-solr.


> Add function for string length
> --
>
> Key: SOLR-9715
> URL: https://issues.apache.org/jira/browse/SOLR-9715
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Affects Versions: master (7.0)
>Reporter: Mats Lindh
>Priority: Trivial
>  Labels: feature, function, newbie
> Attachments: SOLR-9715.patch
>
>
> This allows a query to use the string length in a Solr query, without having 
> to index a separate field with the length. The function is named "strlen" in 
> the patch, but another option is "stringlength".
> Since this also introduced a new ValueSource in Lucene, I'm not sure if I 
> should split the patch up into two separate issues, but as the Solr patch 
> would rely on the Lucene patch being accepted, I've included them both in 
> this issue for now. 
> Patch includes two tests in TestFunctionQuery. Patch is against the current 
> HEAD from github/lucene-solr.



--
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-MAVEN] Lucene-Solr-Maven-master #1873: POMs out of sync

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-master/1873/

No tests ran.

Build Log:
[...truncated 36706 lines...]
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/build.xml:783: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/build.xml:324: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/solr/build.xml:691:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/solr/common-build.xml:463:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/lucene/common-build.xml:1667:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/lucene/common-build.xml:561:
 Unable to initialize POM pom.xml: Could not find the model file 
'/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/lucene/build/poms/solr/contrib/ltr/pom.xml'.
 for project unknown

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



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

Re: [VOTE] Release Lucene/Solr 6.3.0 RC2

[Michael McCandless]

ARGH.

There is a bug in LUCENE-7135.  Hold please :)

Mike McCandless

http://blog.mikemccandless.com


On Wed, Nov 2, 2016 at 6:15 AM, Michael McCandless
 wrote:
> OK LUCENE-7501 is fixed now too!  I think you can spin the next RC Shalin?
>
> Thanks and sorry!
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Wed, Nov 2, 2016 at 4:57 AM, Michael McCandless
>  wrote:
>> Thanks Shalin, I backported it.
>>
>> Still working on LUCENE-7501...
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>>
>> On Wed, Nov 2, 2016 at 4:39 AM, Shalin Shekhar Mangar
>>  wrote:
>>> Please go ahead, Mike.
>>>
>>> On Wed, Nov 2, 2016 at 2:07 PM, Michael McCandless
>>>  wrote:
 Hi Shalin,

 Since we must re-spin for LUCENE-7501 (I'm still working on that), is
 it OK if I backport LUCENE-7135 for 6.3.0?

 At least, I need to fix the CHANGES.txt entry if not.

 Mike McCandless

 http://blog.mikemccandless.com


 On Tue, Nov 1, 2016 at 5:19 PM, Michael McCandless
  wrote:
> I think there's possibly a bad problem with LUCENE-7501 (creates a
> possibly corrupt index) ... I'm trying to dig more to be sure ...
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Mon, Oct 31, 2016 at 2:28 PM, Shalin Shekhar Mangar
>  wrote:
>> Please vote for the second release candidate for Lucene/Solr 6.3.0
>>
>> The artifacts can be downloaded from:
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/
>>
>> You can run the smoke tester directly with this command:
>> python3 -u dev-tools/scripts/smokeTestRelease.py
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/
>>
>> Smoke tester passed for me:
>> SUCCESS! [0:35:05.847870]
>>
>> Here's my +1 to release.
>>
>> --
>> Regards,
>> Shalin Shekhar Mangar.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>

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

>>>
>>>
>>>
>>> --
>>> Regards,
>>> Shalin Shekhar Mangar.
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>

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

[jira] [Commented] (LUCENE-7135) Constants check for JRE bitness causes SecurityException under WebStart

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7135:


There is a bug in the logic here: it marks a 64 bit JVM as 32 bit!

> Constants check for JRE bitness causes SecurityException under WebStart
> ---
>
> Key: LUCENE-7135
> URL: https://issues.apache.org/jira/browse/LUCENE-7135
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/other
>Affects Versions: 5.5
> Environment: OS X 10.11.4, Java 1.8.0_77-b03 (under WebStart)
>Reporter: Aaron Madlon-Kay
> Fix For: master (7.0), 6.3, 5.5.4
>
> Attachments: LUCENE-7135.diff
>
>
> I have an app that I deploy via WebStart that uses Lucene 5.2.1 (we are 
> locked to 5.2.1 because that's what [LanguageTool|https://languagetool.org/] 
> uses).
> When running under the WebStart security manager, there are two locations 
> where exceptions are thrown and prevent pretty much all Lucene classes from 
> initializing. This is true even when we sign everything and specify 
> {{}}.
> # In {{RamUsageEstimator}}, fixed by LUCENE-6923
> # In {{Constants}}, caused by the call 
> {{System.getProperty("sun.arch.data.model")}} (stack trace below).
> {code}
> Error: Caused by: java.security.AccessControlException: access denied 
> ("java.util.PropertyPermission" "sun.arch.data.model" "read") 
> Error:at 
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>  
> Error:at 
> java.security.AccessController.checkPermission(AccessController.java:884) 
> Error:at 
> java.lang.SecurityManager.checkPermission(SecurityManager.java:549) 
> Error:at 
> com.sun.javaws.security.JavaWebStartSecurity.checkPermission(Unknown Source) 
> Error:at 
> java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1294) 
> Error:at java.lang.System.getProperty(System.java:717) 
> Error:at org.apache.lucene.util.Constants.(Constants.java:71) 
> Error:... 34 more 
> {code}
> The latter is still present in the latest version. My patch illustrates one 
> solution that appears to be working for us.
> (This patch, together with a backport of the fix to LUCENE-6923, seems to fix 
> the issue for our purposes. However if you really wanted to make my day you 
> could put out a maintenance release of 5.2 with both fixes included.)



--
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-7135) Constants check for JRE bitness causes SecurityException under WebStart

[ASF subversion and git services (JIRA)]

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

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

Commit 92f56ea9dd72d935c21aadae6a20ee23fa9c3cf8 in lucene-solr's branch 
refs/heads/master from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=92f56ea ]

LUCENE-7135: only use OS_ARCH if we couldn't access sun.arch.data.model


> Constants check for JRE bitness causes SecurityException under WebStart
> ---
>
> Key: LUCENE-7135
> URL: https://issues.apache.org/jira/browse/LUCENE-7135
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/other
>Affects Versions: 5.5
> Environment: OS X 10.11.4, Java 1.8.0_77-b03 (under WebStart)
>Reporter: Aaron Madlon-Kay
> Fix For: master (7.0), 6.3, 5.5.4
>
> Attachments: LUCENE-7135.diff
>
>
> I have an app that I deploy via WebStart that uses Lucene 5.2.1 (we are 
> locked to 5.2.1 because that's what [LanguageTool|https://languagetool.org/] 
> uses).
> When running under the WebStart security manager, there are two locations 
> where exceptions are thrown and prevent pretty much all Lucene classes from 
> initializing. This is true even when we sign everything and specify 
> {{}}.
> # In {{RamUsageEstimator}}, fixed by LUCENE-6923
> # In {{Constants}}, caused by the call 
> {{System.getProperty("sun.arch.data.model")}} (stack trace below).
> {code}
> Error: Caused by: java.security.AccessControlException: access denied 
> ("java.util.PropertyPermission" "sun.arch.data.model" "read") 
> Error:at 
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>  
> Error:at 
> java.security.AccessController.checkPermission(AccessController.java:884) 
> Error:at 
> java.lang.SecurityManager.checkPermission(SecurityManager.java:549) 
> Error:at 
> com.sun.javaws.security.JavaWebStartSecurity.checkPermission(Unknown Source) 
> Error:at 
> java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1294) 
> Error:at java.lang.System.getProperty(System.java:717) 
> Error:at org.apache.lucene.util.Constants.(Constants.java:71) 
> Error:... 34 more 
> {code}
> The latter is still present in the latest version. My patch illustrates one 
> solution that appears to be working for us.
> (This patch, together with a backport of the fix to LUCENE-6923, seems to fix 
> the issue for our purposes. However if you really wanted to make my day you 
> could put out a maintenance release of 5.2 with both fixes included.)



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

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

[jira] [Created] (LUCENE-7534) smokeTestRelease.py on cygwin [Errno 2] No such file or directory:

[Mikhail Khludnev (JIRA)]

Mikhail Khludnev created LUCENE-7534:


 Summary: smokeTestRelease.py on cygwin [Errno 2] No such file or 
directory: 
 Key: LUCENE-7534
 URL: https://issues.apache.org/jira/browse/LUCENE-7534
 Project: Lucene - Core
  Issue Type: Bug
 Environment: Windows, Cygwin, Python

Reporter: Mikhail Khludnev


{quote}
$ python3 -u dev-tools/scripts/smokeTestRelease.py 
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/
Revision: 1fe1a54db32b8c27bfae81887cd4d75242090613
Java 1.8 JAVA_HOME=C:\Program Files\Java\jdk1.8.0_102
Traceback (most recent call last):
  File "dev-tools/scripts/smokeTestRelease.py", line 1440, in 
main()
  File "dev-tools/scripts/smokeTestRelease.py", line 1377, in main
c = parse_config()
  File "dev-tools/scripts/smokeTestRelease.py", line 1239, in parse_config
c.java = make_java_config(parser, c.test_java8)
  File "dev-tools/scripts/smokeTestRelease.py", line 1193, in make_java_config
run_java8 = _make_runner(java8_home, '1.8')
  File "dev-tools/scripts/smokeTestRelease.py", line 1179, in _make_runner
java_home = subprocess.check_output('cygpath -u "%s"' % 
java_home).read().decode('utf-8').strip()
  File "/usr/lib/python3.4/subprocess.py", line 607, in check_output
with Popen(*popenargs, stdout=PIPE, **kwargs) as process:
  File "/usr/lib/python3.4/subprocess.py", line 859, in __init__
restore_signals, start_new_session)
  File "/usr/lib/python3.4/subprocess.py", line 1457, in _execute_child
raise child_exception_type(errno_num, err_msg)
FileNotFoundError: [Errno 2] No such file or directory: 'cygpath -u 
"C:\\Program Files\\Java\\jdk1.8.0_102"'
{quote}

giving [the doc|https://docs.python.org/3.4/library/subprocess.html] path and 
args should be either supplied as array of terms or supplied as {{shell=True}}




--
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-7135) Constants check for JRE bitness causes SecurityException under WebStart

[ASF subversion and git services (JIRA)]

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

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

Commit 97c97838022efcac8ccbcffb5edf5735605fdf17 in lucene-solr's branch 
refs/heads/branch_6x from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=97c9783 ]

LUCENE-7135: only use OS_ARCH if we couldn't access sun.arch.data.model


> Constants check for JRE bitness causes SecurityException under WebStart
> ---
>
> Key: LUCENE-7135
> URL: https://issues.apache.org/jira/browse/LUCENE-7135
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/other
>Affects Versions: 5.5
> Environment: OS X 10.11.4, Java 1.8.0_77-b03 (under WebStart)
>Reporter: Aaron Madlon-Kay
> Fix For: master (7.0), 6.3, 5.5.4
>
> Attachments: LUCENE-7135.diff
>
>
> I have an app that I deploy via WebStart that uses Lucene 5.2.1 (we are 
> locked to 5.2.1 because that's what [LanguageTool|https://languagetool.org/] 
> uses).
> When running under the WebStart security manager, there are two locations 
> where exceptions are thrown and prevent pretty much all Lucene classes from 
> initializing. This is true even when we sign everything and specify 
> {{}}.
> # In {{RamUsageEstimator}}, fixed by LUCENE-6923
> # In {{Constants}}, caused by the call 
> {{System.getProperty("sun.arch.data.model")}} (stack trace below).
> {code}
> Error: Caused by: java.security.AccessControlException: access denied 
> ("java.util.PropertyPermission" "sun.arch.data.model" "read") 
> Error:at 
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>  
> Error:at 
> java.security.AccessController.checkPermission(AccessController.java:884) 
> Error:at 
> java.lang.SecurityManager.checkPermission(SecurityManager.java:549) 
> Error:at 
> com.sun.javaws.security.JavaWebStartSecurity.checkPermission(Unknown Source) 
> Error:at 
> java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1294) 
> Error:at java.lang.System.getProperty(System.java:717) 
> Error:at org.apache.lucene.util.Constants.(Constants.java:71) 
> Error:... 34 more 
> {code}
> The latter is still present in the latest version. My patch illustrates one 
> solution that appears to be working for us.
> (This patch, together with a backport of the fix to LUCENE-6923, seems to fix 
> the issue for our purposes. However if you really wanted to make my day you 
> could put out a maintenance release of 5.2 with both fixes included.)



--
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-9715) Add function for string length

[Mats Lindh (JIRA)]

Mats Lindh created SOLR-9715:


 Summary: Add function for string length
 Key: SOLR-9715
 URL: https://issues.apache.org/jira/browse/SOLR-9715
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: search
Affects Versions: master (7.0)
Reporter: Mats Lindh
Priority: Trivial


This allows a query to use the string length in a Solr query, without having to 
index a separate field with the length.

Since this also introduced a new ValueSource in Lucene, I'm not sure if I 
should split the patch up into two separate issues, but as the Solr patch would 
rely on the Lucene patch being accepted, I've included them both in this issue 
for now. 

Patch includes two tests in TestFunctionQuery. Patch is against the current 
HEAD from github/lucene-solr.



--
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-9715) Add function for string length

[Mats Lindh (JIRA)]

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

Mats Lindh updated SOLR-9715:
-
Attachment: SOLR-9715.patch

> Add function for string length
> --
>
> Key: SOLR-9715
> URL: https://issues.apache.org/jira/browse/SOLR-9715
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Affects Versions: master (7.0)
>Reporter: Mats Lindh
>Priority: Trivial
>  Labels: feature, function, newbie
> Attachments: SOLR-9715.patch
>
>
> This allows a query to use the string length in a Solr query, without having 
> to index a separate field with the length.
> Since this also introduced a new ValueSource in Lucene, I'm not sure if I 
> should split the patch up into two separate issues, but as the Solr patch 
> would rely on the Lucene patch being accepted, I've included them both in 
> this issue for now. 
> Patch includes two tests in TestFunctionQuery. Patch is against the current 
> HEAD from github/lucene-solr.



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

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

Re: [VOTE] Release Lucene/Solr 6.3.0 RC2

[Michael McCandless]

OK LUCENE-7501 is fixed now too!  I think you can spin the next RC Shalin?

Thanks and sorry!

Mike McCandless

http://blog.mikemccandless.com


On Wed, Nov 2, 2016 at 4:57 AM, Michael McCandless
 wrote:
> Thanks Shalin, I backported it.
>
> Still working on LUCENE-7501...
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Wed, Nov 2, 2016 at 4:39 AM, Shalin Shekhar Mangar
>  wrote:
>> Please go ahead, Mike.
>>
>> On Wed, Nov 2, 2016 at 2:07 PM, Michael McCandless
>>  wrote:
>>> Hi Shalin,
>>>
>>> Since we must re-spin for LUCENE-7501 (I'm still working on that), is
>>> it OK if I backport LUCENE-7135 for 6.3.0?
>>>
>>> At least, I need to fix the CHANGES.txt entry if not.
>>>
>>> Mike McCandless
>>>
>>> http://blog.mikemccandless.com
>>>
>>>
>>> On Tue, Nov 1, 2016 at 5:19 PM, Michael McCandless
>>>  wrote:
 I think there's possibly a bad problem with LUCENE-7501 (creates a
 possibly corrupt index) ... I'm trying to dig more to be sure ...

 Mike McCandless

 http://blog.mikemccandless.com

 On Mon, Oct 31, 2016 at 2:28 PM, Shalin Shekhar Mangar
  wrote:
> Please vote for the second release candidate for Lucene/Solr 6.3.0
>
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/
>
> You can run the smoke tester directly with this command:
> python3 -u dev-tools/scripts/smokeTestRelease.py
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/
>
> Smoke tester passed for me:
> SUCCESS! [0:35:05.847870]
>
> Here's my +1 to release.
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>
>>
>>
>> --
>> Regards,
>> Shalin Shekhar Mangar.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>

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

[jira] [Commented] (LUCENE-7135) Constants check for JRE bitness causes SecurityException under WebStart

[Aaron Madlon-Kay (JIRA)]

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

Aaron Madlon-Kay commented on LUCENE-7135:
--

Very sorry about that!

> Constants check for JRE bitness causes SecurityException under WebStart
> ---
>
> Key: LUCENE-7135
> URL: https://issues.apache.org/jira/browse/LUCENE-7135
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/other
>Affects Versions: 5.5
> Environment: OS X 10.11.4, Java 1.8.0_77-b03 (under WebStart)
>Reporter: Aaron Madlon-Kay
> Fix For: master (7.0), 6.3, 5.5.4
>
> Attachments: LUCENE-7135.diff
>
>
> I have an app that I deploy via WebStart that uses Lucene 5.2.1 (we are 
> locked to 5.2.1 because that's what [LanguageTool|https://languagetool.org/] 
> uses).
> When running under the WebStart security manager, there are two locations 
> where exceptions are thrown and prevent pretty much all Lucene classes from 
> initializing. This is true even when we sign everything and specify 
> {{}}.
> # In {{RamUsageEstimator}}, fixed by LUCENE-6923
> # In {{Constants}}, caused by the call 
> {{System.getProperty("sun.arch.data.model")}} (stack trace below).
> {code}
> Error: Caused by: java.security.AccessControlException: access denied 
> ("java.util.PropertyPermission" "sun.arch.data.model" "read") 
> Error:at 
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>  
> Error:at 
> java.security.AccessController.checkPermission(AccessController.java:884) 
> Error:at 
> java.lang.SecurityManager.checkPermission(SecurityManager.java:549) 
> Error:at 
> com.sun.javaws.security.JavaWebStartSecurity.checkPermission(Unknown Source) 
> Error:at 
> java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1294) 
> Error:at java.lang.System.getProperty(System.java:717) 
> Error:at org.apache.lucene.util.Constants.(Constants.java:71) 
> Error:... 34 more 
> {code}
> The latter is still present in the latest version. My patch illustrates one 
> solution that appears to be working for us.
> (This patch, together with a backport of the fix to LUCENE-6923, seems to fix 
> the issue for our purposes. However if you really wanted to make my day you 
> could put out a maintenance release of 5.2 with both fixes included.)



--
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-9714) can not stop solr with $STOP_PORT

[JIRA]

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

胡晓东 updated SOLR-9714:
--
Attachment: SOLR-9714.patch

I resolved this issue, welcome to test.

> can not stop solr with $STOP_PORT
> -
>
> Key: SOLR-9714
> URL: https://issues.apache.org/jira/browse/SOLR-9714
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 5.5.3, 6.2.1
>Reporter: 胡晓东
> Attachments: SOLR-9714.patch
>
>
> start:
>export SOLR_PORT="8983"
>export STOP_PORT="8984"
>... ...
> and use command  '$SOLR_HOME/bin/solr start ' to start solr
> stop:
>   export SOLR_PORT="8983"
>   export STOP_PORT="8984"
>   ... ...
>   use command  '$SOLR_HOME/bin/solr stop'  will throw exception below
>Sending stop command to Solr running on port 8983 ... waiting 5 
> seconds to allow Jetty process 18791 to stop gracefully.
> + /usr/java/jdk/bin/java -jar /opt/ZDH/parcels/lib/solr/server/start.jar 
> STOP.PORT=7983 STOP.KEY=solrrocks --stop
> java.net.ConnectException: Connection refused
>   at java.net.PlainSocketImpl.socketConnect(Native Method)
>   at 
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
>   at 
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
>   at 
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
>   at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
>   at java.net.Socket.connect(Socket.java:579)
>   at java.net.Socket.connect(Socket.java:528)
>   at java.net.Socket.(Socket.java:425)
>   at java.net.Socket.(Socket.java:241)
>   at org.eclipse.jetty.start.Main.stop(Main.java:869)
>   at org.eclipse.jetty.start.Main.stop(Main.java:848)
>   at org.eclipse.jetty.start.Main.doStop(Main.java:839)
>   at org.eclipse.jetty.start.Main.start(Main.java:692)
>   at org.eclipse.jetty.start.Main.main(Main.java:112)



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

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

[jira] [Resolved] (LUCENE-7501) Do not encode the split dimension in the index in the 1D case

[Michael McCandless (JIRA)]

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

Michael McCandless resolved LUCENE-7501.

Resolution: Fixed

> Do not encode the split dimension in the index in the 1D case
> -
>
> Key: LUCENE-7501
> URL: https://issues.apache.org/jira/browse/LUCENE-7501
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Blocker
> Fix For: master (7.0), 6.3
>
> Attachments: LUCENE-7501.patch, LUCENE-7501.patch, LUCENE-7501.patch
>
>
> When there is a single dimension, the split dimension is always 0, so we do 
> not need to encode it in the index of the BKD tree. This would be 33% memory 
> saving for half floats, 20% for ints/floats, 11% for longs/doubles and 6% for 
> ip addresses.



--
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-7135) Constants check for JRE bitness causes SecurityException under WebStart

[ASF subversion and git services (JIRA)]

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

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

Commit a66a44513ee8191e25b477372094bfa846450316 in lucene-solr's branch 
refs/heads/branch_6_3 from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a66a445 ]

LUCENE-7135: only use OS_ARCH if we couldn't access sun.arch.data.model


> Constants check for JRE bitness causes SecurityException under WebStart
> ---
>
> Key: LUCENE-7135
> URL: https://issues.apache.org/jira/browse/LUCENE-7135
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/other
>Affects Versions: 5.5
> Environment: OS X 10.11.4, Java 1.8.0_77-b03 (under WebStart)
>Reporter: Aaron Madlon-Kay
> Fix For: master (7.0), 6.3, 5.5.4
>
> Attachments: LUCENE-7135.diff
>
>
> I have an app that I deploy via WebStart that uses Lucene 5.2.1 (we are 
> locked to 5.2.1 because that's what [LanguageTool|https://languagetool.org/] 
> uses).
> When running under the WebStart security manager, there are two locations 
> where exceptions are thrown and prevent pretty much all Lucene classes from 
> initializing. This is true even when we sign everything and specify 
> {{}}.
> # In {{RamUsageEstimator}}, fixed by LUCENE-6923
> # In {{Constants}}, caused by the call 
> {{System.getProperty("sun.arch.data.model")}} (stack trace below).
> {code}
> Error: Caused by: java.security.AccessControlException: access denied 
> ("java.util.PropertyPermission" "sun.arch.data.model" "read") 
> Error:at 
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>  
> Error:at 
> java.security.AccessController.checkPermission(AccessController.java:884) 
> Error:at 
> java.lang.SecurityManager.checkPermission(SecurityManager.java:549) 
> Error:at 
> com.sun.javaws.security.JavaWebStartSecurity.checkPermission(Unknown Source) 
> Error:at 
> java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1294) 
> Error:at java.lang.System.getProperty(System.java:717) 
> Error:at org.apache.lucene.util.Constants.(Constants.java:71) 
> Error:... 34 more 
> {code}
> The latter is still present in the latest version. My patch illustrates one 
> solution that appears to be working for us.
> (This patch, together with a backport of the fix to LUCENE-6923, seems to fix 
> the issue for our purposes. However if you really wanted to make my day you 
> could put out a maintenance release of 5.2 with both fixes included.)



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

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

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

[Policeman Jenkins Server]

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

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

Error Message:
List size mismatch @ spellcheck/suggestions

Stack Trace:
java.lang.RuntimeException: List size mismatch @ spellcheck/suggestions
at 
__randomizedtesting.SeedInfo.seed([2A108AE0A369B19D:A244B53A0D95DC65]:0)
at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:900)
at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:847)
at 
org.apache.solr.handler.component.SpellCheckComponentTest.test(SpellCheckComponentTest.java:147)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(java.base@9-ea/Thread.java:843)




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

[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 610 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/610/

No tests ran.

Build Log:
[...truncated 36373 lines...]
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/build.xml:545:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build.xml:698:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build.xml:691:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/common-build.xml:463:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/common-build.xml:1667:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/common-build.xml:561:
 Unable to initialize POM pom.xml: Could not find the model file 
'/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/poms/solr/contrib/ltr/pom.xml'.
 for project unknown

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




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

[jira] [Commented] (LUCENE-7501) Do not encode the split dimension in the index in the 1D case

[ASF subversion and git services (JIRA)]

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

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

Commit 69e654b3737a97fea7ffc9f57c8fad5e85f72452 in lucene-solr's branch 
refs/heads/master from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=69e654b ]

LUCENE-7501: fix back-compat bug; add test


> Do not encode the split dimension in the index in the 1D case
> -
>
> Key: LUCENE-7501
> URL: https://issues.apache.org/jira/browse/LUCENE-7501
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Blocker
> Fix For: master (7.0), 6.3
>
> Attachments: LUCENE-7501.patch, LUCENE-7501.patch, LUCENE-7501.patch
>
>
> When there is a single dimension, the split dimension is always 0, so we do 
> not need to encode it in the index of the BKD tree. This would be 33% memory 
> saving for half floats, 20% for ints/floats, 11% for longs/doubles and 6% for 
> ip addresses.



--
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-7534) smokeTestRelease.py on cygwin [Errno 2] No such file or directory:

[Mikhail Khludnev (JIRA)]

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

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

> smokeTestRelease.py on cygwin [Errno 2] No such file or directory: 
> ---
>
> Key: LUCENE-7534
> URL: https://issues.apache.org/jira/browse/LUCENE-7534
> Project: Lucene - Core
>  Issue Type: Bug
> Environment: Windows, Cygwin, Python
>Reporter: Mikhail Khludnev
> Attachments: LUCENE-7534.patch
>
>
> {quote}
> $ python3 -u dev-tools/scripts/smokeTestRelease.py 
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/
> Revision: 1fe1a54db32b8c27bfae81887cd4d75242090613
> Java 1.8 JAVA_HOME=C:\Program Files\Java\jdk1.8.0_102
> Traceback (most recent call last):
>   File "dev-tools/scripts/smokeTestRelease.py", line 1440, in 
> main()
>   File "dev-tools/scripts/smokeTestRelease.py", line 1377, in main
> c = parse_config()
>   File "dev-tools/scripts/smokeTestRelease.py", line 1239, in parse_config
> c.java = make_java_config(parser, c.test_java8)
>   File "dev-tools/scripts/smokeTestRelease.py", line 1193, in make_java_config
> run_java8 = _make_runner(java8_home, '1.8')
>   File "dev-tools/scripts/smokeTestRelease.py", line 1179, in _make_runner
> java_home = subprocess.check_output('cygpath -u "%s"' % 
> java_home).read().decode('utf-8').strip()
>   File "/usr/lib/python3.4/subprocess.py", line 607, in check_output
> with Popen(*popenargs, stdout=PIPE, **kwargs) as process:
>   File "/usr/lib/python3.4/subprocess.py", line 859, in __init__
> restore_signals, start_new_session)
>   File "/usr/lib/python3.4/subprocess.py", line 1457, in _execute_child
> raise child_exception_type(errno_num, err_msg)
> FileNotFoundError: [Errno 2] No such file or directory: 'cygpath -u 
> "C:\\Program Files\\Java\\jdk1.8.0_102"'
> {quote}
> giving [the doc|https://docs.python.org/3.4/library/subprocess.html] path and 
> args should be either supplied as array of terms or supplied as {{shell=True}}



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

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

Re: [VOTE] Release Lucene/Solr 6.3.0 RC2

[Michael McCandless]

OK I fixed LUCENE-7135 again.  Sorry :)

Mike McCandless

http://blog.mikemccandless.com


On Wed, Nov 2, 2016 at 6:44 AM, Michael McCandless
 wrote:
> ARGH.
>
> There is a bug in LUCENE-7135.  Hold please :)
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Wed, Nov 2, 2016 at 6:15 AM, Michael McCandless
>  wrote:
>> OK LUCENE-7501 is fixed now too!  I think you can spin the next RC Shalin?
>>
>> Thanks and sorry!
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>>
>> On Wed, Nov 2, 2016 at 4:57 AM, Michael McCandless
>>  wrote:
>>> Thanks Shalin, I backported it.
>>>
>>> Still working on LUCENE-7501...
>>>
>>> Mike McCandless
>>>
>>> http://blog.mikemccandless.com
>>>
>>>
>>> On Wed, Nov 2, 2016 at 4:39 AM, Shalin Shekhar Mangar
>>>  wrote:
 Please go ahead, Mike.

 On Wed, Nov 2, 2016 at 2:07 PM, Michael McCandless
  wrote:
> Hi Shalin,
>
> Since we must re-spin for LUCENE-7501 (I'm still working on that), is
> it OK if I backport LUCENE-7135 for 6.3.0?
>
> At least, I need to fix the CHANGES.txt entry if not.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Tue, Nov 1, 2016 at 5:19 PM, Michael McCandless
>  wrote:
>> I think there's possibly a bad problem with LUCENE-7501 (creates a
>> possibly corrupt index) ... I'm trying to dig more to be sure ...
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>> On Mon, Oct 31, 2016 at 2:28 PM, Shalin Shekhar Mangar
>>  wrote:
>>> Please vote for the second release candidate for Lucene/Solr 6.3.0
>>>
>>> The artifacts can be downloaded from:
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/
>>>
>>> You can run the smoke tester directly with this command:
>>> python3 -u dev-tools/scripts/smokeTestRelease.py
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/
>>>
>>> Smoke tester passed for me:
>>> SUCCESS! [0:35:05.847870]
>>>
>>> Here's my +1 to release.
>>>
>>> --
>>> Regards,
>>> Shalin Shekhar Mangar.
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>



 --
 Regards,
 Shalin Shekhar Mangar.

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


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

[jira] [Commented] (SOLR-9714) can not stop solr with $STOP_PORT

[JIRA]

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

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

It looks as if you have a requirement to configure what to use as stop port 
explicitly. 
However that is not a current documented feature of Apache Solr - have you read 
in any documentation that this should work?
Can you please convert this issue into a "New Feature" issue and rewrite the 
Summary and Description fields to reflect your business need?

> can not stop solr with $STOP_PORT
> -
>
> Key: SOLR-9714
> URL: https://issues.apache.org/jira/browse/SOLR-9714
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 5.5.3, 6.2.1
>Reporter: 胡晓东
> Attachments: SOLR-9714.patch
>
>
> start:
>export SOLR_PORT="8983"
>export STOP_PORT="8984"
>... ...
> and use command  '$SOLR_HOME/bin/solr start ' to start solr
> stop:
>   export SOLR_PORT="8983"
>   export STOP_PORT="8984"
>   ... ...
>   use command  '$SOLR_HOME/bin/solr stop'  will throw exception below
>Sending stop command to Solr running on port 8983 ... waiting 5 
> seconds to allow Jetty process 18791 to stop gracefully.
> + /usr/java/jdk/bin/java -jar /opt/ZDH/parcels/lib/solr/server/start.jar 
> STOP.PORT=7983 STOP.KEY=solrrocks --stop
> java.net.ConnectException: Connection refused
>   at java.net.PlainSocketImpl.socketConnect(Native Method)
>   at 
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
>   at 
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
>   at 
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
>   at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
>   at java.net.Socket.connect(Socket.java:579)
>   at java.net.Socket.connect(Socket.java:528)
>   at java.net.Socket.(Socket.java:425)
>   at java.net.Socket.(Socket.java:241)
>   at org.eclipse.jetty.start.Main.stop(Main.java:869)
>   at org.eclipse.jetty.start.Main.stop(Main.java:848)
>   at org.eclipse.jetty.start.Main.doStop(Main.java:839)
>   at org.eclipse.jetty.start.Main.start(Main.java:692)
>   at org.eclipse.jetty.start.Main.main(Main.java:112)



--
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-9636) Use javabin for /stream, /sql internode communication

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-9636:
--

Typically the way you improve performance is to get an understanding of the 
bottlenecks. Then you work on improving the throughput of the bottlenecks. Then 
something else becomes the bottleneck and you fix that. And you keep doing this 
until you get diminishing returns. 

If we're going undertake a large refactoring of the streaming infrastructure 
for performance reasons, then I'm going to insist that we take that approach.

> Use javabin for /stream, /sql internode communication
> -
>
> Key: SOLR-9636
> URL: https://issues.apache.org/jira/browse/SOLR-9636
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9636.patch
>
>
> currently it uses json, which is verbose and slow



--
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-9636) Use javabin for /stream, /sql internode communication

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-9636 at 11/2/16 9:21 PM:
---

Typically the way you improve performance is to get an understanding of the 
bottlenecks. Then you work on improving the throughput of the bottlenecks. Then 
something else becomes the bottleneck and you fix that. And you keep doing this 
until you get diminishing returns. 

If we're going to undertake a large refactoring of the streaming infrastructure 
for performance reasons, then I'm going to insist that we take that approach.


was (Author: joel.bernstein):
Typically the way you improve performance is to get an understanding of the 
bottlenecks. Then you work on improving the throughput of the bottlenecks. Then 
something else becomes the bottleneck and you fix that. And you keep doing this 
until you get diminishing returns. 

If we're going undertake a large refactoring of the streaming infrastructure 
for performance reasons, then I'm going to insist that we take that approach.

> Use javabin for /stream, /sql internode communication
> -
>
> Key: SOLR-9636
> URL: https://issues.apache.org/jira/browse/SOLR-9636
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9636.patch
>
>
> currently it uses json, which is verbose and slow



--
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-9712) Saner default for maxWarmingSearchers

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-9712:


What we *really* need is additional functionality :-)
A high maxWarmingSearchers is bad from a resource perspective, but good from an 
API perspective.
Conversely, maxWarmingSearchers=1 can cause spurious failures, requiring all 
clients that care if something is committed (presumably that's why they called 
commit) to implement a retry loop.

One needs a reliable "update this document and make it visible, and don't 
return until it is visible" in conjunction with "let's not warm more than one 
searcher at a time".

> Saner default for maxWarmingSearchers
> -
>
> Key: SOLR-9712
> URL: https://issues.apache.org/jira/browse/SOLR-9712
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Shalin Shekhar Mangar
> Fix For: master (7.0), 6.4
>
>
> As noted in SOLR-9710, the default for maxWarmingSearchers is 
> Integer.MAX_VALUE which is just crazy. Let's have a saner default. Today we 
> log a performance warning when the number of on deck searchers goes over 1. 
> What if we had the default as 1 that expert users can increase if needed?



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

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

[jira] [Reopened] (SOLR-9710) SpellCheckComponentTest (still) occasionally fails

[James Dyer (JIRA)]

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

James Dyer reopened SOLR-9710:
--

ok, clearly this was the wrong way to fix this, and I do not understand how the 
test harness works!  We have a couple of fresh failures as our test harness 
fails if we go beyond the # of allowed on-deck searchers.  What we want instead 
is for it to wait for the searcher to be available and then continue.  

I'll revert for now.  Can anyone tell me the correct way to fix this?

> SpellCheckComponentTest (still) occasionally fails
> --
>
> Key: SOLR-9710
> URL: https://issues.apache.org/jira/browse/SOLR-9710
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spellchecker
>Affects Versions: 6.2.1
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Fix For: 6.3
>
> Attachments: SOLR-9710.patch
>
>
> In December 2015, I addressed occasional, non-reproducable failures with the 
> Spellcheck Component tests.  These were failing with this warning:
> bq. PERFORMANCE WARNING: Overlapping onDeckSearchers=2
> ...and the test itself would run before the test data was committed, 
> resulting in failure.
> This problem is re-occurring and needs a better fix.



--
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-9710) SpellCheckComponentTest (still) occasionally fails

[ASF subversion and git services (JIRA)]

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

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

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

Revert "SOLR-9710: fix test bug"

This reverts commit be772dbd4851363edade0fa22587a986122d1ff3.


> SpellCheckComponentTest (still) occasionally fails
> --
>
> Key: SOLR-9710
> URL: https://issues.apache.org/jira/browse/SOLR-9710
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spellchecker
>Affects Versions: 6.2.1
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Fix For: 6.3
>
> Attachments: SOLR-9710.patch
>
>
> In December 2015, I addressed occasional, non-reproducable failures with the 
> Spellcheck Component tests.  These were failing with this warning:
> bq. PERFORMANCE WARNING: Overlapping onDeckSearchers=2
> ...and the test itself would run before the test data was committed, 
> resulting in failure.
> This problem is re-occurring and needs a better fix.



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

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

[JENKINS-EA] Lucene-Solr-6.3-Linux (32bit/jdk-9-ea+140) - Build # 13 - Unstable!

[Policeman Jenkins Server]

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

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

Error Message:
List size mismatch @ spellcheck/suggestions

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




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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/557/
Java: 32bit/jdk1.8.0_102 -client -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.solr.handler.admin.CoreAdminHandlerTest.testDeleteInstanceDirAfterCreateFailure

Error Message:
The data directory was not cleaned up on unload after a failed core reload

Stack Trace:
java.lang.AssertionError: The data directory was not cleaned up on unload after 
a failed core reload
at 
__randomizedtesting.SeedInfo.seed([6199A1CA55FEACAB:1A50038676DC7EAA]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.admin.CoreAdminHandlerTest.testDeleteInstanceDirAfterCreateFailure(CoreAdminHandlerTest.java:334)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 10822 lines...]
   [junit4] Suite: org.apache.solr.handler.admin.CoreAdminHandlerTest
   [junit4]   2> Creating dataDir: 

[jira] [Commented] (SOLR-9710) SpellCheckComponentTest (still) occasionally fails

[ASF subversion and git services (JIRA)]

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

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

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

Revert "SOLR-9710: fix test bug"

This reverts commit 16dc4be2631373e7dac58a31a9850d5cd1d89e2f.


> SpellCheckComponentTest (still) occasionally fails
> --
>
> Key: SOLR-9710
> URL: https://issues.apache.org/jira/browse/SOLR-9710
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spellchecker
>Affects Versions: 6.2.1
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Fix For: 6.3
>
> Attachments: SOLR-9710.patch
>
>
> In December 2015, I addressed occasional, non-reproducable failures with the 
> Spellcheck Component tests.  These were failing with this warning:
> bq. PERFORMANCE WARNING: Overlapping onDeckSearchers=2
> ...and the test itself would run before the test data was committed, 
> resulting in failure.
> This problem is re-occurring and needs a better fix.



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

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

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

[Policeman Jenkins Server]

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

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

Error Message:
document count mismatch.  control=2962 sum(shards)=2961 cloudClient=2961

Stack Trace:
java.lang.AssertionError: document count mismatch.  control=2962 
sum(shards)=2961 cloudClient=2961
at 
__randomizedtesting.SeedInfo.seed([C544271191AE264A:4D1018CB3F524BB2]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1323)
at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:231)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java: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:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[jira] [Commented] (SOLR-9636) Use javabin for /stream, /sql internode communication

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-9636:
--

I've spent too much of my life fixing the wrong thing for efficiency, I've got 
to agree with Joel here. Let's positively identify the bottleneck before 
proposing a solution. SOLR-486 does show roughly a doubling of binary output 
compared to JSON, my uncertainty is how much of that improvement is actually 
forming the response. An interesting measurement would be to just avoid 
assembling _anything_ for the output stream, just read the date from the 
docValues and throw it away. 

But even there it's iffy. My testing purposely threw the bits on the floor, so 
network transmission was completely out of the picture. Whether the end user 
would see measurable improvement is an open question.

Contrariwise, see https://issues.apache.org/jira/browse/SOLR-9296 where I was 
doing some experimenting with re-using things like char[] rather than 
allocating new strings all the time and saw up to an 11% improvement in 
throughput. Don't know whether the notion of going to a binary format would 
make that irrelevant that or not. I'll link the two issues anyway just so don't 
lose the association.

> Use javabin for /stream, /sql internode communication
> -
>
> Key: SOLR-9636
> URL: https://issues.apache.org/jira/browse/SOLR-9636
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9636.patch
>
>
> currently it uses json, which is verbose and slow



--
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-9636) Use javabin for /stream, /sql internode communication

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-9636:
--

How much of SOLR-9296 is made irrelevant by this JIRA (and vice-versa)?

> Use javabin for /stream, /sql internode communication
> -
>
> Key: SOLR-9636
> URL: https://issues.apache.org/jira/browse/SOLR-9636
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9636.patch
>
>
> currently it uses json, which is verbose and slow



--
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-3442) Example schema switch to DisMax instead of CopyField

[JIRA]

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

Jan Høydahl closed SOLR-3442.
-
Resolution: Later

Closing this due to initial pushback and there is now more than one example.

Probably the proper way to teach people the benefits of dismax is through a 
future new example/tutorial?

> Example schema switch to DisMax instead of CopyField
> 
>
> Key: SOLR-3442
> URL: https://issues.apache.org/jira/browse/SOLR-3442
> Project: Solr
>  Issue Type: Improvement
>  Components: Schema and Analysis
>Reporter: Jan Høydahl
>  Labels: dismax
>
> Spinoff from SOLR-3439:
> The use of copyField in todays example schema is an anti pattern since we 
> indirectly teach people to duplicate most of their content, while most would 
> be better off using DisMax, or at least a combination.



--
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-9714) can not stop solr with $STOP_PORT

[JIRA]

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

胡晓东 updated SOLR-9714:
--
Comment: was deleted

(was: But when I show help, it shows that this shuold work.
 (The specified port (SOLR_PORT) will also be used to determine the stop 
port)

[root@huxiaodong01 bin]# ./solr start -help

Usage: solr start [-f] [-c] [-h hostname] [-p port] [-d directory] [-z zkHost] 
[-m memory] [-e example] [-s solr.solr.home] [-a "additional-options"] [-V]

  -fStart Solr in foreground; default starts Solr in the background
  and sends stdout / stderr to solr-PORT-console.log

  -c or -cloud  Start Solr in SolrCloud mode; if -z not supplied, an embedded 
Zookeeper
  instance is started on Solr port+1000, such as 9983 if Solr 
is bound to 8983

  -h  Specify the hostname for this Solr instance

  -p  Specify the port to start the Solr HTTP listener on; default is 
8983
  *The specified port (SOLR_PORT) will also be used to 
determine the stop port*
  STOP_PORT=($SOLR_PORT-1000) and JMX RMI listen port 
RMI_PORT=(1$SOLR_PORT). 
  For instance, if you set -p 8985, then the STOP_PORT=7985 and 
RMI_PORT=18985
  .
)

> can not stop solr with $STOP_PORT
> -
>
> Key: SOLR-9714
> URL: https://issues.apache.org/jira/browse/SOLR-9714
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 5.5.3, 6.2.1
>Reporter: 胡晓东
> Attachments: SOLR-9714.patch
>
>
> start:
>export SOLR_PORT="8983"
>export STOP_PORT="8984"
>... ...
> and use command  '$SOLR_HOME/bin/solr start ' to start solr
> stop:
>   export SOLR_PORT="8983"
>   export STOP_PORT="8984"
>   ... ...
>   use command  '$SOLR_HOME/bin/solr stop'  will throw exception below
>Sending stop command to Solr running on port 8983 ... waiting 5 
> seconds to allow Jetty process 18791 to stop gracefully.
> + /usr/java/jdk/bin/java -jar /opt/ZDH/parcels/lib/solr/server/start.jar 
> STOP.PORT=7983 STOP.KEY=solrrocks --stop
> java.net.ConnectException: Connection refused
>   at java.net.PlainSocketImpl.socketConnect(Native Method)
>   at 
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
>   at 
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
>   at 
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
>   at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
>   at java.net.Socket.connect(Socket.java:579)
>   at java.net.Socket.connect(Socket.java:528)
>   at java.net.Socket.(Socket.java:425)
>   at java.net.Socket.(Socket.java:241)
>   at org.eclipse.jetty.start.Main.stop(Main.java:869)
>   at org.eclipse.jetty.start.Main.stop(Main.java:848)
>   at org.eclipse.jetty.start.Main.doStop(Main.java:839)
>   at org.eclipse.jetty.start.Main.start(Main.java:692)
>   at org.eclipse.jetty.start.Main.main(Main.java:112)



--
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-9709) move http://wiki.apache.org/solr/SolJSON ('JSON specific parameters' +) to Solr Ref Guide

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9709: add json.nl=map example comment, expand json.nl test coverage.


> move http://wiki.apache.org/solr/SolJSON ('JSON specific parameters' +) to 
> Solr Ref Guide
> -
>
> Key: SOLR-9709
> URL: https://issues.apache.org/jira/browse/SOLR-9709
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Response Writers
>Reporter: Christine Poerschke
>Priority: Minor
>
> Currently http://wiki.apache.org/solr/SolJSON#JSON_specific_parameters 
> documents
> * json.nl=flat
> * json.nl=map
> * json.nl=arrarr
> but choices
> * json.nl=arrmap
> * json.nl=arrnvp
> are not documented.
> This ticket is to document {{json.nl=arrnvp}} added by SOLR-9442 and also 
> {{json.nl=arrmap}} which already exists.
> link to relevant code: 
> [JSONResponseWriter.java#L85-L89|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/response/JSONResponseWriter.java#L85-L89]



--
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-7135) Constants check for JRE bitness causes SecurityException under WebStart

[ASF subversion and git services (JIRA)]

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

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

Commit 92f56ea9dd72d935c21aadae6a20ee23fa9c3cf8 in lucene-solr's branch 
refs/heads/apiv2 from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=92f56ea ]

LUCENE-7135: only use OS_ARCH if we couldn't access sun.arch.data.model


> Constants check for JRE bitness causes SecurityException under WebStart
> ---
>
> Key: LUCENE-7135
> URL: https://issues.apache.org/jira/browse/LUCENE-7135
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/other
>Affects Versions: 5.5
> Environment: OS X 10.11.4, Java 1.8.0_77-b03 (under WebStart)
>Reporter: Aaron Madlon-Kay
> Fix For: master (7.0), 6.3, 5.5.4
>
> Attachments: LUCENE-7135.diff
>
>
> I have an app that I deploy via WebStart that uses Lucene 5.2.1 (we are 
> locked to 5.2.1 because that's what [LanguageTool|https://languagetool.org/] 
> uses).
> When running under the WebStart security manager, there are two locations 
> where exceptions are thrown and prevent pretty much all Lucene classes from 
> initializing. This is true even when we sign everything and specify 
> {{}}.
> # In {{RamUsageEstimator}}, fixed by LUCENE-6923
> # In {{Constants}}, caused by the call 
> {{System.getProperty("sun.arch.data.model")}} (stack trace below).
> {code}
> Error: Caused by: java.security.AccessControlException: access denied 
> ("java.util.PropertyPermission" "sun.arch.data.model" "read") 
> Error:at 
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>  
> Error:at 
> java.security.AccessController.checkPermission(AccessController.java:884) 
> Error:at 
> java.lang.SecurityManager.checkPermission(SecurityManager.java:549) 
> Error:at 
> com.sun.javaws.security.JavaWebStartSecurity.checkPermission(Unknown Source) 
> Error:at 
> java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1294) 
> Error:at java.lang.System.getProperty(System.java:717) 
> Error:at org.apache.lucene.util.Constants.(Constants.java:71) 
> Error:... 34 more 
> {code}
> The latter is still present in the latest version. My patch illustrates one 
> solution that appears to be working for us.
> (This patch, together with a backport of the fix to LUCENE-6923, seems to fix 
> the issue for our purposes. However if you really wanted to make my day you 
> could put out a maintenance release of 5.2 with both fixes included.)



--
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-9710) SpellCheckComponentTest (still) occasionally fails

[ASF subversion and git services (JIRA)]

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

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

Commit be772dbd4851363edade0fa22587a986122d1ff3 in lucene-solr's branch 
refs/heads/apiv2 from jdyer1
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=be772db ]

SOLR-9710: fix test bug


> SpellCheckComponentTest (still) occasionally fails
> --
>
> Key: SOLR-9710
> URL: https://issues.apache.org/jira/browse/SOLR-9710
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spellchecker
>Affects Versions: 6.2.1
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Fix For: 6.3
>
> Attachments: SOLR-9710.patch
>
>
> In December 2015, I addressed occasional, non-reproducable failures with the 
> Spellcheck Component tests.  These were failing with this warning:
> bq. PERFORMANCE WARNING: Overlapping onDeckSearchers=2
> ...and the test itself would run before the test data was committed, 
> resulting in failure.
> This problem is re-occurring and needs a better fix.



--
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-9681) add filter to any facet

[ASF subversion and git services (JIRA)]

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

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

Commit 359f981b0e2737c3d019d0097e5be3bf76874407 in lucene-solr's branch 
refs/heads/apiv2 from [~yo...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=359f981 ]

SOLR-9681: move "filter" inside "domain" block


> add filter to any facet
> ---
>
> Key: SOLR-9681
> URL: https://issues.apache.org/jira/browse/SOLR-9681
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: master (7.0), 6.4
>
> Attachments: SOLR-9681.patch, SOLR-9681.patch
>
>
> For the JSON Facet API, we should be able to add a list of filters to any 
> facet.  These would be applied after any domain changes, hence useful for 
> parent->child mapping that would otherwise match all children of any parent 
> (SOLR-9510)
> The API should also be consistent with "filter" at the top level of the JSON 
> Request API (examples at http://yonik.com/solr-json-request-api/ )



--
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-7501) Do not encode the split dimension in the index in the 1D case

[ASF subversion and git services (JIRA)]

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

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

Commit 69e654b3737a97fea7ffc9f57c8fad5e85f72452 in lucene-solr's branch 
refs/heads/apiv2 from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=69e654b ]

LUCENE-7501: fix back-compat bug; add test


> Do not encode the split dimension in the index in the 1D case
> -
>
> Key: LUCENE-7501
> URL: https://issues.apache.org/jira/browse/LUCENE-7501
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Blocker
> Fix For: master (7.0), 6.3
>
> Attachments: LUCENE-7501.patch, LUCENE-7501.patch, LUCENE-7501.patch
>
>
> When there is a single dimension, the split dimension is always 0, so we do 
> not need to encode it in the index of the BKD tree. This would be 33% memory 
> saving for half floats, 20% for ints/floats, 11% for longs/doubles and 6% for 
> ip addresses.



--
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-8542) Integrate Learning to Rank into Solr

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8542: Add maven config and improve IntelliJ config.


> Integrate Learning to Rank into Solr
> 
>
> Key: SOLR-8542
> URL: https://issues.apache.org/jira/browse/SOLR-8542
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joshua Pantony
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8542-branch_5x.patch, SOLR-8542-trunk.patch, 
> SOLR-8542.patch
>
>
> This is a ticket to integrate learning to rank machine learning models into 
> Solr. Solr Learning to Rank (LTR) provides a way for you to extract features 
> directly inside Solr for use in training a machine learned model. You can 
> then deploy that model to Solr and use it to rerank your top X search 
> results. This concept was previously [presented by the authors at Lucene/Solr 
> Revolution 
> 2015|http://www.slideshare.net/lucidworks/learning-to-rank-in-solr-presented-by-michael-nilsson-diego-ceccarelli-bloomberg-lp].
> [Read through the 
> README|https://github.com/bloomberg/lucene-solr/tree/master-ltr-plugin-release/solr/contrib/ltr]
>  for a tutorial on using the plugin, in addition to how to train your own 
> external model.



--
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-9714) can not stop solr with $STOP_PORT

[JIRA]

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

胡晓东 updated SOLR-9714:
--
   Priority: Minor  (was: Major)
Description: Our system just has port planning,we have the requirement to 
configure what to use as stop port explicitly. but now I can configure the 
stop_port on the starting script, but can not use the port on the stopping 
script. I think the script has a little problem.  (was: start:
   export SOLR_PORT="8983"
   export STOP_PORT="8984"
   ... ...
and use command  '$SOLR_HOME/bin/solr start ' to start solr

stop:
  export SOLR_PORT="8983"
  export STOP_PORT="8984"
  ... ...
  use command  '$SOLR_HOME/bin/solr stop'  will throw exception below
   Sending stop command to Solr running on port 8983 ... waiting 5 seconds 
to allow Jetty process 18791 to stop gracefully.
+ /usr/java/jdk/bin/java -jar /opt/ZDH/parcels/lib/solr/server/start.jar 
STOP.PORT=7983 STOP.KEY=solrrocks --stop
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:579)
at java.net.Socket.connect(Socket.java:528)
at java.net.Socket.(Socket.java:425)
at java.net.Socket.(Socket.java:241)
at org.eclipse.jetty.start.Main.stop(Main.java:869)
at org.eclipse.jetty.start.Main.stop(Main.java:848)
at org.eclipse.jetty.start.Main.doStop(Main.java:839)
at org.eclipse.jetty.start.Main.start(Main.java:692)
at org.eclipse.jetty.start.Main.main(Main.java:112)
)
 Issue Type: New Feature  (was: Bug)

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



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

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

Re: [VOTE] - Release Lucene/Solr 6.3.0 RC3

[Steve Rowe]

+1

Smoke tester passed (lost the timing in a closed terminal window, it was 34 
minutes or so IIRC).

Changes, docs and javadocs look good.

--
Steve
www.lucidworks.com

> On Nov 2, 2016, at 3:35 PM, Tommaso Teofili  wrote:
> 
> SUCCESS! [1:54:38.816517]
> 
> +1
> 
> Tommaso
> 
> 
> Il giorno mer 2 nov 2016 alle ore 19:56 Jan Høydahl  
> ha scritto:
> SUCCESS! [1:05:53.149540] (macOS)
> +1
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
> 
>> 2. nov. 2016 kl. 17.34 skrev Shalin Shekhar Mangar :
>> 
>> Please vote for the third release candidate for Lucene/Solr 6.3.0
>> 
>> The artifacts can be downloaded from:
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC3-reva66a44513ee8191e25b477372094bfa846450316
>> 
>> You can run the smoke tester directly with this command:
>> python3 -u dev-tools/scripts/smokeTestRelease.py
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC3-reva66a44513ee8191e25b477372094bfa846450316
>> 
>> Smoke tester passed for me:
>> SUCCESS! [0:36:45.760510]
>> 
>> Here's my +1 to release.
>> 
>> -- 
>> Regards,
>> Shalin Shekhar Mangar.
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
> 


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

[jira] [Commented] (SOLR-9714) can not stop solr with $STOP_PORT

[JIRA]

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

胡晓东 commented on SOLR-9714:
---

But when I show help, it shows that this shuold work.
 (The specified port (SOLR_PORT) will also be used to determine the stop 
port)

[root@huxiaodong01 bin]# ./solr start -help

Usage: solr start [-f] [-c] [-h hostname] [-p port] [-d directory] [-z zkHost] 
[-m memory] [-e example] [-s solr.solr.home] [-a "additional-options"] [-V]

  -fStart Solr in foreground; default starts Solr in the background
  and sends stdout / stderr to solr-PORT-console.log

  -c or -cloud  Start Solr in SolrCloud mode; if -z not supplied, an embedded 
Zookeeper
  instance is started on Solr port+1000, such as 9983 if Solr 
is bound to 8983

  -h  Specify the hostname for this Solr instance

  -p  Specify the port to start the Solr HTTP listener on; default is 
8983
  The specified port (SOLR_PORT) will also be used to determine 
the stop port
  STOP_PORT=($SOLR_PORT-1000) and JMX RMI listen port 
RMI_PORT=(1$SOLR_PORT). 
  For instance, if you set -p 8985, then the STOP_PORT=7985 and 
RMI_PORT=18985
  .


> can not stop solr with $STOP_PORT
> -
>
> Key: SOLR-9714
> URL: https://issues.apache.org/jira/browse/SOLR-9714
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 5.5.3, 6.2.1
>Reporter: 胡晓东
> Attachments: SOLR-9714.patch
>
>
> start:
>export SOLR_PORT="8983"
>export STOP_PORT="8984"
>... ...
> and use command  '$SOLR_HOME/bin/solr start ' to start solr
> stop:
>   export SOLR_PORT="8983"
>   export STOP_PORT="8984"
>   ... ...
>   use command  '$SOLR_HOME/bin/solr stop'  will throw exception below
>Sending stop command to Solr running on port 8983 ... waiting 5 
> seconds to allow Jetty process 18791 to stop gracefully.
> + /usr/java/jdk/bin/java -jar /opt/ZDH/parcels/lib/solr/server/start.jar 
> STOP.PORT=7983 STOP.KEY=solrrocks --stop
> java.net.ConnectException: Connection refused
>   at java.net.PlainSocketImpl.socketConnect(Native Method)
>   at 
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
>   at 
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
>   at 
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
>   at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
>   at java.net.Socket.connect(Socket.java:579)
>   at java.net.Socket.connect(Socket.java:528)
>   at java.net.Socket.(Socket.java:425)
>   at java.net.Socket.(Socket.java:241)
>   at org.eclipse.jetty.start.Main.stop(Main.java:869)
>   at org.eclipse.jetty.start.Main.stop(Main.java:848)
>   at org.eclipse.jetty.start.Main.doStop(Main.java:839)
>   at org.eclipse.jetty.start.Main.start(Main.java:692)
>   at org.eclipse.jetty.start.Main.main(Main.java:112)



--
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-9714) can not stop solr with $STOP_PORT

[JIRA]

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

胡晓东 edited comment on SOLR-9714 at 11/3/16 12:40 AM:
-

But when I show help, it shows that this shuold work.
 (The specified port (SOLR_PORT) will also be used to determine the stop 
port)

[root@huxiaodong01 bin]# ./solr start -help

Usage: solr start [-f] [-c] [-h hostname] [-p port] [-d directory] [-z zkHost] 
[-m memory] [-e example] [-s solr.solr.home] [-a "additional-options"] [-V]

  -fStart Solr in foreground; default starts Solr in the background
  and sends stdout / stderr to solr-PORT-console.log

  -c or -cloud  Start Solr in SolrCloud mode; if -z not supplied, an embedded 
Zookeeper
  instance is started on Solr port+1000, such as 9983 if Solr 
is bound to 8983

  -h  Specify the hostname for this Solr instance

  -p  Specify the port to start the Solr HTTP listener on; default is 
8983
  *The specified port (SOLR_PORT) will also be used to 
determine the stop port*
  STOP_PORT=($SOLR_PORT-1000) and JMX RMI listen port 
RMI_PORT=(1$SOLR_PORT). 
  For instance, if you set -p 8985, then the STOP_PORT=7985 and 
RMI_PORT=18985
  .



was (Author: xiaodong.hu):
But when I show help, it shows that this shuold work.
 (The specified port (SOLR_PORT) will also be used to determine the stop 
port)

[root@huxiaodong01 bin]# ./solr start -help

Usage: solr start [-f] [-c] [-h hostname] [-p port] [-d directory] [-z zkHost] 
[-m memory] [-e example] [-s solr.solr.home] [-a "additional-options"] [-V]

  -fStart Solr in foreground; default starts Solr in the background
  and sends stdout / stderr to solr-PORT-console.log

  -c or -cloud  Start Solr in SolrCloud mode; if -z not supplied, an embedded 
Zookeeper
  instance is started on Solr port+1000, such as 9983 if Solr 
is bound to 8983

  -h  Specify the hostname for this Solr instance

  -p  Specify the port to start the Solr HTTP listener on; default is 
8983
  The specified port (SOLR_PORT) will also be used to determine 
the stop port
  STOP_PORT=($SOLR_PORT-1000) and JMX RMI listen port 
RMI_PORT=(1$SOLR_PORT). 
  For instance, if you set -p 8985, then the STOP_PORT=7985 and 
RMI_PORT=18985
  .


> can not stop solr with $STOP_PORT
> -
>
> Key: SOLR-9714
> URL: https://issues.apache.org/jira/browse/SOLR-9714
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 5.5.3, 6.2.1
>Reporter: 胡晓东
> Attachments: SOLR-9714.patch
>
>
> start:
>export SOLR_PORT="8983"
>export STOP_PORT="8984"
>... ...
> and use command  '$SOLR_HOME/bin/solr start ' to start solr
> stop:
>   export SOLR_PORT="8983"
>   export STOP_PORT="8984"
>   ... ...
>   use command  '$SOLR_HOME/bin/solr stop'  will throw exception below
>Sending stop command to Solr running on port 8983 ... waiting 5 
> seconds to allow Jetty process 18791 to stop gracefully.
> + /usr/java/jdk/bin/java -jar /opt/ZDH/parcels/lib/solr/server/start.jar 
> STOP.PORT=7983 STOP.KEY=solrrocks --stop
> java.net.ConnectException: Connection refused
>   at java.net.PlainSocketImpl.socketConnect(Native Method)
>   at 
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
>   at 
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
>   at 
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
>   at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
>   at java.net.Socket.connect(Socket.java:579)
>   at java.net.Socket.connect(Socket.java:528)
>   at java.net.Socket.(Socket.java:425)
>   at java.net.Socket.(Socket.java:241)
>   at org.eclipse.jetty.start.Main.stop(Main.java:869)
>   at org.eclipse.jetty.start.Main.stop(Main.java:848)
>   at org.eclipse.jetty.start.Main.doStop(Main.java:839)
>   at org.eclipse.jetty.start.Main.start(Main.java:692)
>   at org.eclipse.jetty.start.Main.main(Main.java:112)



--
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-9720) Refactor responsewriter to remove dependencies on TupleStream etc

[Noble Paul (JIRA)]

Noble Paul created SOLR-9720:


 Summary: Refactor responsewriter to remove dependencies on 
TupleStream etc
 Key: SOLR-9720
 URL: https://issues.apache.org/jira/browse/SOLR-9720
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Noble Paul
Assignee: Noble Paul


ResponseWriters are designed to be agnostic of components and they should work 
with the well know set of types we already support



--
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-9721) Create a javabin writer/reader for streaming end point

[Noble Paul (JIRA)]

Noble Paul created SOLR-9721:


 Summary: Create a javabin writer/reader for streaming end point
 Key: SOLR-9721
 URL: https://issues.apache.org/jira/browse/SOLR-9721
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Noble Paul






--
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-9636) Use javabin for /stream, /sql internode communication

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-9636:
--

bq.I've spent too much of my life fixing the wrong thing for efficiency, I've 
got to agree with Joel here. 

Solr has a modular design where we pick and choose components (wt param here). 
These are done to ensure that everything works with each other. In case of 
Streaming it is not there. That introduces too many dependencies on each 
component.

I strongly recommend everyone to take a look at the patch because it may not be 
doing what you think it is doing

> Use javabin for /stream, /sql internode communication
> -
>
> Key: SOLR-9636
> URL: https://issues.apache.org/jira/browse/SOLR-9636
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9636.patch
>
>
> currently it uses json, which is verbose and slow



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

[Policeman Jenkins Server]

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

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

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

Stack Trace:
java.lang.AssertionError: expected:<200> but was:<404>
at 
__randomizedtesting.SeedInfo.seed([76A2FE244E3FE96:6FD51AC89479EC7A]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.cancelDelegationToken(TestSolrCloudWithDelegationTokens.java:140)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail(TestSolrCloudWithDelegationTokens.java:304)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Updated] (SOLR-9720) Refactor responsewriter to remove dependencies on TupleStream etc

[Noble Paul (JIRA)]

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

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

not final but gives an idea

> Refactor responsewriter to remove dependencies on TupleStream etc
> -
>
> Key: SOLR-9720
> URL: https://issues.apache.org/jira/browse/SOLR-9720
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9720.patch
>
>
> ResponseWriters are designed to be agnostic of components and they should 
> work with the well know set of types we already support



--
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-9636) Use javabin for /stream, /sql internode communication

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-9636:
--

Ok, let's do this work and it's sub-tasks in a branch. And let's get consensus 
before it hit's master.


> Use javabin for /stream, /sql internode communication
> -
>
> Key: SOLR-9636
> URL: https://issues.apache.org/jira/browse/SOLR-9636
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9636.patch
>
>
> currently it uses json, which is verbose and slow



--
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_102) - Build # 2098 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2098/
Java: 32bit/jdk1.8.0_102 -server -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.lucene.util.TestPagedBytes.testDataInputOutput2

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([31D9F38942A7A39D:BF18FD0F12366D5D]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.lucene.util.TestPagedBytes.testDataInputOutput2(TestPagedBytes.java:136)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.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:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
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 1065 lines...]
   [junit4] Suite: org.apache.lucene.util.TestPagedBytes
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestPagedBytes 
-Dtests.method=testDataInputOutput2 -Dtests.seed=31D9F38942A7A39D 
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=ar-IQ 
-Dtests.timezone=Pacific/Auckland -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] FAILURE 2.27s J0 | TestPagedBytes.testDataInputOutput2 <<<
   [junit4]> Throwable #1: java.lang.AssertionError
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([31D9F38942A7A39D:BF18FD0F12366D5D]:0)
   [junit4]>at 

[jira] [Commented] (SOLR-9636) Use javabin for /stream, /sql internode communication

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-9636:
--

I've created sub tasks . The refactorings (SOLR-9720)  are long overdue. Let's 
move the discussion to their own sub issues

> Use javabin for /stream, /sql internode communication
> -
>
> Key: SOLR-9636
> URL: https://issues.apache.org/jira/browse/SOLR-9636
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9636.patch
>
>
> currently it uses json, which is verbose and slow



--
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-9718) All JUnits of Streaming use java assert to compare double should use assertEquals()

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-9718:
-
Description: get rid of java {{assert}} altogether. it does not give any 
messages if there are any failures

> All JUnits of Streaming use java assert to compare double should use 
> assertEquals()
> ---
>
> Key: SOLR-9718
> URL: https://issues.apache.org/jira/browse/SOLR-9718
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>
> get rid of java {{assert}} altogether. it does not give any messages if there 
> are any failures



--
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-9720) Refactor responsewriter to remove dependencies on TupleStream etc

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-9720:
--

This is quite nice:

{code}
+  public Map toMap(Map map) {
+try {
+  if (!isOpen) {
+open();
+isOpen = true;
+  }
+} catch (IOException e) {
+  throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, e);
+}
+return Collections.singletonMap("docs", new Iterator() {
+  Tuple tuple;
+  boolean isEOF = false;
+
+  @Override
+  public boolean hasNext() {
+if (isEOF) return false;
+if (tuple != null) return true;
+try {
+  tuple = read();
+  if(tuple != null && tuple.EOF) close();
+  return tuple != null;
+} catch (IOException e) {
+  throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, e);
+}
+  }
+
+  @Override
+  public Tuple next() {
+Tuple tmp = tuple;
+tuple = null;
+isEOF = tmp == null || tmp.EOF;
+return tmp;
+  }
+});
   }
{code}

> Refactor responsewriter to remove dependencies on TupleStream etc
> -
>
> Key: SOLR-9720
> URL: https://issues.apache.org/jira/browse/SOLR-9720
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9720.patch
>
>
> ResponseWriters are designed to be agnostic of components and they should 
> work with the well know set of types we already support



--
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-9712) Saner default for maxWarmingSearchers

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9712:


+1 Yonik.  I've long felt that a commit should block instead of execute 
concurrently, possibly failing.  It's kinda crazy this hasn't been done yet. 
It's a real gotcha for users who don't know better.

> Saner default for maxWarmingSearchers
> -
>
> Key: SOLR-9712
> URL: https://issues.apache.org/jira/browse/SOLR-9712
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Shalin Shekhar Mangar
> Fix For: master (7.0), 6.4
>
>
> As noted in SOLR-9710, the default for maxWarmingSearchers is 
> Integer.MAX_VALUE which is just crazy. Let's have a saner default. Today we 
> log a performance warning when the number of on deck searchers goes over 1. 
> What if we had the default as 1 that expert users can increase if needed?



--
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-9720) Refactor responsewriter to remove dependencies on TupleStream etc

[Noble Paul (JIRA)]

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

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

> Refactor responsewriter to remove dependencies on TupleStream etc
> -
>
> Key: SOLR-9720
> URL: https://issues.apache.org/jira/browse/SOLR-9720
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9720.patch, SOLR-9720.patch
>
>
> ResponseWriters are designed to be agnostic of components and they should 
> work with the well know set of types we already support



--
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-9720) Refactor responsewriter to remove dependencies on TupleStream etc

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-9720:
-
Attachment: (was: SOLR-9720.patch)

> Refactor responsewriter to remove dependencies on TupleStream etc
> -
>
> Key: SOLR-9720
> URL: https://issues.apache.org/jira/browse/SOLR-9720
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9720.patch
>
>
> ResponseWriters are designed to be agnostic of components and they should 
> work with the well know set of types we already support



--
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-9720) Refactor responsewriter to remove dependencies on TupleStream etc

[Noble Paul (JIRA)]

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

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

remove special handling for {{Explanation}} as well

> Refactor responsewriter to remove dependencies on TupleStream etc
> -
>
> Key: SOLR-9720
> URL: https://issues.apache.org/jira/browse/SOLR-9720
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9720.patch, SOLR-9720.patch
>
>
> ResponseWriters are designed to be agnostic of components and they should 
> work with the well know set of types we already support



--
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-9720) Refactor responsewriter to remove dependencies on TupleStream etc

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-9720:
--

I hope this is not controversial in any way. If all tests pass I plan to commit 
this

> Refactor responsewriter to remove dependencies on TupleStream etc
> -
>
> Key: SOLR-9720
> URL: https://issues.apache.org/jira/browse/SOLR-9720
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9720.patch, SOLR-9720.patch
>
>
> ResponseWriters are designed to be agnostic of components and they should 
> work with the well know set of types we already support



--
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-9714) can not stop solr with $STOP_PORT

[JIRA]

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

胡晓东 updated SOLR-9714:
--
Description: Our system just has port planning,we have the requirement to 
configure what to use as stop port explicitly. but now I can configure the 
stop_port on the starting script($SOLR_HOME/bin/solr), but can not use the port 
to stop solr gracefully. I think the script has a little problem.  (was: Our 
system just has port planning,we have the requirement to configure what to use 
as stop port explicitly. but now I can configure the stop_port on the starting 
script($SOLR_HOME/bin/solr), but can not use the port on the stopping script. I 
think the script has a little problem.)

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



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

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

[jira] [Updated] (SOLR-9714) can not stop solr with $STOP_PORT

[JIRA]

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

胡晓东 updated SOLR-9714:
--
Description: Our system just has port planning,we have the requirement to 
configure what to use as stop port explicitly. but now I can configure the 
stop_port on the starting script($SOLR_HOME/bin/solr), but can not use the port 
on the stopping script. I think the script has a little problem.  (was: Our 
system just has port planning,we have the requirement to configure what to use 
as stop port explicitly. but now I can configure the stop_port on the starting 
script, but can not use the port on the stopping script. I think the script has 
a little problem.)

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



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

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

[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 192 - Still Unstable

[Apache Jenkins Server]

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

5 tests failed.
FAILED:  org.apache.solr.cloud.SharedFSAutoReplicaFailoverTest.test

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([150B8ABDB6F96C42:9D5FB567180501BA]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.solr.cloud.SharedFSAutoReplicaFailoverTest.testBasics(SharedFSAutoReplicaFailoverTest.java:199)
at 
org.apache.solr.cloud.SharedFSAutoReplicaFailoverTest.test(SharedFSAutoReplicaFailoverTest.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Updated] (SOLR-9716) RecoveryStrategy send prep recovery cmd without setting request time out

[Cao Manh Dat (JIRA)]

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

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

Initial solution for this issue without tests. This patch is tested on 
solr-jepsen (https://github.com/LucidWorks/jepsen/tree/solr-jepsen) and passed.

This is a critical issue, it can cause a replica being down forever so I think 
we can commit this patch first and create another issue for creating an unit 
test for this ticket.

> RecoveryStrategy send prep recovery cmd without setting request time out
> 
>
> Key: SOLR-9716
> URL: https://issues.apache.org/jira/browse/SOLR-9716
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
> Attachments: SOLR-9716.patch
>
>
> Currently, RecoveryStrategy sends prep recovery cmd without setting request 
> time out. But this can be long running request, so if we have network 
> partition in the middle of the request. Recovering core will stay down 
> forever.



--
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-9609) Change hard-coded keysize from 512 to 1024

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-9609:
-
Attachment: SOLR-9609.patch

So here's a first cut at what it would take to move this to security.json (hey, 
it compiles, but it's _completely_ untested).

The reason I'm putting this up is that putting this value in security.json 
starts to get...messy and I'm wondering if the elegance of putting this in 
security.json outweighs the messiness.

The basic problem is that CryptoKeys doesn't have access to SecurityConfig. So 
we can either pass CoreContainer down to CryptoKeys (yck, talk about 
architectural badness) or have CryptoKeys take a length for this buffer. 

The second option requires that the caller get the new value from the 
SecurityConfig object if it's different than the default and pass that in to 
the c'tor. Which I made the PKIAuthenticationPlugin do.

Unless we make the default CryptoKeys c'tor private, any new classes using 
CryptoKeys has to remember to get the value from security.json which could be 
forgotten. I suppose we can just deprecate the default c'tor and then caveat 
emptor. My guess is that just making the default c'tor private is unacceptable 
as it breaks back-compat.

All this to allow different buffer lengths to be chosen. So is it really worth 
it? It seems we have several options:
1> go ahead and put it in security.json because it's the right thing to do.
2> allow it to be configurable with a sysvar, which is much easier.
3> hard code it to some future-friendly value like 4096. This assumes that 
having a value larger than necessary is OK.

Or am I missing some way to get around this mess?

P.S. there's a nocommit in there (should we really have a main method in 
CryptoKeys?) and I'll take out a change in the PKI test unless we deprecate the 
default c'tor in CryptoKeys if we decide to put this in security.json after all.



> Change hard-coded keysize from 512 to 1024
> --
>
> Key: SOLR-9609
> URL: https://issues.apache.org/jira/browse/SOLR-9609
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Jeremy Martini
>Assignee: Erick Erickson
> Attachments: SOLR-9609.patch, SOLR-9609.patch, SOLR-9609.patch, 
> solr.log
>
>
> In order to configure our dataSource without requiring a plaintext password 
> in the configuration file, we extended JdbcDataSource to create our own 
> custom implementation. Our dataSource config now looks something like this:
> {code:xml}
>  url="jdbc:oracle:thin:@db-host-machine:1521:tst1" user="testuser" 
> password="{ENC}{1.1}1ePOfWcbOIU056gKiLTrLw=="/>
> {code}
> We are using the RSA JSAFE Crypto-J libraries for encrypting/decrypting the 
> password. However, this seems to cause an issue when we try use Solr in a 
> Cloud Configuration (using Zookeeper). The error is "Strong key gen and 
> multiprime gen require at least 1024-bit keysize." Full log attached.
> This seems to be due to the hard-coded value of 512 in the 
> org.apache.solr.util.CryptoKeys$RSAKeyPair class:
> {code:java}
> public RSAKeyPair() {
>   KeyPairGenerator keyGen = null;
>   try {
> keyGen = KeyPairGenerator.getInstance("RSA");
>   } catch (NoSuchAlgorithmException e) {
> throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, e);
>   }
>   keyGen.initialize(512);
> {code}
> I pulled down the Solr code, changed the hard-coded value to 1024, rebuilt 
> it, and now everything seems to work great.



--
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-9636) Use javabin for /stream, /sql internode communication

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-9636:
--

bq.If we're going to undertake a large refactoring of the streaming 
infrastructure for performance reasons, then I'm going to insist that we take 
that approach.

I'm not touching any of the streaming code for this. The rafactoring was done 
to cleanup the unnecessary dependencies it introduced un ResponseWriters etc. I 
am going to split the ticket further. the refactoring is unavoidable. 

> Use javabin for /stream, /sql internode communication
> -
>
> Key: SOLR-9636
> URL: https://issues.apache.org/jira/browse/SOLR-9636
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9636.patch
>
>
> currently it uses json, which is verbose and slow



--
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-7526) Improvements to UnifiedHighlighter OffsetStrategies

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LUCENE-7526:


Github user dsmiley commented on the issue:

https://github.com/apache/lucene-solr/pull/105
  
_(I wrote this as you made your last comments, but rather than delete it 
I'll comment any way)_

The documentation for `PostingsEnum.nextPosition()` states that calling it 
more than `freq()` times is undefined.  Thus it's quite valid to throw an 
IllegalStateException.

> Btw, we've seen other needs for something like a CompositePostingsEnum 
that abstracts over a set of terms, but since this is still internal, dropping 
the house-keeping will also make this code do less. 

I don't think I quite get what you're saying.  By "other needs" do you mean 
Bloomberg internally?  If so, how would that relate this this one inside the 
UH?  Are you advocating a general purpose Multi-PosrtingsEnum?  On the 
latter... a highlighter wouldn't be where to introduce such a thing.  There is 
a `org.apache.lucene.index.MultiPostingsEnum` which I looked at while at the 
Lucene hackday code sprint as it got my curiosity.  Unfortunately, it doesn't 
seem quite general purpose enough for us to use -- it demands a MultiTermsEnum 
parent.  Perhaps that could be improved to be useful without demanding a 
MultiTermsEnum parent... but that seems like a separate issue.


> Improvements to UnifiedHighlighter OffsetStrategies
> ---
>
> Key: LUCENE-7526
> URL: https://issues.apache.org/jira/browse/LUCENE-7526
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Reporter: Timothy M. Rodriguez
>Assignee: David Smiley
>Priority: Minor
> Fix For: 6.4
>
>
> This ticket improves several of the UnifiedHighlighter FieldOffsetStrategies 
> by reducing reliance on creating or re-creating TokenStreams.
> The primary changes are as follows:
> * AnalysisOffsetStrategy - split into two offset strategies
>   ** MemoryIndexOffsetStrategy - the primary analysis mode that utilizes a 
> MemoryIndex for producing Offsets
>   ** TokenStreamOffsetStrategy - an offset strategy that avoids creating a 
> MemoryIndex.  Can only be used if the query distills down to terms and 
> automata.
> * TokenStream removal 
>   ** MemoryIndexOffsetStrategy - previously a TokenStream was created to fill 
> the memory index and then once consumed a new one was generated by 
> uninverting the MemoryIndex back into a TokenStream if there were automata 
> (wildcard/mtq queries) involved.  Now this is avoided, which should save 
> memory and avoid a second pass over the data.
>   ** TermVectorOffsetStrategy - this was refactored in a similar way to avoid 
> generating a TokenStream if automata are involved.
>   ** PostingsWithTermVectorsOffsetStrategy - similar refactoring
> * CompositePostingsEnum - aggregates several underlying PostingsEnums for 
> wildcard/mtq queries.  This should improve relevancy by providing unified 
> metrics for a wildcard across all it's term matches
> * Added a HighlightFlag for enabling the newly separated 
> TokenStreamOffsetStrategy since it can adversely affect passage relevancy



--
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-7135) Constants check for JRE bitness causes SecurityException under WebStart

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7135:


One nice side effect of this 2 day accident was it caused e.g. our nightly geo 
benchmark https://people.apache.org/~mikemccand/geobench.html to use 
{{NIOFSDirectory}} instead of {{MMapDirectory}}, so we get to see at least for 
this benchmark how much better {{MMapDirectory}} is!

I'm working on nightly benchmarks for the sparse case, preview here: 
https://people.apache.org/~mikemccand/lucenebench/sparseResults.html#search_sort_qps

There's an even bigger drop in that benchmark, which is what made me think 
there might be an issue with this change in the first place.  Benchmarking is 
important :)

> Constants check for JRE bitness causes SecurityException under WebStart
> ---
>
> Key: LUCENE-7135
> URL: https://issues.apache.org/jira/browse/LUCENE-7135
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/other
>Affects Versions: 5.5
> Environment: OS X 10.11.4, Java 1.8.0_77-b03 (under WebStart)
>Reporter: Aaron Madlon-Kay
> Fix For: master (7.0), 6.3, 5.5.4
>
> Attachments: LUCENE-7135.diff
>
>
> I have an app that I deploy via WebStart that uses Lucene 5.2.1 (we are 
> locked to 5.2.1 because that's what [LanguageTool|https://languagetool.org/] 
> uses).
> When running under the WebStart security manager, there are two locations 
> where exceptions are thrown and prevent pretty much all Lucene classes from 
> initializing. This is true even when we sign everything and specify 
> {{}}.
> # In {{RamUsageEstimator}}, fixed by LUCENE-6923
> # In {{Constants}}, caused by the call 
> {{System.getProperty("sun.arch.data.model")}} (stack trace below).
> {code}
> Error: Caused by: java.security.AccessControlException: access denied 
> ("java.util.PropertyPermission" "sun.arch.data.model" "read") 
> Error:at 
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>  
> Error:at 
> java.security.AccessController.checkPermission(AccessController.java:884) 
> Error:at 
> java.lang.SecurityManager.checkPermission(SecurityManager.java:549) 
> Error:at 
> com.sun.javaws.security.JavaWebStartSecurity.checkPermission(Unknown Source) 
> Error:at 
> java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1294) 
> Error:at java.lang.System.getProperty(System.java:717) 
> Error:at org.apache.lucene.util.Constants.(Constants.java:71) 
> Error:... 34 more 
> {code}
> The latter is still present in the latest version. My patch illustrates one 
> solution that appears to be working for us.
> (This patch, together with a backport of the fix to LUCENE-6923, seems to fix 
> the issue for our purposes. However if you really wanted to make my day you 
> could put out a maintenance release of 5.2 with both fixes included.)



--
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-7534) smokeTestRelease.py on cygwin [Errno 2] No such file or directory:

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on LUCENE-7534:
--

one more problem 
{code}
confirmAllReleasesAreTestedForBackCompat()
 stdout = stdout.decode('utf-8')
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xcf in position 17636: 
invalid continuation byte
{code}
passing {{,errors='ignore'}} seems fixes the problem.
  

> smokeTestRelease.py on cygwin [Errno 2] No such file or directory: 
> ---
>
> Key: LUCENE-7534
> URL: https://issues.apache.org/jira/browse/LUCENE-7534
> Project: Lucene - Core
>  Issue Type: Bug
> Environment: Windows, Cygwin, Python
>Reporter: Mikhail Khludnev
> Attachments: LUCENE-7534.patch
>
>
> {quote}
> $ python3 -u dev-tools/scripts/smokeTestRelease.py 
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/
> Revision: 1fe1a54db32b8c27bfae81887cd4d75242090613
> Java 1.8 JAVA_HOME=C:\Program Files\Java\jdk1.8.0_102
> Traceback (most recent call last):
>   File "dev-tools/scripts/smokeTestRelease.py", line 1440, in 
> main()
>   File "dev-tools/scripts/smokeTestRelease.py", line 1377, in main
> c = parse_config()
>   File "dev-tools/scripts/smokeTestRelease.py", line 1239, in parse_config
> c.java = make_java_config(parser, c.test_java8)
>   File "dev-tools/scripts/smokeTestRelease.py", line 1193, in make_java_config
> run_java8 = _make_runner(java8_home, '1.8')
>   File "dev-tools/scripts/smokeTestRelease.py", line 1179, in _make_runner
> java_home = subprocess.check_output('cygpath -u "%s"' % 
> java_home).read().decode('utf-8').strip()
>   File "/usr/lib/python3.4/subprocess.py", line 607, in check_output
> with Popen(*popenargs, stdout=PIPE, **kwargs) as process:
>   File "/usr/lib/python3.4/subprocess.py", line 859, in __init__
> restore_signals, start_new_session)
>   File "/usr/lib/python3.4/subprocess.py", line 1457, in _execute_child
> raise child_exception_type(errno_num, err_msg)
> FileNotFoundError: [Errno 2] No such file or directory: 'cygpath -u 
> "C:\\Program Files\\Java\\jdk1.8.0_102"'
> {quote}
> giving [the doc|https://docs.python.org/3.4/library/subprocess.html] path and 
> args should be either supplied as array of terms or supplied as {{shell=True}}



--
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-9481) BasicAuthPlugin should support standalone mode

[JIRA]

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

Jan Høydahl updated SOLR-9481:
--
Attachment: SOLR-9481-6x.patch

Attaching backport patch for 6x.
* The simple recipe above tested on macOS
* The 6.x version of {{HttpClientUtil}} did not have the 
{{clearRequestInterceptors()}} method, so I backported that as well.
* Passes precommit

Instead of cherry-picking 6 commits and then adding another commit for fixing 
6x specific issues, I'll squash all of this into one commit on branch_6x and 
instead list all related master commit hashes in the log.



> BasicAuthPlugin should support standalone mode
> --
>
> Key: SOLR-9481
> URL: https://issues.apache.org/jira/browse/SOLR-9481
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>  Labels: authentication
> Fix For: master (7.0), 6.4
>
> Attachments: SOLR-9481-6x.patch, SOLR-9481.patch, SOLR-9481.patch
>
>
> The BasicAuthPlugin currently only supports SolrCloud, and reads users and 
> credentials from ZK /security.json
> Add support for standalone mode operation



--
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 #105: LUCENE-7526 Improvements to UnifiedHighlighter Offse...

[Timothy055]

Github user Timothy055 commented on the issue:

https://github.com/apache/lucene-solr/pull/105
  
Merged your commit.


---
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-9709) move http://wiki.apache.org/solr/SolJSON ('JSON specific parameters' +) to Solr Ref Guide

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9709: add json.nl=map example comment, expand json.nl test coverage.


> move http://wiki.apache.org/solr/SolJSON ('JSON specific parameters' +) to 
> Solr Ref Guide
> -
>
> Key: SOLR-9709
> URL: https://issues.apache.org/jira/browse/SOLR-9709
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Response Writers
>Reporter: Christine Poerschke
>Priority: Minor
>
> Currently http://wiki.apache.org/solr/SolJSON#JSON_specific_parameters 
> documents
> * json.nl=flat
> * json.nl=map
> * json.nl=arrarr
> but choices
> * json.nl=arrmap
> * json.nl=arrnvp
> are not documented.
> This ticket is to document {{json.nl=arrnvp}} added by SOLR-9442 and also 
> {{json.nl=arrmap}} which already exists.
> link to relevant code: 
> [JSONResponseWriter.java#L85-L89|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/response/JSONResponseWriter.java#L85-L89]



--
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-7526) Improvements to UnifiedHighlighter OffsetStrategies

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LUCENE-7526:


Github user Timothy055 commented on the issue:

https://github.com/apache/lucene-solr/pull/105
  
Forget it, you can't do that because the next position on one enum might be 
-1, but there's more enums left in the queue so the user of this class could 
inadvertently terminate early if looking for -1.


> Improvements to UnifiedHighlighter OffsetStrategies
> ---
>
> Key: LUCENE-7526
> URL: https://issues.apache.org/jira/browse/LUCENE-7526
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Reporter: Timothy M. Rodriguez
>Assignee: David Smiley
>Priority: Minor
> Fix For: 6.4
>
>
> This ticket improves several of the UnifiedHighlighter FieldOffsetStrategies 
> by reducing reliance on creating or re-creating TokenStreams.
> The primary changes are as follows:
> * AnalysisOffsetStrategy - split into two offset strategies
>   ** MemoryIndexOffsetStrategy - the primary analysis mode that utilizes a 
> MemoryIndex for producing Offsets
>   ** TokenStreamOffsetStrategy - an offset strategy that avoids creating a 
> MemoryIndex.  Can only be used if the query distills down to terms and 
> automata.
> * TokenStream removal 
>   ** MemoryIndexOffsetStrategy - previously a TokenStream was created to fill 
> the memory index and then once consumed a new one was generated by 
> uninverting the MemoryIndex back into a TokenStream if there were automata 
> (wildcard/mtq queries) involved.  Now this is avoided, which should save 
> memory and avoid a second pass over the data.
>   ** TermVectorOffsetStrategy - this was refactored in a similar way to avoid 
> generating a TokenStream if automata are involved.
>   ** PostingsWithTermVectorsOffsetStrategy - similar refactoring
> * CompositePostingsEnum - aggregates several underlying PostingsEnums for 
> wildcard/mtq queries.  This should improve relevancy by providing unified 
> metrics for a wildcard across all it's term matches
> * Added a HighlightFlag for enabling the newly separated 
> TokenStreamOffsetStrategy since it can adversely affect passage relevancy



--
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-7526) Improvements to UnifiedHighlighter OffsetStrategies

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LUCENE-7526:


Github user Timothy055 commented on the issue:

https://github.com/apache/lucene-solr/pull/105
  
Merged your commit.


> Improvements to UnifiedHighlighter OffsetStrategies
> ---
>
> Key: LUCENE-7526
> URL: https://issues.apache.org/jira/browse/LUCENE-7526
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Reporter: Timothy M. Rodriguez
>Assignee: David Smiley
>Priority: Minor
> Fix For: 6.4
>
>
> This ticket improves several of the UnifiedHighlighter FieldOffsetStrategies 
> by reducing reliance on creating or re-creating TokenStreams.
> The primary changes are as follows:
> * AnalysisOffsetStrategy - split into two offset strategies
>   ** MemoryIndexOffsetStrategy - the primary analysis mode that utilizes a 
> MemoryIndex for producing Offsets
>   ** TokenStreamOffsetStrategy - an offset strategy that avoids creating a 
> MemoryIndex.  Can only be used if the query distills down to terms and 
> automata.
> * TokenStream removal 
>   ** MemoryIndexOffsetStrategy - previously a TokenStream was created to fill 
> the memory index and then once consumed a new one was generated by 
> uninverting the MemoryIndex back into a TokenStream if there were automata 
> (wildcard/mtq queries) involved.  Now this is avoided, which should save 
> memory and avoid a second pass over the data.
>   ** TermVectorOffsetStrategy - this was refactored in a similar way to avoid 
> generating a TokenStream if automata are involved.
>   ** PostingsWithTermVectorsOffsetStrategy - similar refactoring
> * CompositePostingsEnum - aggregates several underlying PostingsEnums for 
> wildcard/mtq queries.  This should improve relevancy by providing unified 
> metrics for a wildcard across all it's term matches
> * Added a HighlightFlag for enabling the newly separated 
> TokenStreamOffsetStrategy since it can adversely affect passage relevancy



--
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-7135) Constants check for JRE bitness causes SecurityException under WebStart

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7135:


No worries [~amake], stuff happens :)  I'm just glad we caught it before 6.3.0 
was out.

> Constants check for JRE bitness causes SecurityException under WebStart
> ---
>
> Key: LUCENE-7135
> URL: https://issues.apache.org/jira/browse/LUCENE-7135
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/other
>Affects Versions: 5.5
> Environment: OS X 10.11.4, Java 1.8.0_77-b03 (under WebStart)
>Reporter: Aaron Madlon-Kay
> Fix For: master (7.0), 6.3, 5.5.4
>
> Attachments: LUCENE-7135.diff
>
>
> I have an app that I deploy via WebStart that uses Lucene 5.2.1 (we are 
> locked to 5.2.1 because that's what [LanguageTool|https://languagetool.org/] 
> uses).
> When running under the WebStart security manager, there are two locations 
> where exceptions are thrown and prevent pretty much all Lucene classes from 
> initializing. This is true even when we sign everything and specify 
> {{}}.
> # In {{RamUsageEstimator}}, fixed by LUCENE-6923
> # In {{Constants}}, caused by the call 
> {{System.getProperty("sun.arch.data.model")}} (stack trace below).
> {code}
> Error: Caused by: java.security.AccessControlException: access denied 
> ("java.util.PropertyPermission" "sun.arch.data.model" "read") 
> Error:at 
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>  
> Error:at 
> java.security.AccessController.checkPermission(AccessController.java:884) 
> Error:at 
> java.lang.SecurityManager.checkPermission(SecurityManager.java:549) 
> Error:at 
> com.sun.javaws.security.JavaWebStartSecurity.checkPermission(Unknown Source) 
> Error:at 
> java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1294) 
> Error:at java.lang.System.getProperty(System.java:717) 
> Error:at org.apache.lucene.util.Constants.(Constants.java:71) 
> Error:... 34 more 
> {code}
> The latter is still present in the latest version. My patch illustrates one 
> solution that appears to be working for us.
> (This patch, together with a backport of the fix to LUCENE-6923, seems to fix 
> the issue for our purposes. However if you really wanted to make my day you 
> could put out a maintenance release of 5.2 with both fixes included.)



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