date:20150806


[ 
https://issues.apache.org/jira/browse/SOLR-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660288#comment-14660288
 ] 

Upayavira commented on SOLR-7576:
-

We've had JS, we've had XSLT, etc, in our config directory for a long time. 
What is different about this new approach that it demands a more secure 
approach in all situations?

Please understand - I'm really keen on this feature, and am supportive of the 
auth/signing functionality.

I teach Solr a lot, and I know that a lot of normal users will find the .system 
and the HTTP post part hard to understand when first getting started, hence 
wanting to make it really simple to do the simplest things, and possible to do 
the powerful things.

 Implement RequestHandler in Javascript
 --

 Key: SOLR-7576
 URL: https://issues.apache.org/jira/browse/SOLR-7576
 Project: Solr
  Issue Type: New Feature
Reporter: Noble Paul
 Attachments: SOLR-7576.patch, SOLR-7576.patch


 Solr now support dynamic loading (SOLR-7073) of components and it is secured 
 in SOLR-7126
 We can extend the same functionality with JS as well
 the handler {{/js}} is implicitly registered
 To make this work
 * Solr should be started with {{-Denable.js.loading=true}}
 * The javascript must be loaded to the {{.system}} collection using the blob 
 store API
 * Sign the javascript and pass the signature in a param called {{_sig}}
 The {{JSRequestHandler}} is implicitly defined and it can be accessed by 
 hitting {{/js/jsname/version}} 
 Steps for developing scripts
 # start the cluster with the {{enable.js.loading}} . If you are starting 
 using our script it would be {{bin/solr start -e cloud -a 
 -Denable.js.loading=true}} . You would not need security during development 
 , so don't add the private keys to Solr
 # create {{.system}} collection {{bin/solr create -c .system}}
 # Write your javascript code . (say {{test.js}} )
 # post it to {{.system}} collection . {{curl -X POST -H 'Content-Type: 
 application/octet-stream' --data-binary @test.js 
 http://localhost:8983/solr/.system/blob/test}}
 # run your script {{http://host:8983/solr/gettingstarted/js/test/1}}
 # Edit your script and repeat from step #4 . Keep in mind that the version 
 would be bumped up every time you post a new script . So, the second time the 
 url would be {{http://host:8983/solr/gettingstarted/js/test/2}} . So on and 
 so forth
 sample programs
 1) writes a val to output
 {code:javascript}
 //empty line
 $.response().add('testkey','Test Val');
 {code}
 2)  manipulate the output to add an extra field to each doc 
 {code}
 //empty line
 var l = [];
 $.query({
   q: '*:*',
   qt: '/select',
   start:0,
   }).forEach('response', function(doc) {
  doc.put('script', 'Added this 
 value');
  l.push(doc);
   });
  $.response().add('alldocs', l);
 {code}
 3)  stream through all the docs
 {code:Javascript}
 //empty line
 $.query({
   q: '*:*',
   qt: '/select',
   start:0,
   distrib:'false'
   }).pipe('response', 'docs', function(doc) { // the pipe function is 
 executed right before the response writer and right after the transformers   
  if('IT'== doc.get('genre_s')) return 
 null;
  doc.put('script', 'Added this 
 value');
  return doc;
   });
 {code}



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

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

[jira] [Created] (SOLR-7885) Add support for loading HTTP resources

2015-08-06 Thread Aaron LaBella (JIRA)

Aaron LaBella created SOLR-7885:
---

 Summary: Add support for loading HTTP resources
 Key: SOLR-7885
 URL: https://issues.apache.org/jira/browse/SOLR-7885
 Project: Solr
  Issue Type: Improvement
  Components: contrib - DataImportHandler, SolrJ
Affects Versions: 5.3
Reporter: Aaron LaBella


I have a need to be able to load data import handler configuration files from 
an HTTP server instead of the local file system.  So, I modified 
{code}org.apache.solr.core.SolrResourceLoader{code} and some of the respective 
dataimport files in {code}org.apache.solr.handler.dataimport{code} to be able 
to support doing this.  

{code}solrconfig.xml{code} now has the option to define a parameter: 
*configRemote*, and if defined (and it's an HTTP(s) URL), it'll attempt to load 
the resource.  If successfully, it'll also persist the resource to the local 
file system so that it is available on a solr server restart per chance that 
the remote resource is currently unavailable.

Lastly, to be consistent with the pattern that already exists in 
SolrResourceLoader, this feature is *disabled* by default, and requires the 
setting of an additional JVM property: 
{code}-Dsolr.allow.http.resourceloading=true{code}.

Please review and let me know if there is anything else that needs to be done 
in order for this patch to make the next release.  As far as I can tell, it's 
fully tested and ready to go.

Thanks.



--
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-7877) TestAuthenticationFramework.testBasics to preserve/restore the original request(Username|Password)

2015-08-06 Thread Gregory Chanan (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660761#comment-14660761
 ] 

Gregory Chanan commented on SOLR-7877:
--

bq. Can we move that test out of TestMiniSolrCloudCluster . So many tests 
extend that and this will lead to many errors in the future as well.

+1.  One of the main motivations for the MiniSolrCloudCluster was that people 
could use it in a has-a manner (i.e. as a variable in the test) rather than as 
an is-a manner (i.e. deriving from some complicated test base).  Demonstrating 
that was the motivation behind writing the TestMiniSolrCloudCluster (i.e. that 
you could have a SolrCloud test that exists outside of the SolrTest framework). 
 It looks like folks find it useful to have it available in an is-a manner; 
that's fine, but deriving from a class that has actual test methods sounds like 
a bad idea.  Maybe we should write a TestMiniSolrCloudClusterBase that has no 
test methods and convert all the tests that derive from 
TestMiniSolrCloudCluster to use that.

 TestAuthenticationFramework.testBasics to preserve/restore the original 
 request(Username|Password)
 --

 Key: SOLR-7877
 URL: https://issues.apache.org/jira/browse/SOLR-7877
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.3, Trunk
Reporter: Noble Paul
Assignee: Christine Poerschke
Priority: Blocker
 Attachments: SOLR-7877.patch


 {code}
 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13742/
 Java: 32bit/jdk1.8.0_60-ea-b24 -server -XX:+UseG1GC
 1 tests failed.
 FAILED:  
 org.apache.solr.cloud.TestAuthenticationFramework.testCollectionCreateWithoutCoresThenDelete
 Error Message:
 Error from server at http://127.0.0.1:51573/solr: Expected mime type 
 application/octet-stream but got text/html. html head meta 
 http-equiv=Content-Type content=text/html;charset=ISO-8859-1/ 
 titleError 401 /title /head body h2HTTP ERROR: 401/h2 pProblem 
 accessing /solr/admin/collections. Reason: preUnauthorized 
 request/pre/p hr /ismallPowered by Jetty:///small/i /body 
 /html
 Stack Trace:
 org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
 from server at http://127.0.0.1:51573/solr: Expected mime type 
 application/octet-stream but got text/html. html
 head
 meta http-equiv=Content-Type content=text/html;charset=ISO-8859-1/
 titleError 401 /title
 /head
 body
 h2HTTP ERROR: 401/h2
 pProblem accessing /solr/admin/collections. Reason:
 preUnauthorized request/pre/p
 hr /ismallPowered by Jetty:///small/i
 /body
 /html
 at 
 __randomizedtesting.SeedInfo.seed([A454441B503006EB:17918BDA5F48D5AA]:0)
 at 
 org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:528)
 at 
 org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234)
 at 
 org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226)
 at 
 org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376)
 at 
 org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328)
 at 
 org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
 at 
 org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856)
 at 
 org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799)
 at 
 org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
 at 
 org.apache.solr.cloud.MiniSolrCloudCluster.makeCollectionsRequest(MiniSolrCloudCluster.java:349)
 at 
 org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:333)
 at 
 org.apache.solr.cloud.TestMiniSolrCloudCluster.createCollection(TestMiniSolrCloudCluster.java:115)
 at 
 org.apache.solr.cloud.TestMiniSolrCloudCluster.testCollectionCreateWithoutCoresThenDelete(TestMiniSolrCloudCluster.java:298)
 {code}



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

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

[jira] [Created] (SOLR-7886) factor out a TestMiniSolrCloudClusterBase class

Christine Poerschke created SOLR-7886:
-

 Summary: factor out a TestMiniSolrCloudClusterBase class
 Key: SOLR-7886
 URL: https://issues.apache.org/jira/browse/SOLR-7886
 Project: Solr
  Issue Type: Test
Reporter: Christine Poerschke
Priority: Minor


Please see SOLR-7877 for initial discussion on this.

Currently we have:
{code}
public class TestMiniSolrCloudCluster extends LuceneTestCase
{code}
and
{code}
public class BasicAuthIntegrationTest extends TestMiniSolrCloudCluster {
public class TestAuthenticationFramework extends TestMiniSolrCloudCluster {
public class TestMiniSolrCloudClusterKerberos extends TestMiniSolrCloudCluster {
{code}



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

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

[jira] [Updated] (LUCENE-6417) Upgrade ANTLR to version 4.5

2015-08-06 Thread Uwe Schindler (JIRA)

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

Uwe Schindler updated LUCENE-6417:
--
Attachment: LUCENE-6417.patch

Hi,
patch looks good. I did some minor changes at the visibility of the
JavascriptCompiler fields to prevent {{acess$X}} methods (Eclipse warning about
synthetic access) and imported everything successfully into subversion. I also
changed the visibility of the error listeners/handlers to pkg private, the
javadocs now look identical to before.

ant precommit passes and all maven dependencies are fine.

ant regenerate recreates the files without overriding my visibility changes.

I will run all tests tomorrow and commit, it's too late now. Thanks Jack!

Upgrade ANTLR to version 4.5

Key: LUCENE-6417
URL: https://issues.apache.org/jira/browse/LUCENE-6417
Project: Lucene - Core
Issue Type: Improvement
Reporter: Jack Conradson
Assignee: Uwe Schindler
Attachments: LUCENE-6417.patch, LUCENE-6417.patch, LUCENE-6471.patch,
LUCENE-6471.patch, LUCENE-6471.patch

I would like to upgrade ANTLR from 3.5 to 4.5. This version adds several
features that will improve the existing grammars. The main improvement would
be the allowance of left-hand recursion in grammar rules which will reduce
the number of rules significantly for expressions.
This change will require some code refactoring to the existing expressions
work.

--
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-7576) Implement RequestHandler in Javascript

2015-08-06 Thread Christine Poerschke (BLOOMBERG/ LONDON)


[ 
https://issues.apache.org/jira/browse/SOLR-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660681#comment-14660681
 ] 

Upayavira commented on SOLR-7576:
-

For sure - is suspect we're more on the same page than you think.

I would wholly support us moving towards such a situation where ZK is 
protected, and everything goes via authenticated UIs. My concern is merely 
about how we get there.

e.g. allow filesystem based JS (for non-cloud) and JS in ZK as now for 5.x, but 
for 6.x remove that ability and require an API across the board.

i.e. keep things as consistent as we can?

 Implement RequestHandler in Javascript
 --

 Key: SOLR-7576
 URL: https://issues.apache.org/jira/browse/SOLR-7576
 Project: Solr
  Issue Type: New Feature
Reporter: Noble Paul
 Attachments: SOLR-7576.patch, SOLR-7576.patch


 Solr now support dynamic loading (SOLR-7073) of components and it is secured 
 in SOLR-7126
 We can extend the same functionality with JS as well
 the handler {{/js}} is implicitly registered
 To make this work
 * Solr should be started with {{-Denable.js.loading=true}}
 * The javascript must be loaded to the {{.system}} collection using the blob 
 store API
 * Sign the javascript and pass the signature in a param called {{_sig}}
 The {{JSRequestHandler}} is implicitly defined and it can be accessed by 
 hitting {{/js/jsname/version}} 
 Steps for developing scripts
 # start the cluster with the {{enable.js.loading}} . If you are starting 
 using our script it would be {{bin/solr start -e cloud -a 
 -Denable.js.loading=true}} . You would not need security during development 
 , so don't add the private keys to Solr
 # create {{.system}} collection {{bin/solr create -c .system}}
 # Write your javascript code . (say {{test.js}} )
 # post it to {{.system}} collection . {{curl -X POST -H 'Content-Type: 
 application/octet-stream' --data-binary @test.js 
 http://localhost:8983/solr/.system/blob/test}}
 # run your script {{http://host:8983/solr/gettingstarted/js/test/1}}
 # Edit your script and repeat from step #4 . Keep in mind that the version 
 would be bumped up every time you post a new script . So, the second time the 
 url would be {{http://host:8983/solr/gettingstarted/js/test/2}} . So on and 
 so forth
 sample programs
 1) writes a val to output
 {code:javascript}
 //empty line
 $.response().add('testkey','Test Val');
 {code}
 2)  manipulate the output to add an extra field to each doc 
 {code}
 //empty line
 var l = [];
 $.query({
   q: '*:*',
   qt: '/select',
   start:0,
   }).forEach('response', function(doc) {
  doc.put('script', 'Added this 
 value');
  l.push(doc);
   });
  $.response().add('alldocs', l);
 {code}
 3)  stream through all the docs
 {code:Javascript}
 //empty line
 $.query({
   q: '*:*',
   qt: '/select',
   start:0,
   distrib:'false'
   }).pipe('response', 'docs', function(doc) { // the pipe function is 
 executed right before the response writer and right after the transformers   
  if('IT'== doc.get('genre_s')) return 
 null;
  doc.put('script', 'Added this 
 value');
  return doc;
   });
 {code}



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

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

[jira] [Commented] (SOLR-7730) speed-up faceting on doc values fields

2015-08-06 Thread Yonik Seeley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660748#comment-14660748
 ] 

Yonik Seeley commented on SOLR-7730:


bq. how much gain did you evidence?
I actually didn't benchmark it because after I looked at the code in context, 
it became obvious :-)  (and I didn't have a docvalues index lying around...)

Remember to backport your last commit to 5x!  In case you're not familiar with 
the standard way, to merge back a commit from trunk to 5x, it's
{code}
#execute in the root of an up-to-date 5x checkout:
svn merge -c 1694563 https://svn.apache.org/repos/asf/lucene/dev/trunk
{code}

I actually have a shell variable set up to make it shorter:
T=https://svn.apache.org/repos/asf/lucene/dev/trunk


 speed-up faceting on doc values fields
 --

 Key: SOLR-7730
 URL: https://issues.apache.org/jira/browse/SOLR-7730
 Project: Solr
  Issue Type: Improvement
  Components: faceting
Affects Versions: 5.2.1
Reporter: Mikhail Khludnev
  Labels: patch
 Fix For: 5.3

 Attachments: LUCENE-7730.patch, LUCENE-7730.patch, SOLR-7730.patch


 every time we count facets on DocValues fields in Solr on many segments index 
 we see the unnecessary hotspot:
 {code}
 
 at 
 org.apache.lucene.index.MultiFields.getMergedFieldInfos(MultiFields.java:248)
 at 
 org.apache.lucene.index.SlowCompositeReaderWrapper.getFieldInfos(SlowCompositeReaderWrapper.java:239)
 at 
 org.apache.lucene.index.SlowCompositeReaderWrapper.getSortedSetDocValues(SlowCompositeReaderWrapper.java:176)
 at 
 org.apache.solr.request.DocValuesFacets.getCounts(DocValuesFacets.java:72)
 at 
 org.apache.solr.request.SimpleFacets.getTermCounts(SimpleFacets.java:460) 
 {code}
 the reason is SlowCompositeReaderWrapper.getSortedSetDocValues() Line 136 and 
 SlowCompositeReaderWrapper.getSortedDocValues() Line 174
 before return composite doc values, SCWR merges segment field infos, which is 
 expensive, but after fieldinfo is merged, it checks *only* docvalue type in 
 it. This dv type check can be done much easier in per segment basis. 
 This patch gets some performance gain for those who count DV facets in 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: [JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b60)

Hi Adrien,

No, it was just 2 documents in 1 segment yesterday. Just returned to this and 
yes, you're right, placing the 2nd document into a 2nd segment (prior to the 
force merge) seems to work, at least with the seed that previously caused the 
test to fail.

If that sounds about right, i'd be happy to properly patch for this tomorrow.

Thanks,
Christine

--- 
a/lucene/misc/src/test/org/apache/lucene/search/TestEarlyTerminatingSortingCollector.java
+++ 
b/lucene/misc/src/test/org/apache/lucene/search/TestEarlyTerminatingSortingCollector.java
@@ -115,6 +115,8 @@ public class TestEarlyTerminatingSortingCollector extends 
LuceneTestCase {
   // the index, although want want a sorted segment so it needs to be 
merged
   iw.getReader().close(); // refresh
   iw.addDocument(new Document());
+  iw.commit();
+  iw.addDocument(new Document());
   iw.forceMerge(1);
 }
 else if (random().nextBoolean()) {

- Original Message -
From: dev@lucene.apache.org
To: Christine Poerschke (BLOOMBERG/ LONDON), dev@lucene.apache.org
At: Aug  6 2015 10:27:38

Hi Christine,

On Wed, Aug 5, 2015 at 11:42 PM, Christine Poerschke (BLOOMBERG/
LONDON) cpoersc...@bloomberg.net wrote:
 Locally changed createRandomIndex to add not the 1 but 2 documents before the 
 forceMerge. Still ends up with an unsorted segment:

Did you ensure that there is a reopen between these two documents are
added, so that we not only have 2 docs but also 2 segments? This can
be done eg. by calling iw.getReader().close(); on the
RandomIndexWriter.

-- 
Adrien

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

[jira] [Commented] (SOLR-4854) Query elevation [elevated] field always false with java binary communication

2015-08-06 Thread Ray (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-4854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660821#comment-14660821
 ] 

Ray commented on SOLR-4854:
---

This issues was still there, any plan to fix this?

 Query elevation [elevated] field always false with java binary communication
 

 Key: SOLR-4854
 URL: https://issues.apache.org/jira/browse/SOLR-4854
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 4.3
 Environment: tomcat 6.0.33, java 1.6.0_26_x64, solrj 4.3
Reporter: Istvan Hegedus

 With XMLResponseParser there is no problem, but with default 
 BinaryResponseWriter [elevated] is always false.



--
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-7875) Speedup SolrQueryTimeoutImpl

2015-08-06 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660828#comment-14660828
 ] 

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

Commit 1694574 from [~tomasflobbe] in branch 'dev/trunk'
[ https://svn.apache.org/r1694574 ]

SOLR-7875: Speedup SolrQueryTimeoutImpl

 Speedup SolrQueryTimeoutImpl
 

 Key: SOLR-7875
 URL: https://issues.apache.org/jira/browse/SOLR-7875
 Project: Solr
  Issue Type: Improvement
Affects Versions: 5.0, 5.1, 5.2, 5.2.1
Reporter: Tomás Fernández Löbbe
Assignee: Tomás Fernández Löbbe
 Fix For: 5.3

 Attachments: SOLR-7875.patch


 SolrQueryTimeoutImpl can be slow for some use cases, for example, in cases 
 with many terms, where shouldExit() is called many times. 
 See http://search-lucene.com/m/l6pAi1HLrodLhNUd



--
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-7877) TestAuthenticationFramework.testBasics to preserve/restore the original request(Username|Password)


[ 
https://issues.apache.org/jira/browse/SOLR-7877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660799#comment-14660799
 ] 

Christine Poerschke commented on SOLR-7877:
---

+1 for refactoring {{TestMiniSolrCloudCluster}} - just created SOLR-7886 for it.

 TestAuthenticationFramework.testBasics to preserve/restore the original 
 request(Username|Password)
 --

 Key: SOLR-7877
 URL: https://issues.apache.org/jira/browse/SOLR-7877
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.3, Trunk
Reporter: Noble Paul
Assignee: Christine Poerschke
Priority: Blocker
 Attachments: SOLR-7877.patch


 {code}
 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13742/
 Java: 32bit/jdk1.8.0_60-ea-b24 -server -XX:+UseG1GC
 1 tests failed.
 FAILED:  
 org.apache.solr.cloud.TestAuthenticationFramework.testCollectionCreateWithoutCoresThenDelete
 Error Message:
 Error from server at http://127.0.0.1:51573/solr: Expected mime type 
 application/octet-stream but got text/html. html head meta 
 http-equiv=Content-Type content=text/html;charset=ISO-8859-1/ 
 titleError 401 /title /head body h2HTTP ERROR: 401/h2 pProblem 
 accessing /solr/admin/collections. Reason: preUnauthorized 
 request/pre/p hr /ismallPowered by Jetty:///small/i /body 
 /html
 Stack Trace:
 org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
 from server at http://127.0.0.1:51573/solr: Expected mime type 
 application/octet-stream but got text/html. html
 head
 meta http-equiv=Content-Type content=text/html;charset=ISO-8859-1/
 titleError 401 /title
 /head
 body
 h2HTTP ERROR: 401/h2
 pProblem accessing /solr/admin/collections. Reason:
 preUnauthorized request/pre/p
 hr /ismallPowered by Jetty:///small/i
 /body
 /html
 at 
 __randomizedtesting.SeedInfo.seed([A454441B503006EB:17918BDA5F48D5AA]:0)
 at 
 org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:528)
 at 
 org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234)
 at 
 org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226)
 at 
 org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376)
 at 
 org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328)
 at 
 org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
 at 
 org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856)
 at 
 org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799)
 at 
 org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
 at 
 org.apache.solr.cloud.MiniSolrCloudCluster.makeCollectionsRequest(MiniSolrCloudCluster.java:349)
 at 
 org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:333)
 at 
 org.apache.solr.cloud.TestMiniSolrCloudCluster.createCollection(TestMiniSolrCloudCluster.java:115)
 at 
 org.apache.solr.cloud.TestMiniSolrCloudCluster.testCollectionCreateWithoutCoresThenDelete(TestMiniSolrCloudCluster.java:298)
 {code}



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

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

[jira] [Commented] (SOLR-7877) TestAuthenticationFramework.testBasics to preserve/restore the original request(Username|Password)


[ 
https://issues.apache.org/jira/browse/SOLR-7877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660815#comment-14660815
 ] 

Christine Poerschke commented on SOLR-7877:
---

Hi [~noble.paul] - thanks for your comments and patch. I just created SOLR-7886 
for the refactoring discussion and efforts. If it's possible, could i suggest 
transferring the patch attachment to that JIRA ticket (and removing it from 
this JIRA ticket to avoid confusion between the changes already committed for 
this JIRA as per above and the currently attached, subsequent, separate patch)? 
My reason for not yet resolving this ticket here is that the merge to 
{{branches/lucene_solr_5_3}} is yet to happen, i will do that tomorrow/Friday 
morning London time if that's okay. Thank you. - Christine

 TestAuthenticationFramework.testBasics to preserve/restore the original 
 request(Username|Password)
 --

 Key: SOLR-7877
 URL: https://issues.apache.org/jira/browse/SOLR-7877
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.3, Trunk
Reporter: Noble Paul
Assignee: Christine Poerschke
Priority: Blocker
 Attachments: SOLR-7877.patch


 {code}
 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13742/
 Java: 32bit/jdk1.8.0_60-ea-b24 -server -XX:+UseG1GC
 1 tests failed.
 FAILED:  
 org.apache.solr.cloud.TestAuthenticationFramework.testCollectionCreateWithoutCoresThenDelete
 Error Message:
 Error from server at http://127.0.0.1:51573/solr: Expected mime type 
 application/octet-stream but got text/html. html head meta 
 http-equiv=Content-Type content=text/html;charset=ISO-8859-1/ 
 titleError 401 /title /head body h2HTTP ERROR: 401/h2 pProblem 
 accessing /solr/admin/collections. Reason: preUnauthorized 
 request/pre/p hr /ismallPowered by Jetty:///small/i /body 
 /html
 Stack Trace:
 org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
 from server at http://127.0.0.1:51573/solr: Expected mime type 
 application/octet-stream but got text/html. html
 head
 meta http-equiv=Content-Type content=text/html;charset=ISO-8859-1/
 titleError 401 /title
 /head
 body
 h2HTTP ERROR: 401/h2
 pProblem accessing /solr/admin/collections. Reason:
 preUnauthorized request/pre/p
 hr /ismallPowered by Jetty:///small/i
 /body
 /html
 at 
 __randomizedtesting.SeedInfo.seed([A454441B503006EB:17918BDA5F48D5AA]:0)
 at 
 org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:528)
 at 
 org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234)
 at 
 org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226)
 at 
 org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376)
 at 
 org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328)
 at 
 org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
 at 
 org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856)
 at 
 org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799)
 at 
 org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
 at 
 org.apache.solr.cloud.MiniSolrCloudCluster.makeCollectionsRequest(MiniSolrCloudCluster.java:349)
 at 
 org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:333)
 at 
 org.apache.solr.cloud.TestMiniSolrCloudCluster.createCollection(TestMiniSolrCloudCluster.java:115)
 at 
 org.apache.solr.cloud.TestMiniSolrCloudCluster.testCollectionCreateWithoutCoresThenDelete(TestMiniSolrCloudCluster.java:298)
 {code}



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

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

[jira] [Commented] (SOLR-7576) Implement RequestHandler in Javascript

2015-08-06 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660690#comment-14660690
 ] 

Noble Paul commented on SOLR-7576:
--

bq.e.g. allow filesystem based JS (for non-cloud) and JS in ZK as now for 5.x

A lot of APIs we build of late do not have Standalone Solr support. For lack of 
time and resources we are unable to build that. If possible I would like to see 
it supported. 

bq.i.e. keep things as consistent as we can?

yes, eventually consistent

 Implement RequestHandler in Javascript
 --

 Key: SOLR-7576
 URL: https://issues.apache.org/jira/browse/SOLR-7576
 Project: Solr
  Issue Type: New Feature
Reporter: Noble Paul
 Attachments: SOLR-7576.patch, SOLR-7576.patch


 Solr now support dynamic loading (SOLR-7073) of components and it is secured 
 in SOLR-7126
 We can extend the same functionality with JS as well
 the handler {{/js}} is implicitly registered
 To make this work
 * Solr should be started with {{-Denable.js.loading=true}}
 * The javascript must be loaded to the {{.system}} collection using the blob 
 store API
 * Sign the javascript and pass the signature in a param called {{_sig}}
 The {{JSRequestHandler}} is implicitly defined and it can be accessed by 
 hitting {{/js/jsname/version}} 
 Steps for developing scripts
 # start the cluster with the {{enable.js.loading}} . If you are starting 
 using our script it would be {{bin/solr start -e cloud -a 
 -Denable.js.loading=true}} . You would not need security during development 
 , so don't add the private keys to Solr
 # create {{.system}} collection {{bin/solr create -c .system}}
 # Write your javascript code . (say {{test.js}} )
 # post it to {{.system}} collection . {{curl -X POST -H 'Content-Type: 
 application/octet-stream' --data-binary @test.js 
 http://localhost:8983/solr/.system/blob/test}}
 # run your script {{http://host:8983/solr/gettingstarted/js/test/1}}
 # Edit your script and repeat from step #4 . Keep in mind that the version 
 would be bumped up every time you post a new script . So, the second time the 
 url would be {{http://host:8983/solr/gettingstarted/js/test/2}} . So on and 
 so forth
 sample programs
 1) writes a val to output
 {code:javascript}
 //empty line
 $.response().add('testkey','Test Val');
 {code}
 2)  manipulate the output to add an extra field to each doc 
 {code}
 //empty line
 var l = [];
 $.query({
   q: '*:*',
   qt: '/select',
   start:0,
   }).forEach('response', function(doc) {
  doc.put('script', 'Added this 
 value');
  l.push(doc);
   });
  $.response().add('alldocs', l);
 {code}
 3)  stream through all the docs
 {code:Javascript}
 //empty line
 $.query({
   q: '*:*',
   qt: '/select',
   start:0,
   distrib:'false'
   }).pipe('response', 'docs', function(doc) { // the pipe function is 
 executed right before the response writer and right after the transformers   
  if('IT'== doc.get('genre_s')) return 
 null;
  doc.put('script', 'Added this 
 value');
  return doc;
   });
 {code}



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

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

[jira] [Updated] (SOLR-7219) Access filter cache from lucene query syntax

2015-08-06 Thread Yonik Seeley (JIRA)


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

Yonik Seeley updated SOLR-7219:
---
Attachment: SOLR-7219.patch

Here's the patch implementing the proposed syntax, along with tests that the 
filter cache is actually being hit.

 Access filter cache from lucene query syntax
 

 Key: SOLR-7219
 URL: https://issues.apache.org/jira/browse/SOLR-7219
 Project: Solr
  Issue Type: New Feature
Reporter: Yonik Seeley
Assignee: Yonik Seeley
 Attachments: SOLR-7219.patch


 A filter query retrieves a set of documents matching a query from the filter 
 cache. Since scores are not cached, all documents that match the filter 
 produce the same score. Cached filters will be extremely fast when they are 
 used again in another query.
 Filter Query Example:
 {code}
 description:HDTV OR filter(+promotion:tv +promotion_date:[NOW/DAY-7DAYS TO 
 NOW/DAY+1DAY])
 {code}
 The power of the filter() syntax is that it may be used anywhere within a 
 lucene/solr query syntax. Normal fq support is limited to top-level 
 conjunctions. 



--
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-7757) Create a framework to edit/reload security params


[ 
https://issues.apache.org/jira/browse/SOLR-7757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660732#comment-14660732
 ] 

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

Commit 1694566 from [~noble.paul] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1694566 ]

SOLR-7757: Pair is not available in java 7

 Create a framework to edit/reload security params
 -

 Key: SOLR-7757
 URL: https://issues.apache.org/jira/browse/SOLR-7757
 Project: Solr
  Issue Type: Sub-task
Reporter: Noble Paul
Assignee: Noble Paul
 Attachments: SOLR-7757.patch


 We should have a standard mechanism which security plugins can use to 
 edit/reload etc for various plugins.
 This will involve solr watching the {{/security.json}} and giving callbacks 
 to the plugins. It wil also create standard end points for Rest-like APIs for 
 each plugin. Each plugin will be able to define the payload, verify it, 
 modify the config etc 



--
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-1945) Add support for child docs in DocumentObjectBinder

2015-08-06 Thread Preetam Dwivedi (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660778#comment-14660778
 ] 

Preetam Dwivedi commented on SOLR-1945:
---

I am getting following error when I am using @Field(child=true)

{code:xml}
Exception in thread main 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://localhost:8983/solr: undefined field: child
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:560)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:235)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:227)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:174)
at org.apache.solr.client.solrj.SolrClient.addBean(SolrClient.java:278)
at 
com.portal.job.services.solr.TestSolrService.test(TestSolrService.java:27)
at 
com.portal.job.services.solr.TestSolrService.main(TestSolrService.java:14)

{code}
Code:

{code:java}
import java.io.IOException;

import org.apache.solr.client.solrj.SolrClient;
import org.apache.solr.client.solrj.SolrServerException;
import org.apache.solr.client.solrj.beans.Field;
import org.apache.solr.client.solrj.impl.HttpSolrClient;

public class TestSolrService {

public static void main(String[] args) throws IOException,
SolrServerException {
new TestSolrService().test();
}

public void test() throws IOException, SolrServerException {

SolrClient client = new 
HttpSolrClient(http://localhost:8983/solr/;);

Test test = new Test();
test.setId(2);
Child c = new Child();
c.child = true;
c.id = 1;
test.setChild(c);
client.addBean(test, test, 10);

client.close();

}

public class Child {
@Field
public String id;
@Field
public boolean child;
}

public class Test {

@Field
private String id;

@Field(child = true)
private Child child;

public String getId() {
return id;
}

public void setId(String id) {
this.id = id;
}

public Child getChild() {
return child;
}

public void setChild(Child child) {
this.child = child;
}

}
}
{code}

 Add support for child docs in DocumentObjectBinder
 --

 Key: SOLR-1945
 URL: https://issues.apache.org/jira/browse/SOLR-1945
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
Assignee: Noble Paul
Priority: Minor
 Fix For: 5.1, Trunk

 Attachments: SOLR-1945.patch, SOLR-1945.patch


 see 
 http://search.lucidimagination.com/search/document/d909d909420aeb4e/does_solrj_support_nested_annotated_beans
 Would be nice to be able to pass an object graph to solrj with @field 
 annotations rather than just a top level class



--
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-Tests-5.x-Java7 - Build # 3399 - Failure

2015-08-06 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/3399/

1 tests failed.
REGRESSION:  org.apache.solr.schema.TestCloudSchemaless.test

Error Message:
QUERY FAILED: 
xpath=/response/arr[@name='fields']/lst/str[@name='name'][.='newTestFieldInt445']
  request=/schema/fields?wt=xml  response=?xml version=1.0 
encoding=UTF-8? response  lst name=responseHeader   int 
name=status0/int   int name=QTime30/int /lst arr name=fields   
lst str name=name_root_/str str name=typestring/str 
bool name=indexedtrue/bool bool name=storedtrue/bool bool 
name=multiValuedfalse/bool   /lst   lst str 
name=name_version_/str str name=typelong/str bool 
name=indexedtrue/bool bool name=storedtrue/bool   /lst   lst 
str name=nameconstantField/str str name=typetdouble/str   
/lst   lst str name=nameid/str str name=typestring/str  
   bool name=indexedtrue/bool bool name=storedtrue/bool 
bool name=multiValuedfalse/bool bool name=requiredtrue/bool 
bool name=uniqueKeytrue/bool   /lst   lst str 
name=namenewTestFieldInt0/str str name=typetlong/str   /lst   
lst str name=namenewTestFieldInt1/str str 
name=typetlong/str   /lst   lst str 
name=namenewTestFieldInt10/str str name=typetlong/str   /lst   
lst str name=namenewTestFieldInt100/str str 
name=typetlong/str   /lst   lst str 
name=namenewTestFieldInt101/str str name=typetlong/str   /lst  
 lst str name=namenewTestFieldInt102/str str 
name=typetlong/str   /lst   lst str 
name=namenewTestFieldInt103/str str name=typetlong/str   /lst  
 lst str name=namenewTestFieldInt104/str str 
name=typetlong/str   /lst   lst str 
name=namenewTestFieldInt105/str str name=typetlong/str   /lst  
 lst str name=namenewTestFieldInt106/str str 
name=typetlong/str   /lst   lst str 
name=namenewTestFieldInt107/str str name=typetlong/str   /lst  
 lst str name=namenewTestFieldInt108/str str 
name=typetlong/str   /lst   lst str 
name=namenewTestFieldInt109/str str name=typetlong/str   /lst  
 lst str name=namenewTestFieldInt11/str str 
name=typetlong/str   /lst   lst str 
name=namenewTestFieldInt110/str str name=typetlong/str   /lst  
 lst str name=namenewTestFieldInt111/str str 
name=typetlong/str   /lst   lst str 
name=namenewTestFieldInt112/str str name=typetlong/str   /lst  
 lst str name=namenewTestFieldInt113/str str 
name=typetlong/str   /lst   lst str 
name=namenewTestFieldInt114/str str name=typetlong/str   /lst  
 lst str name=namenewTestFieldInt115/str str 
name=typetlong/str   /lst   lst str 
name=namenewTestFieldInt116/str str name=typetlong/str   /lst  
 lst str name=namenewTestFieldInt117/str str 
name=typetlong/str   /lst   lst str 
name=namenewTestFieldInt118/str str name=typetlong/str   /lst  
 lst str name=namenewTestFieldInt119/str str 
name=typetlong/str   /lst   lst str 
name=namenewTestFieldInt12/str str name=typetlong/str   /lst   
lst str name=namenewTestFieldInt120/str str 
name=typetlong/str   /lst   lst str 
name=namenewTestFieldInt121/str str name=typetlong/str   /lst  
 lst str name=namenewTestFieldInt122/str str 
name=typetlong/str   /lst   lst str 
name=namenewTestFieldInt123/str str name=typetlong/str   /lst  
 lst str name=namenewTestFieldInt124/str str 
name=typetlong/str   /lst   lst str 
name=namenewTestFieldInt125/str str name=typetlong/str   /lst  
 lst str name=namenewTestFieldInt126/str str 
name=typetlong/str   /lst   lst str 
name=namenewTestFieldInt127/str str name=typetlong/str   /lst  
 lst str name=namenewTestFieldInt128/str str 
name=typetlong/str   /lst   lst str 
name=namenewTestFieldInt129/str str name=typetlong/str   /lst  
 lst str name=namenewTestFieldInt13/str str 
name=typetlong/str   /lst   lst str 
name=namenewTestFieldInt130/str str name=typetlong/str   /lst  
 lst str name=namenewTestFieldInt131/str str 
name=typetlong/str   /lst   lst str 
name=namenewTestFieldInt132/str str name=typetlong/str   /lst  
 lst str name=namenewTestFieldInt133/str str 
name=typetlong/str   /lst   lst str 
name=namenewTestFieldInt134/str str name=typetlong/str   /lst  
 lst str name=namenewTestFieldInt135/str str 
name=typetlong/str   /lst   lst str 
name=namenewTestFieldInt136/str str name=typetlong/str   /lst  
 lst str name=namenewTestFieldInt137/str str 
name=typetlong/str   /lst   lst str 
name=namenewTestFieldInt138/str str name=typetlong/str   /lst  
 lst str name=namenewTestFieldInt139/str str 
name=typetlong/str   /lst   lst str 
name=namenewTestFieldInt14/str str name=typetlong/str   /lst   
lst str name=namenewTestFieldInt140/str str 
name=typetlong/str   /lst   lst str

[jira] [Commented] (SOLR-7875) Speedup SolrQueryTimeoutImpl

2015-08-06 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660834#comment-14660834
 ] 

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

Commit 1694576 from [~tomasflobbe] in branch 'dev/branches/lucene_solr_5_3'
[ https://svn.apache.org/r1694576 ]

SOLR-7875: Speedup SolrQueryTimeoutImpl

 Speedup SolrQueryTimeoutImpl
 

 Key: SOLR-7875
 URL: https://issues.apache.org/jira/browse/SOLR-7875
 Project: Solr
  Issue Type: Improvement
Affects Versions: 5.0, 5.1, 5.2, 5.2.1
Reporter: Tomás Fernández Löbbe
Assignee: Tomás Fernández Löbbe
 Fix For: 5.3

 Attachments: SOLR-7875.patch


 SolrQueryTimeoutImpl can be slow for some use cases, for example, in cases 
 with many terms, where shouldExit() is called many times. 
 See http://search-lucene.com/m/l6pAi1HLrodLhNUd



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

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

[jira] [Resolved] (SOLR-7875) Speedup SolrQueryTimeoutImpl

2015-08-06 Thread JIRA


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

Tomás Fernández Löbbe resolved SOLR-7875.
-
Resolution: Fixed

 Speedup SolrQueryTimeoutImpl
 

 Key: SOLR-7875
 URL: https://issues.apache.org/jira/browse/SOLR-7875
 Project: Solr
  Issue Type: Improvement
Affects Versions: 5.0, 5.1, 5.2, 5.2.1
Reporter: Tomás Fernández Löbbe
Assignee: Tomás Fernández Löbbe
 Fix For: 5.3

 Attachments: SOLR-7875.patch


 SolrQueryTimeoutImpl can be slow for some use cases, for example, in cases 
 with many terms, where shouldExit() is called many times. 
 See http://search-lucene.com/m/l6pAi1HLrodLhNUd



--
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-7760) Fix method and field visibility for UIMAUpdateRequestProcessor and SolrUIMAConfiguration

2015-08-06 Thread Aaron LaBella (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660714#comment-14660714
 ] 

Aaron LaBella commented on SOLR-7760:
-

Is someone able to commit this patch soon?  It'd be great to get in the next 
release of solr.
Thanks!

 Fix method and field visibility for UIMAUpdateRequestProcessor and 
 SolrUIMAConfiguration
 

 Key: SOLR-7760
 URL: https://issues.apache.org/jira/browse/SOLR-7760
 Project: Solr
  Issue Type: Improvement
  Components: contrib - UIMA
Affects Versions: 5x
Reporter: Aaron LaBella
Priority: Critical
 Fix For: 5.3

 Attachments: SOLR-7760.patch


 The methods in 
 {{solr/contrib/uima/src/java/org/apache/solr/uima/processor/SolrUIMAConfiguration.java}}
  are not public and they need to be for other code to be able to make use of 
 the configuration data, ie: mapped fields.   Likewise, 
 {{solr/contrib/uima/src/java/org/apache/solr/uima/processor/UIMAUpdateRequestProcessor.java}}
  does not have an accessor for the SolrUIMAConfiguration object



--
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-7885) Add support for loading HTTP resources

2015-08-06 Thread Aaron LaBella (JIRA)


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

Aaron LaBella updated SOLR-7885:

Attachment: SOLR-7885-2.patch
SOLR-7885-1.patch

I split the patch into 2 parts, one for solr-core and one for dataimporthandler

 Add support for loading HTTP resources
 --

 Key: SOLR-7885
 URL: https://issues.apache.org/jira/browse/SOLR-7885
 Project: Solr
  Issue Type: Improvement
  Components: contrib - DataImportHandler, SolrJ
Affects Versions: 5.3
Reporter: Aaron LaBella
 Attachments: SOLR-7885-1.patch, SOLR-7885-2.patch


 I have a need to be able to load data import handler configuration files from 
 an HTTP server instead of the local file system.  So, I modified 
 {code}org.apache.solr.core.SolrResourceLoader{code} and some of the 
 respective dataimport files in {code}org.apache.solr.handler.dataimport{code} 
 to be able to support doing this.  
 {code}solrconfig.xml{code} now has the option to define a parameter: 
 *configRemote*, and if defined (and it's an HTTP(s) URL), it'll attempt to 
 load the resource.  If successfully, it'll also persist the resource to the 
 local file system so that it is available on a solr server restart per chance 
 that the remote resource is currently unavailable.
 Lastly, to be consistent with the pattern that already exists in 
 SolrResourceLoader, this feature is *disabled* by default, and requires the 
 setting of an additional JVM property: 
 {code}-Dsolr.allow.http.resourceloading=true{code}.
 Please review and let me know if there is anything else that needs to be done 
 in order for this patch to make the next release.  As far as I can tell, it's 
 fully tested and ready to go.
 Thanks.



--
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-6621) two unused variables in analysis/stempel/src/java/org/egothor/stemmer/Compile.java

2015-08-06 Thread Rishabh Patel (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-6621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660691#comment-14660691
 ] 

Rishabh Patel commented on LUCENE-6621:
---

Thanks Christine! 

 two unused variables in 
 analysis/stempel/src/java/org/egothor/stemmer/Compile.java
 --

 Key: LUCENE-6621
 URL: https://issues.apache.org/jira/browse/LUCENE-6621
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/analysis
Affects Versions: Trunk
Reporter: Rishabh Patel
Assignee: Christine Poerschke
Priority: Trivial
 Fix For: 5.3, Trunk


 {code:title=Compile.java|borderStyle=solid}
 public static void main(java.lang.String[] args) throws Exception {
 ...
   for (int i = 1; i  args.length; i++) {
   // System.out.println([ + args[i] + ]);
   Diff diff = new Diff();
   int stems = 0;
   int words = 0;
 ...
 {code}
 In the file {{Compile.java}}, the variables {{stems}} and {{words}} are 
 unused.
 Although {{words}} gets incremented further in the file, it does not get 
 referenced or used elsewhere.
 {{stems}} is neither incremented nor used elsewhere in the project.
 Are these variables redundant?



--
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-7730) speed-up faceting on doc values fields

2015-08-06 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660724#comment-14660724
 ] 

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

Commit 1694563 from m...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1694563 ]

SOLR-7730: mention initial contributors

 speed-up faceting on doc values fields
 --

 Key: SOLR-7730
 URL: https://issues.apache.org/jira/browse/SOLR-7730
 Project: Solr
  Issue Type: Improvement
  Components: faceting
Affects Versions: 5.2.1
Reporter: Mikhail Khludnev
  Labels: patch
 Fix For: 5.3

 Attachments: LUCENE-7730.patch, LUCENE-7730.patch, SOLR-7730.patch


 every time we count facets on DocValues fields in Solr on many segments index 
 we see the unnecessary hotspot:
 {code}
 
 at 
 org.apache.lucene.index.MultiFields.getMergedFieldInfos(MultiFields.java:248)
 at 
 org.apache.lucene.index.SlowCompositeReaderWrapper.getFieldInfos(SlowCompositeReaderWrapper.java:239)
 at 
 org.apache.lucene.index.SlowCompositeReaderWrapper.getSortedSetDocValues(SlowCompositeReaderWrapper.java:176)
 at 
 org.apache.solr.request.DocValuesFacets.getCounts(DocValuesFacets.java:72)
 at 
 org.apache.solr.request.SimpleFacets.getTermCounts(SimpleFacets.java:460) 
 {code}
 the reason is SlowCompositeReaderWrapper.getSortedSetDocValues() Line 136 and 
 SlowCompositeReaderWrapper.getSortedDocValues() Line 174
 before return composite doc values, SCWR merges segment field infos, which is 
 expensive, but after fieldinfo is merged, it checks *only* docvalue type in 
 it. This dv type check can be done much easier in per segment basis. 
 This patch gets some performance gain for those who count DV facets in 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] [Commented] (SOLR-7757) Create a framework to edit/reload security params

2015-08-06 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660725#comment-14660725
 ] 

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

Commit 1694564 from [~noble.paul] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1694564 ]

SOLR-7757: Pair is not available in java 7

 Create a framework to edit/reload security params
 -

 Key: SOLR-7757
 URL: https://issues.apache.org/jira/browse/SOLR-7757
 Project: Solr
  Issue Type: Sub-task
Reporter: Noble Paul
Assignee: Noble Paul
 Attachments: SOLR-7757.patch


 We should have a standard mechanism which security plugins can use to 
 edit/reload etc for various plugins.
 This will involve solr watching the {{/security.json}} and giving callbacks 
 to the plugins. It wil also create standard end points for Rest-like APIs for 
 each plugin. Each plugin will be able to define the payload, verify it, 
 modify the config etc 



--
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-7757) Create a framework to edit/reload security params

2015-08-06 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660729#comment-14660729
 ] 

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

Commit 1694565 from [~noble.paul] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1694565 ]

SOLR-7757: Pair is not available in java 7

 Create a framework to edit/reload security params
 -

 Key: SOLR-7757
 URL: https://issues.apache.org/jira/browse/SOLR-7757
 Project: Solr
  Issue Type: Sub-task
Reporter: Noble Paul
Assignee: Noble Paul
 Attachments: SOLR-7757.patch


 We should have a standard mechanism which security plugins can use to 
 edit/reload etc for various plugins.
 This will involve solr watching the {{/security.json}} and giving callbacks 
 to the plugins. It wil also create standard end points for Rest-like APIs for 
 each plugin. Each plugin will be able to define the payload, verify it, 
 modify the config etc 



--
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-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b60)

2015-08-06 Thread Adrien Grand

+1

On Thu, Aug 6, 2015 at 10:29 PM, Christine Poerschke (BLOOMBERG/
LONDON) cpoersc...@bloomberg.net wrote:
 Hi Adrien,

 No, it was just 2 documents in 1 segment yesterday. Just returned to this and 
 yes, you're right, placing the 2nd document into a 2nd segment (prior to the 
 force merge) seems to work, at least with the seed that previously caused the 
 test to fail.

 If that sounds about right, i'd be happy to properly patch for this tomorrow.

 Thanks,
 Christine

 --- 
 a/lucene/misc/src/test/org/apache/lucene/search/TestEarlyTerminatingSortingCollector.java
 +++ 
 b/lucene/misc/src/test/org/apache/lucene/search/TestEarlyTerminatingSortingCollector.java
 @@ -115,6 +115,8 @@ public class TestEarlyTerminatingSortingCollector extends 
 LuceneTestCase {
// the index, although want want a sorted segment so it needs to be 
 merged
iw.getReader().close(); // refresh
iw.addDocument(new Document());
 +  iw.commit();
 +  iw.addDocument(new Document());
iw.forceMerge(1);
  }
  else if (random().nextBoolean()) {

 - Original Message -
 From: dev@lucene.apache.org
 To: Christine Poerschke (BLOOMBERG/ LONDON), dev@lucene.apache.org
 At: Aug  6 2015 10:27:38

 Hi Christine,

 On Wed, Aug 5, 2015 at 11:42 PM, Christine Poerschke (BLOOMBERG/
 LONDON) cpoersc...@bloomberg.net wrote:
 Locally changed createRandomIndex to add not the 1 but 2 documents before 
 the forceMerge. Still ends up with an unsorted segment:

 Did you ensure that there is a reopen between these two documents are
 added, so that we not only have 2 docs but also 2 segments? This can
 be done eg. by calling iw.getReader().close(); on the
 RandomIndexWriter.

 --
 Adrien

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





-- 
Adrien

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

[jira] [Commented] (SOLR-7877) TestAuthenticationFramework.testBasics to preserve/restore the original request(Username|Password)

2015-08-06 Thread Ramkumar Aiyengar (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660786#comment-14660786
 ] 

Ramkumar Aiyengar commented on SOLR-7877:
-

I agree, I think in general, deriving tests is a bad idea. I once pulled out 
`test` virtual method for this very reason from AbstractZkTestCase.. If many 
tests extend a particular test suite, then they should be changed to not do it.

 TestAuthenticationFramework.testBasics to preserve/restore the original 
 request(Username|Password)
 --

 Key: SOLR-7877
 URL: https://issues.apache.org/jira/browse/SOLR-7877
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.3, Trunk
Reporter: Noble Paul
Assignee: Christine Poerschke
Priority: Blocker
 Attachments: SOLR-7877.patch


 {code}
 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13742/
 Java: 32bit/jdk1.8.0_60-ea-b24 -server -XX:+UseG1GC
 1 tests failed.
 FAILED:  
 org.apache.solr.cloud.TestAuthenticationFramework.testCollectionCreateWithoutCoresThenDelete
 Error Message:
 Error from server at http://127.0.0.1:51573/solr: Expected mime type 
 application/octet-stream but got text/html. html head meta 
 http-equiv=Content-Type content=text/html;charset=ISO-8859-1/ 
 titleError 401 /title /head body h2HTTP ERROR: 401/h2 pProblem 
 accessing /solr/admin/collections. Reason: preUnauthorized 
 request/pre/p hr /ismallPowered by Jetty:///small/i /body 
 /html
 Stack Trace:
 org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
 from server at http://127.0.0.1:51573/solr: Expected mime type 
 application/octet-stream but got text/html. html
 head
 meta http-equiv=Content-Type content=text/html;charset=ISO-8859-1/
 titleError 401 /title
 /head
 body
 h2HTTP ERROR: 401/h2
 pProblem accessing /solr/admin/collections. Reason:
 preUnauthorized request/pre/p
 hr /ismallPowered by Jetty:///small/i
 /body
 /html
 at 
 __randomizedtesting.SeedInfo.seed([A454441B503006EB:17918BDA5F48D5AA]:0)
 at 
 org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:528)
 at 
 org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234)
 at 
 org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226)
 at 
 org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376)
 at 
 org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328)
 at 
 org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
 at 
 org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856)
 at 
 org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799)
 at 
 org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
 at 
 org.apache.solr.cloud.MiniSolrCloudCluster.makeCollectionsRequest(MiniSolrCloudCluster.java:349)
 at 
 org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:333)
 at 
 org.apache.solr.cloud.TestMiniSolrCloudCluster.createCollection(TestMiniSolrCloudCluster.java:115)
 at 
 org.apache.solr.cloud.TestMiniSolrCloudCluster.testCollectionCreateWithoutCoresThenDelete(TestMiniSolrCloudCluster.java:298)
 {code}



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

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

[jira] [Commented] (LUCENE-6417) Upgrade ANTLR to version 4.5

2015-08-06 Thread Jack Conradson (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-6417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660824#comment-14660824
 ] 

Jack Conradson commented on LUCENE-6417:


Thanks again, Uwe, for all the feedback and taking the time to get the patch 
into Lucene.

 Upgrade ANTLR to version 4.5
 

 Key: LUCENE-6417
 URL: https://issues.apache.org/jira/browse/LUCENE-6417
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Jack Conradson
Assignee: Uwe Schindler
 Attachments: LUCENE-6417.patch, LUCENE-6417.patch, LUCENE-6471.patch, 
 LUCENE-6471.patch, LUCENE-6471.patch


 I would like to upgrade ANTLR from 3.5 to 4.5.  This version adds several 
 features that will improve the existing grammars.  The main improvement would 
 be the allowance of left-hand recursion in grammar rules which will reduce 
 the number of rules significantly for expressions.
 This change will require some code refactoring to the existing expressions 
 work.



--
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-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life

2015-08-06 Thread ASF subversion and git services (JIRA)

Shawn Heisey created SOLR-7887:
--

 Summary: Upgrade Solr to use log4j2 -- log4j 1 now officially end 
of life
 Key: SOLR-7887
 URL: https://issues.apache.org/jira/browse/SOLR-7887
 Project: Solr
  Issue Type: Task
Affects Versions: 5.2.1
Reporter: Shawn Heisey


The logging services project has officially announced the EOL of log4j 1:

https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces

In the official binary jetty deployment, we use use log4j 1.2 as our final 
logging destination, so the admin UI has a log watcher that actually uses log4j 
and java.util.logging classes.  That will need to be extended to add log4j2.  I 
think that might be the largest pain point to this upgrade.

There is some crossover between log4j2 and slf4j.  Figuring out exactly which 
jars need to be in the lib/ext directory will take some research.



--
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-7666) Umbrella ticket for Angular JS post-5.2.1 issues


[ 
https://issues.apache.org/jira/browse/SOLR-7666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14659748#comment-14659748
 ] 

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

Commit 1694429 from [~upayavira] in branch 'dev/trunk'
[ https://svn.apache.org/r1694429 ]

SOLR-7666 Update CHANGES.txt for Angular UI changes

 Umbrella ticket for Angular JS post-5.2.1 issues
 

 Key: SOLR-7666
 URL: https://issues.apache.org/jira/browse/SOLR-7666
 Project: Solr
  Issue Type: New Feature
  Components: UI
Affects Versions: 5.3, Trunk
Reporter: Erick Erickson
Assignee: Upayavira

 As of Solr 5.2.1, there's a new admin UI available that has been written 
 almost entirely by Upayavira (thanks!) over the last several months. It's 
 written in Angular JS with an eye towards enhancement/maintainability. The 
 default UI is still the old version, but you can access the new version by 
 going to http://sever:port/solr/index.html. There are a couple of fixes 
 between 5.2.0 and 5.2.1, so please use either a fresh 5x checkout, trunk, or 
 5.2.1
 The expectation is that in Solr 5.3, the new code will become the default 
 with the old UI deprecated and eventually removed.
 So it would be a great help if volunteers could give the new UI a spin. It 
 should look much the same as the current one at the start, but evolve into 
 something much more interesting and more cloud-friendly. Of course all the 
 new UI code will always be available on trunk/6.0 too, and the up-to-date 
 code will always be on both the trunk and 5x branches.
 Please provide feedback on the user's (or dev) lists about anything you find 
 that doesn't work, or enhancements you'd like to see (or, even better, 
 contribute). If you raise a JIRA, please link it to this one so I can keep 
 track of what needs to be committed. If linking JIRAs is a mystery just add a 
 comment to this JIRA referencing the new JIRA and we can take care of it.
 Please do _not_ attach patches to this JIRA, it'll be much easier to keep 
 track of everything if the patches are attached to sub-JIRAs.
 And a big thanks to Upayavira for this work!



--
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-6725) Reindex crashes the JVM

Jan Eerdekens created LUCENE-6725:
-

 Summary: Reindex crashes the JVM
 Key: LUCENE-6725
 URL: https://issues.apache.org/jira/browse/LUCENE-6725
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/index
Affects Versions: 3.5
 Environment: Solaris 10 1/13 (Update 11) Patchset applied.
Oracle Solaris 10 8/11 s10s_u10wos_17b SPARC
CPU:total 64 v9, popc, vis1, vis2, vis3, blk_init, cbcond, sun4v, niagara_plus
Memory: 8k page, physical 25165824k(3240848k free)
vm_info: Java HotSpot(TM) 64-Bit Server VM (24.75-b04) for solaris-sparc JRE 
(1.7.0_75-b13)
Reporter: Jan Eerdekens
Priority: Blocker


We're using Liferay which uses Lucene behind the screens to index things like 
documents, web content, users, etc... . When we trigger a full reindex via the 
Liferay Control Panel, which uses IndexWriter.deleteAll(), the JVM crashes and 
generates a dump with the following message: 

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x78de94a8, pid=18938, tid=2478
#
# JRE version: Java(TM) SE Runtime Environment (7.0_75-b13) (build 1.7.0_75-b13)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.75-b04 mixed mode 
solaris-sparc compressed oops)
# Problematic frame:
# J 5227 C2 
org.apache.lucene.index.IndexFileNames.segmentFileName(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
 (44 bytes) @ 0x78de94a8 [0x78de9480+0x28]



--
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-6722) Java 8 as the minimum supported JVM version for branch_5x

2015-08-06 Thread Mark Miller (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-6722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14659760#comment-14659760
 ] 

Mark Miller commented on LUCENE-6722:
-

bq. At least to make the life of developers easy , we must do it

Making our two branches identical is a silly idea for a solution. As a 
community we decided on 2 dev branches for a reason. So they can diverge :) If 
we don't want that, let's not play games with 2 branches. If we do want that, 
let's not cry about divergence.

 Java 8 as the minimum supported JVM version for branch_5x
 -

 Key: LUCENE-6722
 URL: https://issues.apache.org/jira/browse/LUCENE-6722
 Project: Lucene - Core
  Issue Type: Wish
Reporter: Shalin Shekhar Mangar
Priority: Blocker
 Fix For: 5.4


 Require Java 8 as the minimum supported JVM version for branch_5x.
 # Java 7 is already EOL'ed
 # Trunk is already at Java8
 # Important Solr components such as Jetty 9.3.x already require Java 8
 # Nashorn Javascript engine available in Java 8 is just so much faster and we 
 may see more usage of JS inside Solr (SOLR-7576 etc.)



--
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-6722) Java 8 as the minimum supported JVM version for branch_5x

2015-08-06 Thread Robert Muir (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-6722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14659767#comment-14659767
 ] 

Robert Muir commented on LUCENE-6722:
-

+1 Uwe

 Java 8 as the minimum supported JVM version for branch_5x
 -

 Key: LUCENE-6722
 URL: https://issues.apache.org/jira/browse/LUCENE-6722
 Project: Lucene - Core
  Issue Type: Wish
Reporter: Shalin Shekhar Mangar
Priority: Blocker
 Fix For: 5.4


 Require Java 8 as the minimum supported JVM version for branch_5x.
 # Java 7 is already EOL'ed
 # Trunk is already at Java8
 # Important Solr components such as Jetty 9.3.x already require Java 8
 # Nashorn Javascript engine available in Java 8 is just so much faster and we 
 may see more usage of JS inside Solr (SOLR-7576 etc.)



--
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-6699) Integrate lat/lon BKD and spatial3d

2015-08-06 Thread Karl Wright (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14659790#comment-14659790
 ] 

Karl Wright commented on LUCENE-6699:
-

[~mikemccand]: Turns out that my class is having problems properly relating to 
GeoWorld.  I'm going to have to make some modifications to make things play 
nicely.  Stay tuned.

 Integrate lat/lon BKD and spatial3d
 ---

 Key: LUCENE-6699
 URL: https://issues.apache.org/jira/browse/LUCENE-6699
 Project: Lucene - Core
  Issue Type: New Feature
Reporter: Michael McCandless
Assignee: Michael McCandless
 Attachments: Geo3DPacking.java, LUCENE-6699.patch


 I'm opening this for discussion, because I'm not yet sure how to do
 this integration, because of my ignorance about spatial in general and
 spatial3d in particular :)
 Our BKD tree impl is very fast at doing lat/lon shape intersection
 (bbox, polygon, soon distance: LUCENE-6698) against previously indexed
 points.
 I think to integrate with spatial3d, we would first need to record
 lat/lon/z into doc values.  Somewhere I saw discussion about how we
 could stuff all 3 into a single long value with acceptable precision
 loss?  Or, we could use BinaryDocValues?  We need all 3 dims available
 to do the fast per-hit query time filtering.
 But, second: what do we index into the BKD tree?  Can we just index
 earth surface lat/lon, and then at query time is spatial3d able to
 give me an enclosing surface lat/lon bbox for a 3d shape?  Or
 ... must we index all 3 dimensions into the BKD tree (seems like this
 could be somewhat wasteful)?



--
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-6708) TopFieldCollector sometimes calls Scorer.score() several times on the same doc

2015-08-06 Thread Adrien Grand (JIRA)


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

Adrien Grand resolved LUCENE-6708.
--
Resolution: Fixed

 TopFieldCollector sometimes calls Scorer.score() several times on the same doc
 --

 Key: LUCENE-6708
 URL: https://issues.apache.org/jira/browse/LUCENE-6708
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: 5.4

 Attachments: LUCENE-6708.patch


 If the sort spec includes a sort field that needs scores, and if 
 trackDocScores or trackMaxScore is set, then TopFieldCollectors may compute 
 the score several times on the same document, once to check whether the hit 
 is competitive, and once to update maxScore or to set the score on the 
 ScoreDoc.



--
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-6722) Java 8 as the minimum supported JVM version for branch_5x

2015-08-06 Thread Uwe Schindler (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-6722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14659658#comment-14659658
 ] 

Uwe Schindler commented on LUCENE-6722:
---

Hi,
we should not move the 5.x branch to Java 8 a this point. The differences 
between trunk and 5.x are not so big, so we can instead just switch to Lucene 6 
aka Trunk. Backporting all the Java 8 changes back to branch5x is a lot of 
work, because you have to pick lots of commits and backport them again.

I would like to prepare Lucene trunk to make it releaseable (e.g., fix the 
Stored/IndexDocument issues with docvalues) and then release 6.0 during the 
next year.

Most merge conflicts I see between trunk and 5.x are more related to 
Index/StorableDocument. The differences in Java code are minimal (we have some 
lambdas in trunk already, but nobody really did a big rewrite of that code). 
I backported some stuff that used Java 8 code in trunk, but that was quite 
simple.

So my vote:
-1 to move branch_5x to Java 8
+1 to work on releasing trunk as Lucene 6

 Java 8 as the minimum supported JVM version for branch_5x
 -

 Key: LUCENE-6722
 URL: https://issues.apache.org/jira/browse/LUCENE-6722
 Project: Lucene - Core
  Issue Type: Wish
Reporter: Shalin Shekhar Mangar
Priority: Blocker
 Fix For: 5.4


 Require Java 8 as the minimum supported JVM version for branch_5x.
 # Java 7 is already EOL'ed
 # Trunk is already at Java8
 # Important Solr components such as Jetty 9.3.x already require Java 8
 # Nashorn Javascript engine available in Java 8 is just so much faster and we 
 may see more usage of JS inside Solr (SOLR-7576 etc.)



--
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: 5.3 release

2015-08-06 Thread Jens Wille


Noble Paul [2015-08-05 17:09]:

If anything new must go into 5.3 release please communicate it
here
What are the chances of getting the second patch from SOLR-7639 
included in this release? It adds the missing pieces (support for 
the `boost` parameter and exclusion of the current document from the 
result set) to reach parity between MLTQParser and MLT Handler. With 
this patch applied (in combination with SOLR-7143) I could finally 
use the new QParser instead of the handler.


Best regards,
Jens

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

Re: [JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b60)

2015-08-06 Thread Adrien Grand

Hi Christine,

On Wed, Aug 5, 2015 at 11:42 PM, Christine Poerschke (BLOOMBERG/
LONDON) cpoersc...@bloomberg.net wrote:
 Locally changed createRandomIndex to add not the 1 but 2 documents before the 
 forceMerge. Still ends up with an unsorted segment:

Did you ensure that there is a reopen between these two documents are
added, so that we not only have 2 docs but also 2 segments? This can
be done eg. by calling iw.getReader().close(); on the
RandomIndexWriter.

-- 
Adrien

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

[jira] [Commented] (LUCENE-6722) Java 8 as the minimum supported JVM version for branch_5x

2015-08-06 Thread Mark Miller (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-6722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14659758#comment-14659758
 ] 

Mark Miller commented on LUCENE-6722:
-

As usual, Uwe gets it :)

+1

 Java 8 as the minimum supported JVM version for branch_5x
 -

 Key: LUCENE-6722
 URL: https://issues.apache.org/jira/browse/LUCENE-6722
 Project: Lucene - Core
  Issue Type: Wish
Reporter: Shalin Shekhar Mangar
Priority: Blocker
 Fix For: 5.4


 Require Java 8 as the minimum supported JVM version for branch_5x.
 # Java 7 is already EOL'ed
 # Trunk is already at Java8
 # Important Solr components such as Jetty 9.3.x already require Java 8
 # Nashorn Javascript engine available in Java 8 is just so much faster and we 
 may see more usage of JS inside Solr (SOLR-7576 etc.)



--
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: 5.3 release

2015-08-06 Thread Upayavira

I just committed this to trunk and the lucene_5x branch. However, when I
attempted to commit it to the lucene/dev/branches/lucene_solr_5_3
branch, I got this error:

svn: E175013: Commit failed (details follow):
svn: E175013: POST of '/repos/asf/!svn/me': 403 Forbidden
(http://svn.apache.org)
svn: E175013: Your commit message was left in a temporary file:
svn: E175013:'/Users/upayavira/apache/solr-5.3/svn-commit.tmp'

Any idea what's up? Anyone able to copy my SOLR-7666 line from either of
the other CHANGES.txt to the one in lucene_solr_5_3?

Thanks!

Upayavira

On Wed, Aug 5, 2015, at 04:30 PM, Upayavira wrote:
 I need to update CHANGES.txt to account for a number of bug fixes to the
 angular UI. I'll add a single entry to account for them all.
 
 Upayavira
 
 On Wed, Aug 5, 2015, at 04:15 PM, Steve Rowe wrote:
  I can work on setting up 5.3 release branch jobs on ASF Jenkins later
  today if Uwe doesn’t beat me to it. - Steve
  
   On Aug 5, 2015, at 11:09 AM, Noble Paul noble.p...@gmail.com wrote:
   
   I have created the lucene_solr_5_3 branch.
   If anything new must go into 5.3 release please communicate it here
   and commit to the new branch as well
   
   @uwe, @sarowe , can someone help me setup jenkins for the same.
   --Noble
   
   On Wed, Aug 5, 2015 at 7:27 PM, Varun Thacker
   varunthacker1...@gmail.com wrote:
   Hi Noble,
   
   I've just now committed SOLR-7818 and SOLR-7756. Both were bug fixes. I'm
   done from my side for 5.3
   
   On Wed, Aug 5, 2015 at 1:22 PM, Noble Paul noble.p...@gmail.com wrote:
   
   https://issues.apache.org/jira/browse/SOLR-7692 is slated to be a part
   of 5.3 . I'm wrapping it up.
   As you suggested , it makes sense to cut a branch and stabilize stuff.
   I shall cut a branch as soon as possible
   
   I guess there could be other things too.
   --Noble
   
   On Tue, Aug 4, 2015 at 6:55 PM, Adrien Grand jpou...@gmail.com wrote:
   Hi Noble,
   
   Which changes are delaying the branch creation? Even if everything
   that we want for 5.3 is not ready yet, it could be useful to create
   the branch now to help stabilize it? We could still merge the changes
   we want in after the branch is created.
   
   On Mon, Aug 3, 2015 at 4:52 PM, Noble Paul noble.p...@gmail.com 
   wrote:
   I may have to push the branch by a day or two. There are some more
   loose ends to be tied up from my side. Sorry for the trouble
   
   --Noble
   
   On Thu, Jul 30, 2015 at 12:48 PM, Adrien Grand jpou...@gmail.com
   wrote:
   +1 to releasing 5.3, and thanks for volunteering!
   
   On Mon, Jul 27, 2015 at 10:56 AM, Noble Paul noble.p...@gmail.com
   wrote:
   Hi,
   I would like to volunteer myself as the RM for 5.3 release. I plan 
   to
   cut the 5.3 release branch by next Monday (03/Aug).
   
   --
   -
   Noble Paul
   
   -
   To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
   For additional commands, e-mail: dev-h...@lucene.apache.org
   
   
   
   
   --
   Adrien
   
   -
   To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
   For additional commands, e-mail: dev-h...@lucene.apache.org
   
   
   
   
   --
   -
   Noble Paul
   
   -
   To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
   For additional commands, e-mail: dev-h...@lucene.apache.org
   
   
   
   
   --
   Adrien
   
   -
   To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
   For additional commands, e-mail: dev-h...@lucene.apache.org
   
   
   
   
   --
   -
   Noble Paul
   
   -
   To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
   For additional commands, e-mail: dev-h...@lucene.apache.org
   
   
   
   
   --
   
   
   Regards,
   Varun Thacker
   
   
   
   -- 
   -
   Noble Paul
  
  
  -
  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
  For additional commands, e-mail: dev-h...@lucene.apache.org
  
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 

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

[jira] [Updated] (LUCENE-6725) Reindex crashes the JVM

2015-08-06 Thread ASF subversion and git services (JIRA)


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

Jan Eerdekens updated LUCENE-6725:
--
Attachment: hs_err_pid18938.log

 Reindex crashes the JVM
 ---

 Key: LUCENE-6725
 URL: https://issues.apache.org/jira/browse/LUCENE-6725
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/index
Affects Versions: 3.5
 Environment: Solaris 10 1/13 (Update 11) Patchset applied.
 Oracle Solaris 10 8/11 s10s_u10wos_17b SPARC
 CPU:total 64 v9, popc, vis1, vis2, vis3, blk_init, cbcond, sun4v, niagara_plus
 Memory: 8k page, physical 25165824k(3240848k free)
 vm_info: Java HotSpot(TM) 64-Bit Server VM (24.75-b04) for solaris-sparc JRE 
 (1.7.0_75-b13)
Reporter: Jan Eerdekens
Priority: Blocker
 Attachments: hs_err_pid18938.log


 We're using Liferay which uses Lucene behind the screens to index things like 
 documents, web content, users, etc... . When we trigger a full reindex via 
 the Liferay Control Panel, which uses IndexWriter.deleteAll(), the JVM 
 crashes and generates a dump with the following message: 
 #
 # A fatal error has been detected by the Java Runtime Environment:
 #
 #  SIGSEGV (0xb) at pc=0x78de94a8, pid=18938, tid=2478
 #
 # JRE version: Java(TM) SE Runtime Environment (7.0_75-b13) (build 
 1.7.0_75-b13)
 # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.75-b04 mixed mode 
 solaris-sparc compressed oops)
 # Problematic frame:
 # J 5227 C2 
 org.apache.lucene.index.IndexFileNames.segmentFileName(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
  (44 bytes) @ 0x78de94a8 [0x78de9480+0x28]



--
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-6722) Java 8 as the minimum supported JVM version for branch_5x

2015-08-06 Thread Adrien Grand (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-6722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14659762#comment-14659762
 ] 

Adrien Grand commented on LUCENE-6722:
--

+1 to Uwe's plan

 Java 8 as the minimum supported JVM version for branch_5x
 -

 Key: LUCENE-6722
 URL: https://issues.apache.org/jira/browse/LUCENE-6722
 Project: Lucene - Core
  Issue Type: Wish
Reporter: Shalin Shekhar Mangar
Priority: Blocker
 Fix For: 5.4


 Require Java 8 as the minimum supported JVM version for branch_5x.
 # Java 7 is already EOL'ed
 # Trunk is already at Java8
 # Important Solr components such as Jetty 9.3.x already require Java 8
 # Nashorn Javascript engine available in Java 8 is just so much faster and we 
 may see more usage of JS inside Solr (SOLR-7576 etc.)



--
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-6708) TopFieldCollector sometimes calls Scorer.score() several times on the same doc


[ 
https://issues.apache.org/jira/browse/LUCENE-6708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14659771#comment-14659771
 ] 

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

Commit 1694435 from [~jpountz] in branch 'dev/trunk'
[ https://svn.apache.org/r1694435 ]

LUCENE-6708: TopFieldCollector does not compute the score several times on the 
same document anymore.

 TopFieldCollector sometimes calls Scorer.score() several times on the same doc
 --

 Key: LUCENE-6708
 URL: https://issues.apache.org/jira/browse/LUCENE-6708
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Attachments: LUCENE-6708.patch


 If the sort spec includes a sort field that needs scores, and if 
 trackDocScores or trackMaxScore is set, then TopFieldCollectors may compute 
 the score several times on the same document, once to check whether the hit 
 is competitive, and once to update maxScore or to set the score on the 
 ScoreDoc.



--
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-6725) Reindex crashes the JVM

2015-08-06 Thread Robert Muir (JIRA)


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

Robert Muir updated LUCENE-6725:

Priority: Minor  (was: Blocker)

 Reindex crashes the JVM
 ---

 Key: LUCENE-6725
 URL: https://issues.apache.org/jira/browse/LUCENE-6725
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/index
Affects Versions: 3.5
 Environment: Solaris 10 1/13 (Update 11) Patchset applied.
 Oracle Solaris 10 8/11 s10s_u10wos_17b SPARC
 CPU:total 64 v9, popc, vis1, vis2, vis3, blk_init, cbcond, sun4v, niagara_plus
 Memory: 8k page, physical 25165824k(3240848k free)
 vm_info: Java HotSpot(TM) 64-Bit Server VM (24.75-b04) for solaris-sparc JRE 
 (1.7.0_75-b13)
Reporter: Jan Eerdekens
Priority: Minor
 Attachments: hs_err_pid18938.log


 We're using Liferay which uses Lucene behind the screens to index things like 
 documents, web content, users, etc... . When we trigger a full reindex via 
 the Liferay Control Panel, which uses IndexWriter.deleteAll(), the JVM 
 crashes and generates a dump with the following message: 
 #
 # A fatal error has been detected by the Java Runtime Environment:
 #
 #  SIGSEGV (0xb) at pc=0x78de94a8, pid=18938, tid=2478
 #
 # JRE version: Java(TM) SE Runtime Environment (7.0_75-b13) (build 
 1.7.0_75-b13)
 # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.75-b04 mixed mode 
 solaris-sparc compressed oops)
 # Problematic frame:
 # J 5227 C2 
 org.apache.lucene.index.IndexFileNames.segmentFileName(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
  (44 bytes) @ 0x78de94a8 [0x78de9480+0x28]



--
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-6708) TopFieldCollector sometimes calls Scorer.score() several times on the same doc

2015-08-06 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-6708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14659788#comment-14659788
 ] 

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

Commit 1694442 from [~jpountz] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1694442 ]

LUCENE-6708: TopFieldCollector does not compute the score several times on the 
same document anymore.

 TopFieldCollector sometimes calls Scorer.score() several times on the same doc
 --

 Key: LUCENE-6708
 URL: https://issues.apache.org/jira/browse/LUCENE-6708
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: 5.4

 Attachments: LUCENE-6708.patch


 If the sort spec includes a sort field that needs scores, and if 
 trackDocScores or trackMaxScore is set, then TopFieldCollectors may compute 
 the score several times on the same document, once to check whether the hit 
 is competitive, and once to update maxScore or to set the score on the 
 ScoreDoc.



--
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-6725) Reindex crashes the JVM

2015-08-06 Thread Dawid Weiss (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14659807#comment-14659807
 ] 

Dawid Weiss commented on LUCENE-6725:
-

It looks like a JVM issue, not Lucene issue. We don't test against Solaris 
because we don't have access to a test machine running this OS.
Could you try running a full suite of Lucene test on those (test) machines 
running Solaris? Do the test pass (run it 10 times, they're randomized).

If you can reproduce the problem (more or less reliably) than the hotspot-dev 
mailing list would be more appropriate to report this issue, but you can also 
post it here, we'll pass the information along.

 Reindex crashes the JVM
 ---

 Key: LUCENE-6725
 URL: https://issues.apache.org/jira/browse/LUCENE-6725
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/index
Affects Versions: 3.5
 Environment: Solaris 10 1/13 (Update 11) Patchset applied.
 Oracle Solaris 10 8/11 s10s_u10wos_17b SPARC
 CPU:total 64 v9, popc, vis1, vis2, vis3, blk_init, cbcond, sun4v, niagara_plus
 Memory: 8k page, physical 25165824k(3240848k free)
 vm_info: Java HotSpot(TM) 64-Bit Server VM (24.75-b04) for solaris-sparc JRE 
 (1.7.0_75-b13)
Reporter: Jan Eerdekens
Priority: Minor
 Attachments: hs_err_pid18938.log


 We're using Liferay which uses Lucene behind the screens to index things like 
 documents, web content, users, etc... . When we trigger a full reindex via 
 the Liferay Control Panel, which uses IndexWriter.deleteAll(), the JVM 
 crashes and generates a dump with the following message: 
 #
 # A fatal error has been detected by the Java Runtime Environment:
 #
 #  SIGSEGV (0xb) at pc=0x78de94a8, pid=18938, tid=2478
 #
 # JRE version: Java(TM) SE Runtime Environment (7.0_75-b13) (build 
 1.7.0_75-b13)
 # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.75-b04 mixed mode 
 solaris-sparc compressed oops)
 # Problematic frame:
 # J 5227 C2 
 org.apache.lucene.index.IndexFileNames.segmentFileName(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
  (44 bytes) @ 0x78de94a8 [0x78de9480+0x28]



--
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-7666) Umbrella ticket for Angular JS post-5.2.1 issues

2015-08-06 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14659751#comment-14659751
 ] 

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

Commit 1694430 from [~upayavira] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1694430 ]

SOLR-7666: Update CHANGES.txt for fixes to AngularJS admin UI

 Umbrella ticket for Angular JS post-5.2.1 issues
 

 Key: SOLR-7666
 URL: https://issues.apache.org/jira/browse/SOLR-7666
 Project: Solr
  Issue Type: New Feature
  Components: UI
Affects Versions: 5.3, Trunk
Reporter: Erick Erickson
Assignee: Upayavira

 As of Solr 5.2.1, there's a new admin UI available that has been written 
 almost entirely by Upayavira (thanks!) over the last several months. It's 
 written in Angular JS with an eye towards enhancement/maintainability. The 
 default UI is still the old version, but you can access the new version by 
 going to http://sever:port/solr/index.html. There are a couple of fixes 
 between 5.2.0 and 5.2.1, so please use either a fresh 5x checkout, trunk, or 
 5.2.1
 The expectation is that in Solr 5.3, the new code will become the default 
 with the old UI deprecated and eventually removed.
 So it would be a great help if volunteers could give the new UI a spin. It 
 should look much the same as the current one at the start, but evolve into 
 something much more interesting and more cloud-friendly. Of course all the 
 new UI code will always be available on trunk/6.0 too, and the up-to-date 
 code will always be on both the trunk and 5x branches.
 Please provide feedback on the user's (or dev) lists about anything you find 
 that doesn't work, or enhancements you'd like to see (or, even better, 
 contribute). If you raise a JIRA, please link it to this one so I can keep 
 track of what needs to be committed. If linking JIRAs is a mystery just add a 
 comment to this JIRA referencing the new JIRA and we can take care of it.
 Please do _not_ attach patches to this JIRA, it'll be much easier to keep 
 track of everything if the patches are attached to sub-JIRAs.
 And a big thanks to Upayavira for this work!



--
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-6722) Java 8 as the minimum supported JVM version for branch_5x

2015-08-06 Thread Mark Miller (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-6722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14659769#comment-14659769
 ] 

Mark Miller commented on LUCENE-6722:
-

bq. This leads us to an interesting question – is software for users or for 
developers?

In my experience, that depends on the ratio of devs that are paid to work on 
the project as a day job.

 Java 8 as the minimum supported JVM version for branch_5x
 -

 Key: LUCENE-6722
 URL: https://issues.apache.org/jira/browse/LUCENE-6722
 Project: Lucene - Core
  Issue Type: Wish
Reporter: Shalin Shekhar Mangar
Priority: Blocker
 Fix For: 5.4


 Require Java 8 as the minimum supported JVM version for branch_5x.
 # Java 7 is already EOL'ed
 # Trunk is already at Java8
 # Important Solr components such as Jetty 9.3.x already require Java 8
 # Nashorn Javascript engine available in Java 8 is just so much faster and we 
 may see more usage of JS inside Solr (SOLR-7576 etc.)



--
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-6725) Reindex crashes the JVM


[ 
https://issues.apache.org/jira/browse/LUCENE-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14659774#comment-14659774
 ] 

Jan Eerdekens commented on LUCENE-6725:
---

Currently reproducing this behaviour is difficult as we're seeing the following:

- the problem seemed to occur consistently on our production environment (but 
we can't tried it a lot there for obvious reasons)
  - after installing a monitoring tool today (a Java agent) the next reindex 
didn't crash the JVM
- the problem (at first) didn't happen on our pre-production environment (which 
is the most similar with regards to CPU/memory/... to production)
  - in the weeks after discovering the problem, it also happened once on the 
pre-production environment, but on retrying the reindex afterwards it didn't 
happen again
- the problem isn't reproducible on our test environment or local machines 
(Apple MacBook Pro's) 

We also created a small standalone Java tool that is also able to do the 
IndexWriter.deleteAll() call on a copy of the index, but that doesn't trigger 
the same JVM crash on our production and pre-production environments (using in 
the same JVM version).

 Reindex crashes the JVM
 ---

 Key: LUCENE-6725
 URL: https://issues.apache.org/jira/browse/LUCENE-6725
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/index
Affects Versions: 3.5
 Environment: Solaris 10 1/13 (Update 11) Patchset applied.
 Oracle Solaris 10 8/11 s10s_u10wos_17b SPARC
 CPU:total 64 v9, popc, vis1, vis2, vis3, blk_init, cbcond, sun4v, niagara_plus
 Memory: 8k page, physical 25165824k(3240848k free)
 vm_info: Java HotSpot(TM) 64-Bit Server VM (24.75-b04) for solaris-sparc JRE 
 (1.7.0_75-b13)
Reporter: Jan Eerdekens
Priority: Minor
 Attachments: hs_err_pid18938.log


 We're using Liferay which uses Lucene behind the screens to index things like 
 documents, web content, users, etc... . When we trigger a full reindex via 
 the Liferay Control Panel, which uses IndexWriter.deleteAll(), the JVM 
 crashes and generates a dump with the following message: 
 #
 # A fatal error has been detected by the Java Runtime Environment:
 #
 #  SIGSEGV (0xb) at pc=0x78de94a8, pid=18938, tid=2478
 #
 # JRE version: Java(TM) SE Runtime Environment (7.0_75-b13) (build 
 1.7.0_75-b13)
 # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.75-b04 mixed mode 
 solaris-sparc compressed oops)
 # Problematic frame:
 # J 5227 C2 
 org.apache.lucene.index.IndexFileNames.segmentFileName(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
  (44 bytes) @ 0x78de94a8 [0x78de9480+0x28]



--
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-6708) TopFieldCollector sometimes calls Scorer.score() several times on the same doc

2015-08-06 Thread Adrien Grand (JIRA)


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

Adrien Grand updated LUCENE-6708:
-
Fix Version/s: 5.4

 TopFieldCollector sometimes calls Scorer.score() several times on the same doc
 --

 Key: LUCENE-6708
 URL: https://issues.apache.org/jira/browse/LUCENE-6708
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: 5.4

 Attachments: LUCENE-6708.patch


 If the sort spec includes a sort field that needs scores, and if 
 trackDocScores or trackMaxScore is set, then TopFieldCollectors may compute 
 the score several times on the same document, once to check whether the hit 
 is competitive, and once to update maxScore or to set the score on the 
 ScoreDoc.



--
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-6725) Reindex crashes the JVM

2015-08-06 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14659794#comment-14659794
 ] 

Jan Eerdekens commented on LUCENE-6725:
---

Problem seems (very) similar to what this guy reported in the mailing list: 
http://mail-archives.apache.org/mod_mbox/lucene-java-user/201306.mbox/%3CCA+9jHe=H9-wun5FedByRr5GuKKt1O7f=xh3nvgbikkb8wt1...@mail.gmail.com%3E

 Reindex crashes the JVM
 ---

 Key: LUCENE-6725
 URL: https://issues.apache.org/jira/browse/LUCENE-6725
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/index
Affects Versions: 3.5
 Environment: Solaris 10 1/13 (Update 11) Patchset applied.
 Oracle Solaris 10 8/11 s10s_u10wos_17b SPARC
 CPU:total 64 v9, popc, vis1, vis2, vis3, blk_init, cbcond, sun4v, niagara_plus
 Memory: 8k page, physical 25165824k(3240848k free)
 vm_info: Java HotSpot(TM) 64-Bit Server VM (24.75-b04) for solaris-sparc JRE 
 (1.7.0_75-b13)
Reporter: Jan Eerdekens
Priority: Minor
 Attachments: hs_err_pid18938.log


 We're using Liferay which uses Lucene behind the screens to index things like 
 documents, web content, users, etc... . When we trigger a full reindex via 
 the Liferay Control Panel, which uses IndexWriter.deleteAll(), the JVM 
 crashes and generates a dump with the following message: 
 #
 # A fatal error has been detected by the Java Runtime Environment:
 #
 #  SIGSEGV (0xb) at pc=0x78de94a8, pid=18938, tid=2478
 #
 # JRE version: Java(TM) SE Runtime Environment (7.0_75-b13) (build 
 1.7.0_75-b13)
 # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.75-b04 mixed mode 
 solaris-sparc compressed oops)
 # Problematic frame:
 # J 5227 C2 
 org.apache.lucene.index.IndexFileNames.segmentFileName(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
  (44 bytes) @ 0x78de94a8 [0x78de9480+0x28]



--
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: 5.3 release

2015-08-06 Thread Uwe Schindler

This should work without error 503. Maybe a temporary problem with subversion 
server?

Uwe

Am 6. August 2015 11:49:25 MESZ, schrieb Upayavira u...@odoko.co.uk:
I just committed this to trunk and the lucene_5x branch. However, when
I
attempted to commit it to the lucene/dev/branches/lucene_solr_5_3
branch, I got this error:

svn: E175013: Commit failed (details follow):
svn: E175013: POST of '/repos/asf/!svn/me': 403 Forbidden
(http://svn.apache.org)
svn: E175013: Your commit message was left in a temporary file:
svn: E175013:'/Users/upayavira/apache/solr-5.3/svn-commit.tmp'

Any idea what's up? Anyone able to copy my SOLR-7666 line from either
of
the other CHANGES.txt to the one in lucene_solr_5_3?

Thanks!

Upayavira

On Wed, Aug 5, 2015, at 04:30 PM, Upayavira wrote:
 I need to update CHANGES.txt to account for a number of bug fixes to
the
 angular UI. I'll add a single entry to account for them all.
 
 Upayavira
 
 On Wed, Aug 5, 2015, at 04:15 PM, Steve Rowe wrote:
  I can work on setting up 5.3 release branch jobs on ASF Jenkins
later
  today if Uwe doesn’t beat me to it. - Steve
  
   On Aug 5, 2015, at 11:09 AM, Noble Paul noble.p...@gmail.com
wrote:
   
   I have created the lucene_solr_5_3 branch.
   If anything new must go into 5.3 release please communicate it
here
   and commit to the new branch as well
   
   @uwe, @sarowe , can someone help me setup jenkins for the same.
   --Noble
   
   On Wed, Aug 5, 2015 at 7:27 PM, Varun Thacker
   varunthacker1...@gmail.com wrote:
   Hi Noble,
   
   I've just now committed SOLR-7818 and SOLR-7756. Both were bug
fixes. I'm
   done from my side for 5.3
   
   On Wed, Aug 5, 2015 at 1:22 PM, Noble Paul
noble.p...@gmail.com wrote:
   
   https://issues.apache.org/jira/browse/SOLR-7692 is slated to be
a part
   of 5.3 . I'm wrapping it up.
   As you suggested , it makes sense to cut a branch and stabilize
stuff.
   I shall cut a branch as soon as possible
   
   I guess there could be other things too.
   --Noble
   
   On Tue, Aug 4, 2015 at 6:55 PM, Adrien Grand
jpou...@gmail.com wrote:
   Hi Noble,
   
   Which changes are delaying the branch creation? Even if
everything
   that we want for 5.3 is not ready yet, it could be useful to
create
   the branch now to help stabilize it? We could still merge the
changes
   we want in after the branch is created.
   
   On Mon, Aug 3, 2015 at 4:52 PM, Noble Paul
noble.p...@gmail.com wrote:
   I may have to push the branch by a day or two. There are some
more
   loose ends to be tied up from my side. Sorry for the trouble
   
   --Noble
   
   On Thu, Jul 30, 2015 at 12:48 PM, Adrien Grand
jpou...@gmail.com
   wrote:
   +1 to releasing 5.3, and thanks for volunteering!
   
   On Mon, Jul 27, 2015 at 10:56 AM, Noble Paul
noble.p...@gmail.com
   wrote:
   Hi,
   I would like to volunteer myself as the RM for 5.3 release.
I plan to
   cut the 5.3 release branch by next Monday (03/Aug).
   
   --
   -
   Noble Paul
   
  
-
   To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
   For additional commands, e-mail: dev-h...@lucene.apache.org
   
   
   
   
   --
   Adrien
   
  
-
   To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
   For additional commands, e-mail: dev-h...@lucene.apache.org
   
   
   
   
   --
   -
   Noble Paul
   
  
-
   To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
   For additional commands, e-mail: dev-h...@lucene.apache.org
   
   
   
   
   --
   Adrien
   
  
-
   To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
   For additional commands, e-mail: dev-h...@lucene.apache.org
   
   
   
   
   --
   -
   Noble Paul
   
  
-
   To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
   For additional commands, e-mail: dev-h...@lucene.apache.org
   
   
   
   
   --
   
   
   Regards,
   Varun Thacker
   
   
   
   -- 
   -
   Noble Paul
  
  
 
-
  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
  For additional commands, e-mail: dev-h...@lucene.apache.org
  
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 

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

[jira] [Commented] (SOLR-7837) Implement BasicAuth Authentication Plugin


[ 
https://issues.apache.org/jira/browse/SOLR-7837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660744#comment-14660744
 ] 

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

Commit 1694567 from [~noble.paul] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1694567 ]

SOLR-7837: some more java 7 issues

 Implement BasicAuth Authentication Plugin
 -

 Key: SOLR-7837
 URL: https://issues.apache.org/jira/browse/SOLR-7837
 Project: Solr
  Issue Type: Sub-task
Reporter: Noble Paul
Assignee: 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-7877) TestAuthenticationFramework.testBasics to preserve/restore the original request(Username|Password)

2015-08-06 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660818#comment-14660818
 ] 

Christine Poerschke commented on SOLR-7877:
---

to do still (tomorrow/Friday morning London time): merge {{branch_5x}} (or 
should it be {{trunk}}?) commit to {{branches/lucene_solr_5_3}}

 TestAuthenticationFramework.testBasics to preserve/restore the original 
 request(Username|Password)
 --

 Key: SOLR-7877
 URL: https://issues.apache.org/jira/browse/SOLR-7877
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.3, Trunk
Reporter: Noble Paul
Assignee: Christine Poerschke
Priority: Blocker
 Attachments: SOLR-7877.patch


 {code}
 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13742/
 Java: 32bit/jdk1.8.0_60-ea-b24 -server -XX:+UseG1GC
 1 tests failed.
 FAILED:  
 org.apache.solr.cloud.TestAuthenticationFramework.testCollectionCreateWithoutCoresThenDelete
 Error Message:
 Error from server at http://127.0.0.1:51573/solr: Expected mime type 
 application/octet-stream but got text/html. html head meta 
 http-equiv=Content-Type content=text/html;charset=ISO-8859-1/ 
 titleError 401 /title /head body h2HTTP ERROR: 401/h2 pProblem 
 accessing /solr/admin/collections. Reason: preUnauthorized 
 request/pre/p hr /ismallPowered by Jetty:///small/i /body 
 /html
 Stack Trace:
 org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
 from server at http://127.0.0.1:51573/solr: Expected mime type 
 application/octet-stream but got text/html. html
 head
 meta http-equiv=Content-Type content=text/html;charset=ISO-8859-1/
 titleError 401 /title
 /head
 body
 h2HTTP ERROR: 401/h2
 pProblem accessing /solr/admin/collections. Reason:
 preUnauthorized request/pre/p
 hr /ismallPowered by Jetty:///small/i
 /body
 /html
 at 
 __randomizedtesting.SeedInfo.seed([A454441B503006EB:17918BDA5F48D5AA]:0)
 at 
 org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:528)
 at 
 org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234)
 at 
 org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226)
 at 
 org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376)
 at 
 org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328)
 at 
 org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
 at 
 org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856)
 at 
 org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799)
 at 
 org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
 at 
 org.apache.solr.cloud.MiniSolrCloudCluster.makeCollectionsRequest(MiniSolrCloudCluster.java:349)
 at 
 org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:333)
 at 
 org.apache.solr.cloud.TestMiniSolrCloudCluster.createCollection(TestMiniSolrCloudCluster.java:115)
 at 
 org.apache.solr.cloud.TestMiniSolrCloudCluster.testCollectionCreateWithoutCoresThenDelete(TestMiniSolrCloudCluster.java:298)
 {code}



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

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

[jira] [Commented] (SOLR-7875) Speedup SolrQueryTimeoutImpl


[ 
https://issues.apache.org/jira/browse/SOLR-7875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660833#comment-14660833
 ] 

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

Commit 1694575 from [~tomasflobbe] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1694575 ]

SOLR-7875: Speedup SolrQueryTimeoutImpl

 Speedup SolrQueryTimeoutImpl
 

 Key: SOLR-7875
 URL: https://issues.apache.org/jira/browse/SOLR-7875
 Project: Solr
  Issue Type: Improvement
Affects Versions: 5.0, 5.1, 5.2, 5.2.1
Reporter: Tomás Fernández Löbbe
Assignee: Tomás Fernández Löbbe
 Fix For: 5.3

 Attachments: SOLR-7875.patch


 SolrQueryTimeoutImpl can be slow for some use cases, for example, in cases 
 with many terms, where shouldExit() is called many times. 
 See http://search-lucene.com/m/l6pAi1HLrodLhNUd



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

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

[jira] [Assigned] (SOLR-7838) Implement a RuleBasedAuthorizationPlugin


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

Noble Paul reassigned SOLR-7838:


Assignee: Noble Paul

 Implement a RuleBasedAuthorizationPlugin
 

 Key: SOLR-7838
 URL: https://issues.apache.org/jira/browse/SOLR-7838
 Project: Solr
  Issue Type: Sub-task
Reporter: Noble Paul
Assignee: Noble Paul

 h2. authorization plugin
 This would store the roles of various users and their privileges in ZK
 sample authorization.json
 {code:javascript}
 {
   authorization: {
 class: solr.ZKAuthorization,
roles :{
   john : [admin]
   david : [guest,dev]
}
 permissions: {
collection-edit: {
  role: admin 
},
coreadmin:{
  role:admin
},
config-edit: {
  //all collections
  role: admin,
  method:POST
},
schema-edit: {
  roles: admin,
  method:POST
},
update: {
  //all collections
  role: dev
},
   mycoll_update: {
 collection: mycoll,
 path:[/update/*],
 role: [somebody]
   }
 }
   }
 }
 {code} 
 This also supports editing of the configuration through APIs
 Example 1: add or remove roles
 {code}
 curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
 'Content-type:application/json' -d '{ 
   set-user-role: {tom:[admin,dev},
   set-user-role: {harry:null}
 }'
 {code}
  
 Example 2: add or remove permissions
 {code}
 curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
 'Content-type:application/json'-d '{ 
   set-permission: { name:a-custom-permission-name,
   collection:gettingstarted,
   path:/handler-name,
   before: name-of-another-permission
},
  delete-permission:permission-name
 }'
 {code}
 Please note that you have to replace the whole permission each time it is 
 edited. The API does not support editing one property at a time. Use the 
 'before' property to re-order your permissions
 Example 3: Restrict collection admin operations (writes only) to be performed 
 by an admin only
 {code}
 curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
 'Content-type:application/json' -d '{
 set-permission : {name:collection-admin-edit, role:admin}}'
 {code}



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

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

[jira] [Updated] (SOLR-7838) Implement a RuleBasedAuthorizationPlugin


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

Noble Paul updated SOLR-7838:
-
Description: 
h2. authorization plugin

This would store the roles of various users and their privileges in ZK

sample authorization.json

{code:javascript}
{
  authorization: {
class: solr.ZKAuthorization,
   roles :{
  john : [admin]
  david : [guest,dev]
   }
permissions: {
   collection-edit: {
 role: admin 
   },
   coreadmin:{
 role:admin
   },
   config-edit: {
 //all collections
 role: admin,
 method:POST
   },
   schema-edit: {
 roles: admin,
 method:POST
   },
   update: {
 //all collections
 role: dev
   },
  mycoll_update: {
collection: mycoll,
path:[/update/*],
role: [somebody]
  }
}
  }
}
{code} 
This also supports editing of the configuration through APIs
Example 1: add or remove roles

{code}
curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
'Content-type:application/json' -d '{ 

  set-user-role: {tom:[admin,dev},

  set-user-role: {harry:null}

}'
{code}
 

Example 2: add or remove permissions


{code}
curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
'Content-type:application/json'-d '{ 

  set-permission: { name:a-custom-permission-name,

  collection:gettingstarted,

  path:/handler-name,

  before: name-of-another-permission

   },

 delete-permission:permission-name

}'
{code}
Please note that you have to replace the whole permission each time it is 
edited. The API does not support editing one property at a time. Use the 
'before' property to re-order your permissions

Example 3: Restrict collection admin operations (writes only) to be performed 
by an admin only

{code}
curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
'Content-type:application/json' -d '{

set-permission : {name:collection-admin-edit, role:admin}}'

{code}

 Implement a RuleBasedAuthorizationPlugin
 

 Key: SOLR-7838
 URL: https://issues.apache.org/jira/browse/SOLR-7838
 Project: Solr
  Issue Type: Sub-task
Reporter: Noble Paul

 h2. authorization plugin
 This would store the roles of various users and their privileges in ZK
 sample authorization.json
 {code:javascript}
 {
   authorization: {
 class: solr.ZKAuthorization,
roles :{
   john : [admin]
   david : [guest,dev]
}
 permissions: {
collection-edit: {
  role: admin 
},
coreadmin:{
  role:admin
},
config-edit: {
  //all collections
  role: admin,
  method:POST
},
schema-edit: {
  roles: admin,
  method:POST
},
update: {
  //all collections
  role: dev
},
   mycoll_update: {
 collection: mycoll,
 path:[/update/*],
 role: [somebody]
   }
 }
   }
 }
 {code} 
 This also supports editing of the configuration through APIs
 Example 1: add or remove roles
 {code}
 curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
 'Content-type:application/json' -d '{ 
   set-user-role: {tom:[admin,dev},
   set-user-role: {harry:null}
 }'
 {code}
  
 Example 2: add or remove permissions
 {code}
 curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
 'Content-type:application/json'-d '{ 
   set-permission: { name:a-custom-permission-name,
   collection:gettingstarted,
   path:/handler-name,
   before: name-of-another-permission
},
  delete-permission:permission-name
 }'
 {code}
 Please note that you have to replace the whole permission each time it is 
 edited. The API does not support editing one property at a time. Use the 
 'before' property to re-order your permissions
 Example 3: Restrict collection admin operations (writes only) to be performed 
 by an admin only
 {code}
 curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
 'Content-type:application/json' -d '{
 set-permission : {name:collection-admin-edit, role:admin}}'
 {code}



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

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

[jira] [Created] (SOLR-7894) Solr Forgets Core Setup And Throws Fake Errors Each Time It Starts

Aaron Greenspan created SOLR-7894:
-

 Summary: Solr Forgets Core Setup And Throws Fake Errors Each Time 
It Starts
 Key: SOLR-7894
 URL: https://issues.apache.org/jira/browse/SOLR-7894
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.2.1
 Environment: CentOS 6.3
Linux 2.6.32-504.23.4.el6.x86_64 #1 SMP Tue Jun 9 20:57:37 UTC 2015 x86_64 
x86_64 x86_64 GNU/Linux
Reporter: Aaron Greenspan


I have two Solr cores that I need to use. Their folders are already set up with 
appropriate permissions in the /solr subdirectory I'm using. Nevertheless, each 
time I start and stop Solr, the following ridiculous dance has to take place:

1. I go to the web interface on port 8983.
2. No cores are listed. I press the Add Core button.
3. I type in the name of the first of the two cores I want to re-add that was 
just there when the process was running previously in the name and 
instanceDir fields. I leave the other fields with their default values.
4. I press the blue Add Core button.
5. I get the following red error message: Error CREATEing SolrCore '[core 
name]': Could not create a new core in /home/solr/server/solr/[core name]/as 
another core is already defined there
6. I press the gray Cancel button.
7. I click Java Properties on the left side, or some other link in the 
administrative interface, just to get off the cores page.
8. I go back to the cores page.
9. The core is listed and is working fine.

This is absurd.

For one thing, I shouldn't have to do *anything*. Either by scanning the 
directory for the annoying-as-hell XML configuration files or some other 
method, it should remember the cores that were just there. But even assuming 
that's impossible for some reason (which it's not), I should not be getting a 
technically true but practically useless and misleading error message that 
suggests that adding the core *didn't* work when in fact it *did*.



--
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-7897) Solr Can't Find Singular Versus Plural Words

Aaron Greenspan created SOLR-7897:
-

 Summary: Solr Can't Find Singular Versus Plural Words
 Key: SOLR-7897
 URL: https://issues.apache.org/jira/browse/SOLR-7897
 Project: Solr
  Issue Type: Bug
  Components: search
Affects Versions: 5.2.1
Reporter: Aaron Greenspan


I have a core with lots of company names in it. If I search for Uber 
Technologies, Inc. then great. It's an exact match. If I search for Uber 
Technology then no results found.

Do I really have to teach Solr that you drop the y and add ies somehow to 
make words plural? I thought it somehow knew how to do that already... If it 
doesn't, it should.



--
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-7894) Solr Forgets Core Setup And Throws Fake Errors Each Time It Starts

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

Aaron Greenspan updated SOLR-7894:
--
Description:
I have two Solr cores that I need to use. Their folders are already set up with
appropriate permissions in the /solr subdirectory I'm using. Nevertheless, each
time I start and stop Solr, the following ridiculous dance has to take place:

1. I go to the web interface on port 8983.
2. No cores are listed. I press the Add Core button.
3. I type in the name of the first of the two cores I want to re-add that was
just there when the process was running previously in the name and
instanceDir fields. I leave the other fields with their default values.
4. I press the blue Add Core button.
5. I get the following red error message: Error CREATEing SolrCore '[core
name]': Could not create a new core in /home/solr/server/solr/[core name]/as
another core is already defined there.
6. I press the gray Cancel button.
7. I click Java Properties on the left side, or some other link in the
administrative interface, just to get off the cores page.
8. I go back to the cores page.
9. The core is listed and is working fine.

This is absurd.

For one thing, I shouldn't have to do *anything*. Either by scanning the
directory for the annoying-as-hell XML configuration files or some other
method, it should remember the cores that were just there. But even assuming
that's impossible for some reason (which it's not), I should not be getting a
technically true but practically useless and misleading error message that
suggests that adding the core *didn't* work when in fact it *did*.

was:
I have two Solr cores that I need to use. Their folders are already set up with
appropriate permissions in the /solr subdirectory I'm using. Nevertheless, each
time I start and stop Solr, the following ridiculous dance has to take place:

1. I go to the web interface on port 8983.
2. No cores are listed. I press the Add Core button.
3. I type in the name of the first of the two cores I want to re-add that was
just there when the process was running previously in the name and
instanceDir fields. I leave the other fields with their default values.
4. I press the blue Add Core button.
5. I get the following red error message: Error CREATEing SolrCore '[core
name]': Could not create a new core in /home/solr/server/solr/[core name]/as
another core is already defined there
6. I press the gray Cancel button.
7. I click Java Properties on the left side, or some other link in the
administrative interface, just to get off the cores page.
8. I go back to the cores page.
9. The core is listed and is working fine.

This is absurd.

Solr Forgets Core Setup And Throws Fake Errors Each Time It Starts
--

Key: SOLR-7894
URL: https://issues.apache.org/jira/browse/SOLR-7894
Project: Solr
Issue Type: Bug
Affects Versions: 5.2.1
Environment: CentOS 6.3
Linux 2.6.32-504.23.4.el6.x86_64 #1 SMP Tue Jun 9 20:57:37 UTC 2015 x86_64
x86_64 x86_64 GNU/Linux
Reporter: Aaron Greenspan

I have two Solr cores that I need to use. Their folders are already set up
with appropriate permissions in the /solr subdirectory I'm using.
Nevertheless, each time I start and stop Solr, the following ridiculous dance
has to take place:
1. I go to the web interface on port 8983.
2. No cores are listed. I press the Add Core button.
3. I type in the name of the first of the two cores I want to re-add that was
just there when the process was running previously in the name and
instanceDir fields. I leave the other fields with their default values.
4. I press the blue Add Core button.
5. I get the following red error message: Error CREATEing SolrCore '[core
name]': Could not create a new core in /home/solr/server/solr/[core name]/as
another core is already defined there.
6. I press the gray Cancel button.
7. I click Java Properties on the left side, or some other link in the
administrative interface, just to get off the cores page.
8. I go back to the cores page.
9. The core is listed and is working fine.
This is absurd.
For one thing, I shouldn't have to do *anything*. Either by scanning the
directory for the annoying-as-hell XML configuration files or some other
method, it should remember the cores that were just there. But even assuming
that's

[jira] [Commented] (SOLR-7896) Solr Administrative Interface Lacks Password Protection

2015-08-06 Thread Shalin Shekhar Mangar (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-7896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661334#comment-14661334
]

Shalin Shekhar Mangar commented on SOLR-7896:
-

You are in luck. Basic authentication has been added for the next release
(5.3). See SOLR-7837.

Also, Solr has supported SSL for a while now, see
https://cwiki.apache.org/confluence/display/solr/Enabling+SSL

Solr Administrative Interface Lacks Password Protection
---

Key: SOLR-7896
URL: https://issues.apache.org/jira/browse/SOLR-7896
Project: Solr
Issue Type: Bug
Components: security, web gui
Affects Versions: 5.2.1
Reporter: Aaron Greenspan
Priority: Critical

Out of the box, the Solr interface should require an administrative password
that the user is required to set. Apparently there are ways of configuring
Jetty to do this with HTTP AUTH or whatever. I'm a moderately experienced
Linux admin and a programmer; I've tried, numerous times, and I've not once
been able to get it to work. The point is this, though:
*No one should have to try to get their Solr instance to support password
authentication and preferably SSL (even if it's just with a self-signed
certificate). Solr is designed to store huge amounts of data and is therefore
a likely target for malicious users.*
This needs to be addressed! It's 2015 and Solr is on version 5!

--
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-7894) Solr Forgets Core Setup And Throws Fake Errors Each Time It Starts

[
https://issues.apache.org/jira/browse/SOLR-7894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661346#comment-14661346
]

Shawn Heisey commented on SOLR-7894:

At the moment you use the Add Core button, the core.properties file must NOT
exist. Adding the core will create that file. I think that these facts are
not well-documented.

The core.properties file is how the core is re-discovered when Solr is
restarted.

https://wiki.apache.org/solr/Solr.xml%204.4%20and%20beyond

Solr Forgets Core Setup And Throws Fake Errors Each Time It Starts
--

--
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-7896) Solr Administrative Interface Lacks Password Protection

[
https://issues.apache.org/jira/browse/SOLR-7896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661341#comment-14661341
]

Aaron Greenspan edited comment on SOLR-7896 at 8/7/15 5:23 AM:
---

It's all well and good to say that users shouldn't do things, but they're being
done, and the code needs to be written to account for real-world use, not some
hypothetical ideal that doesn't exist.

Also, I would love for Solr to just be exposed exclusively on my server's
internal IP address(es)--but I have no idea how to do that. The administrative
web interface certainly doesn't let me select which IPs to bind to, which would
be the easy way to implement that ideal. But regardless, it should never be
assumed that every user will want to or know to operate Solr the same way (e.g.
exclusively on a LAN behind a firewall).

was (Author: thinkcomp):
It's all well and good to say that users shouldn't do things, but they're being
done, and the code needs to be written to account for real-world use, not some
hypothetical ideal that doesn't exist.

Also, I would love for Solr to just be exposed on my server's internal IP
addresses--but I have no idea how to do that. The administrative web interface
certainly doesn't let me select which IPs to bind to, which would be the easy
way to implement that ideal. But regardless, it should never be assumed that
every user will want to or know to operate Solr the same way (e.g. exclusively
on a LAN behind a firewall).

Solr Administrative Interface Lacks Password Protection
---

Key: SOLR-7896
URL: https://issues.apache.org/jira/browse/SOLR-7896
Project: Solr
Issue Type: Bug
Components: security, web gui
Affects Versions: 5.2.1
Reporter: Aaron Greenspan
Priority: Critical

--
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-7576) Implement RequestHandler in Javascript


[ 
https://issues.apache.org/jira/browse/SOLR-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661362#comment-14661362
 ] 

Noble Paul commented on SOLR-7576:
--

bq.There are other features like sources for Suggesters that I look forward to 
seeing getting upgraded to use the blob store

Exactly. That was the reason why I created that API. We need a place where we 
can store MBs of files and multiple versions of each of them. So a developer 
should be able to edit without fear and play with his production cluster 
without impacting his actual users

bq.For this specific feature (request handlers in scripting language) why 
should the executable be put in the Blob store at all? Generally these scripts 
are going to be very small.

I don't know if they are going to be very small and neither do you. In general 
we need a place which can store a lot of files. Moreover, whether the file is 
big or small the user experience is going to be exactly same, he will have to 
run a command line to edit this. Keeping multiple versions of the same script 
in the conf directory is not what I call elegant. We are just thinking of ZK as 
a kitchen sink because it used to be file system for standlone solr and size 
was never a problem

Standalone Solr is not going to be the primary target for any new feature that 
we develop. In a not too distant future we will make the standalone Solr also 
use a ZK and other stuff to unify dev/user experience. After all a standalone  
solr can easily be a single collection/ single shard/single replica version of 
SolrCloud. 

bq. A REST API on top could add another convenient access mechanism to conf 
dir stuff 
Please , we are not going to add more stuff to conf dir. That is a slippery 
slope. conf dir should have well known standard files. The rest of the stuff 
should move away. Bloating up ZK just because we used to store things in conf 
dir is just inertia. We must get over it. 

Having said that there is nothing that stops us from configuring the 
JsRequestHandler to load scripts from a local file system directory which can 
be useful for certain usecases. 

bq.i.e. exactly how the Script URP works

IIRC the script URP does not reload the script automatically by watching the ZK 
node. You need to go and restart core or other dirty stuff. In a large 
SolrCloud cluster that amounts to 100's of cores getting reloaded and caches 
trashed and what not (all queries getting slow/ a lot of GC etc). Do you still 
like that idea? Let's not assume that whatever we have today is optimized to 
run on cloud mode. There are a lot of things that got carried forward from the 
legacy things which are suboptimal to cloud. Instead of clinging on to the old 
way of life we must modernize our system to adopt to the new paradigm






 Implement RequestHandler in Javascript
 --

 Key: SOLR-7576
 URL: https://issues.apache.org/jira/browse/SOLR-7576
 Project: Solr
  Issue Type: New Feature
Reporter: Noble Paul
 Attachments: SOLR-7576.patch, SOLR-7576.patch


 Solr now support dynamic loading (SOLR-7073) of components and it is secured 
 in SOLR-7126
 We can extend the same functionality with JS as well
 the handler {{/js}} is implicitly registered
 To make this work
 * Solr should be started with {{-Denable.js.loading=true}}
 * The javascript must be loaded to the {{.system}} collection using the blob 
 store API
 * Sign the javascript and pass the signature in a param called {{_sig}}
 The {{JSRequestHandler}} is implicitly defined and it can be accessed by 
 hitting {{/js/jsname/version}} 
 Steps for developing scripts
 # start the cluster with the {{enable.js.loading}} . If you are starting 
 using our script it would be {{bin/solr start -e cloud -a 
 -Denable.js.loading=true}} . You would not need security during development 
 , so don't add the private keys to Solr
 # create {{.system}} collection {{bin/solr create -c .system}}
 # Write your javascript code . (say {{test.js}} )
 # post it to {{.system}} collection . {{curl -X POST -H 'Content-Type: 
 application/octet-stream' --data-binary @test.js 
 http://localhost:8983/solr/.system/blob/test}}
 # run your script {{http://host:8983/solr/gettingstarted/js/test/1}}
 # Edit your script and repeat from step #4 . Keep in mind that the version 
 would be bumped up every time you post a new script . So, the second time the 
 url would be {{http://host:8983/solr/gettingstarted/js/test/2}} . So on and 
 so forth
 sample programs
 1) writes a val to output
 {code:javascript}
 //empty line
 $.response().add('testkey','Test Val');
 {code}
 2)  manipulate the output to add an extra field to each doc 
 {code}
 //empty line
 var l = [];
 $.query({
   q: '*:*',
   qt: '/select',
   start:0,
   }).forEach('response', function(doc) {

[jira] [Reopened] (SOLR-7896) Solr Administrative Interface Lacks Password Protection


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

Upayavira reopened SOLR-7896:
-

As a slightly longer term goal, I believe this ticket does have merit, and 
given we have auth capabilities in Solr now, it makes sense to place the admin 
UI behind that.

 Solr Administrative Interface Lacks Password Protection
 ---

 Key: SOLR-7896
 URL: https://issues.apache.org/jira/browse/SOLR-7896
 Project: Solr
  Issue Type: Bug
  Components: security, web gui
Affects Versions: 5.2.1
Reporter: Aaron Greenspan
Priority: Critical

 Out of the box, the Solr interface should require an administrative password 
 that the user is required to set. Apparently there are ways of configuring 
 Jetty to do this with HTTP AUTH or whatever. I'm a moderately experienced 
 Linux admin and a programmer; I've tried, numerous times, and I've not once 
 been able to get it to work. The point is this, though:
 *No one should have to try to get their Solr instance to support password 
 authentication and preferably SSL (even if it's just with a self-signed 
 certificate). Solr is designed to store huge amounts of data and is therefore 
 a likely target for malicious users.*
 This needs to be addressed! It's 2015 and Solr is on version 5!



--
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-7895) Administrative UI Lacks Obvious Delete Core Contents Button


[ 
https://issues.apache.org/jira/browse/SOLR-7895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661358#comment-14661358
 ] 

Aaron Greenspan commented on SOLR-7895:
---

I'm afraid I can't be of much assistance coding, but I'm happy to provide 
feedback.

 Administrative UI Lacks Obvious Delete Core Contents Button
 -

 Key: SOLR-7895
 URL: https://issues.apache.org/jira/browse/SOLR-7895
 Project: Solr
  Issue Type: Improvement
Affects Versions: 5.2.1
Reporter: Aaron Greenspan

 When Solr screws up, which is practically on a daily basis, I often want to 
 delete the contents of a core without deleting its structure. Instead of 
 clicking on a button and perhaps an Are you sure? prompt, I have to 
 remember this incredibly unwieldy and dangerous-to-bookmark URL:
 http://[server]:8983/solr/[core 
 name]/update?stream.body=%3Cdelete%3E%3Cquery%3Eid:*%3C/query%3E%3C/delete%3Ecommit=true
 To say that this is not user-friendly is a gross understatement. If there is 
 a better way or an obvious easy way, I have not found 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-7896) Solr Administrative Interface Lacks Password Protection

[
https://issues.apache.org/jira/browse/SOLR-7896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661360#comment-14661360
]

Upayavira commented on SOLR-7896:
-

Given we have a new auth framework, and SSL support, this is do-able. I've not
yet payed with, nor needed to, play with either.

The benefit of discussing on the User list first, as Erick suggests, is to get
more of an understanding of the use-cases you are looking at before we decide
on an approach to solving them.

Erick is right - Solr is not something that has traditionally been placed
outside a firewall, because, well, it hasn't offered features that would allow
that. This is starting to change, and I think auth on the admin UI would be a
good thing, although I'm not yet in a position to work on it.

Therefore, I'm inclined to re-open, even if I'm aware it'd take me some time to
get around to it.

Solr Administrative Interface Lacks Password Protection
---

Key: SOLR-7896
URL: https://issues.apache.org/jira/browse/SOLR-7896
Project: Solr
Issue Type: Bug
Components: security, web gui
Affects Versions: 5.2.1
Reporter: Aaron Greenspan
Priority: Critical

--
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-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2593 - Failure!

2015-08-06 Thread Policeman Jenkins Server

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2593/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC

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

Error Message:
Didn't see replicas [core_node1, core_node2] come up within 9 ms! 
ClusterState: DocCollection(c8n_1x3_lf)={   replicationFactor:3,   
shards:{shard1:{   range:8000-7fff,   state:active, 
  replicas:{ core_node1:{   
core:c8n_1x3_lf_shard1_replica3,   
base_url:http://127.0.0.1:53643/ozb/j;,   
node_name:127.0.0.1:53643_ozb%2Fj,   state:recovering}, 
core_node2:{   core:c8n_1x3_lf_shard1_replica2,   
base_url:http://127.0.0.1:53625/ozb/j;,   
node_name:127.0.0.1:53625_ozb%2Fj,   state:active,   
leader:true}, core_node3:{   
core:c8n_1x3_lf_shard1_replica1,   
base_url:http://127.0.0.1:53661/ozb/j;,   
node_name:127.0.0.1:53661_ozb%2Fj,   state:down,   
router:{name:compositeId},   maxShardsPerNode:1,   
autoAddReplicas:false}

Stack Trace:
java.lang.AssertionError: Didn't see replicas [core_node1, core_node2] come up 
within 9 ms! ClusterState: DocCollection(c8n_1x3_lf)={
  replicationFactor:3,
  shards:{shard1:{
  range:8000-7fff,
  state:active,
  replicas:{
core_node1:{
  core:c8n_1x3_lf_shard1_replica3,
  base_url:http://127.0.0.1:53643/ozb/j;,
  node_name:127.0.0.1:53643_ozb%2Fj,
  state:recovering},
core_node2:{
  core:c8n_1x3_lf_shard1_replica2,
  base_url:http://127.0.0.1:53625/ozb/j;,
  node_name:127.0.0.1:53625_ozb%2Fj,
  state:active,
  leader:true},
core_node3:{
  core:c8n_1x3_lf_shard1_replica1,
  base_url:http://127.0.0.1:53661/ozb/j;,
  node_name:127.0.0.1:53661_ozb%2Fj,
  state:down,
  router:{name:compositeId},
  maxShardsPerNode:1,
  autoAddReplicas:false}
at 
__randomizedtesting.SeedInfo.seed([FE819BF77201435F:76D5A42DDCFD2EA7]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.HttpPartitionTest.waitToSeeReplicasActive(HttpPartitionTest.java:565)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:178)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:51)
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:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at

[jira] [Commented] (SOLR-7877) TestAuthenticationFramework.testBasics to preserve/restore the original request(Username|Password)


[ 
https://issues.apache.org/jira/browse/SOLR-7877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661264#comment-14661264
 ] 

Noble Paul commented on SOLR-7877:
--

sure, I'll remove that patch. It is committed to trunk, branch_5x already

 TestAuthenticationFramework.testBasics to preserve/restore the original 
 request(Username|Password)
 --

 Key: SOLR-7877
 URL: https://issues.apache.org/jira/browse/SOLR-7877
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.3, Trunk
Reporter: Noble Paul
Assignee: Christine Poerschke
Priority: Blocker

 {code}
 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13742/
 Java: 32bit/jdk1.8.0_60-ea-b24 -server -XX:+UseG1GC
 1 tests failed.
 FAILED:  
 org.apache.solr.cloud.TestAuthenticationFramework.testCollectionCreateWithoutCoresThenDelete
 Error Message:
 Error from server at http://127.0.0.1:51573/solr: Expected mime type 
 application/octet-stream but got text/html. html head meta 
 http-equiv=Content-Type content=text/html;charset=ISO-8859-1/ 
 titleError 401 /title /head body h2HTTP ERROR: 401/h2 pProblem 
 accessing /solr/admin/collections. Reason: preUnauthorized 
 request/pre/p hr /ismallPowered by Jetty:///small/i /body 
 /html
 Stack Trace:
 org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
 from server at http://127.0.0.1:51573/solr: Expected mime type 
 application/octet-stream but got text/html. html
 head
 meta http-equiv=Content-Type content=text/html;charset=ISO-8859-1/
 titleError 401 /title
 /head
 body
 h2HTTP ERROR: 401/h2
 pProblem accessing /solr/admin/collections. Reason:
 preUnauthorized request/pre/p
 hr /ismallPowered by Jetty:///small/i
 /body
 /html
 at 
 __randomizedtesting.SeedInfo.seed([A454441B503006EB:17918BDA5F48D5AA]:0)
 at 
 org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:528)
 at 
 org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234)
 at 
 org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226)
 at 
 org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376)
 at 
 org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328)
 at 
 org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
 at 
 org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856)
 at 
 org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799)
 at 
 org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
 at 
 org.apache.solr.cloud.MiniSolrCloudCluster.makeCollectionsRequest(MiniSolrCloudCluster.java:349)
 at 
 org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:333)
 at 
 org.apache.solr.cloud.TestMiniSolrCloudCluster.createCollection(TestMiniSolrCloudCluster.java:115)
 at 
 org.apache.solr.cloud.TestMiniSolrCloudCluster.testCollectionCreateWithoutCoresThenDelete(TestMiniSolrCloudCluster.java:298)
 {code}



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

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

[jira] [Updated] (SOLR-7877) TestAuthenticationFramework.testBasics to preserve/restore the original request(Username|Password)


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

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

 TestAuthenticationFramework.testBasics to preserve/restore the original 
 request(Username|Password)
 --

 Key: SOLR-7877
 URL: https://issues.apache.org/jira/browse/SOLR-7877
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.3, Trunk
Reporter: Noble Paul
Assignee: Christine Poerschke
Priority: Blocker

 {code}
 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13742/
 Java: 32bit/jdk1.8.0_60-ea-b24 -server -XX:+UseG1GC
 1 tests failed.
 FAILED:  
 org.apache.solr.cloud.TestAuthenticationFramework.testCollectionCreateWithoutCoresThenDelete
 Error Message:
 Error from server at http://127.0.0.1:51573/solr: Expected mime type 
 application/octet-stream but got text/html. html head meta 
 http-equiv=Content-Type content=text/html;charset=ISO-8859-1/ 
 titleError 401 /title /head body h2HTTP ERROR: 401/h2 pProblem 
 accessing /solr/admin/collections. Reason: preUnauthorized 
 request/pre/p hr /ismallPowered by Jetty:///small/i /body 
 /html
 Stack Trace:
 org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
 from server at http://127.0.0.1:51573/solr: Expected mime type 
 application/octet-stream but got text/html. html
 head
 meta http-equiv=Content-Type content=text/html;charset=ISO-8859-1/
 titleError 401 /title
 /head
 body
 h2HTTP ERROR: 401/h2
 pProblem accessing /solr/admin/collections. Reason:
 preUnauthorized request/pre/p
 hr /ismallPowered by Jetty:///small/i
 /body
 /html
 at 
 __randomizedtesting.SeedInfo.seed([A454441B503006EB:17918BDA5F48D5AA]:0)
 at 
 org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:528)
 at 
 org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234)
 at 
 org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226)
 at 
 org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376)
 at 
 org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328)
 at 
 org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
 at 
 org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856)
 at 
 org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799)
 at 
 org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
 at 
 org.apache.solr.cloud.MiniSolrCloudCluster.makeCollectionsRequest(MiniSolrCloudCluster.java:349)
 at 
 org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:333)
 at 
 org.apache.solr.cloud.TestMiniSolrCloudCluster.createCollection(TestMiniSolrCloudCluster.java:115)
 at 
 org.apache.solr.cloud.TestMiniSolrCloudCluster.testCollectionCreateWithoutCoresThenDelete(TestMiniSolrCloudCluster.java:298)
 {code}



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

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

[jira] [Updated] (SOLR-7880) Update commons-cli to 1.3.1, fix usage of deprecated classes/methods

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

Shawn Heisey updated SOLR-7880:
---
Attachment: SOLR-7880.patch

Second crack at a patch. This time I found *all* places in the code where
commons-cli is used and checked them for usage of deprecated bits. They are
all gone now.

While I was there, I cleaned up some additional warnings in the source files
that use commons-cli. I'd appreciate a review to tell me if I have overstepped
in any way.

I'm running tests now (on Windows) and will do a precommit and nightly-smoke
(on Linux) when/if that successfully completes. I will also do some manual
testing of the bin\solr.cmd script to make sure that the arguments aren't
completely broken.

Update commons-cli to 1.3.1, fix usage of deprecated classes/methods

Key: SOLR-7880
URL: https://issues.apache.org/jira/browse/SOLR-7880
Project: Solr
Issue Type: Improvement
Components: scripts and tools
Affects Versions: 5.2.1
Reporter: Shawn Heisey
Assignee: Shawn Heisey
Fix For: 5.4

Attachments: SOLR-7880.patch, SOLR-7880.patch

While looking at SOLR-7847, I noticed that commons-cli was an old version,
and once I upgraded it in the ivy config, found that SolrCLI is using
deprecated classes/methods.
This issue is to complete the upgrade and fix the deprecations.

--
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-1945) Add support for child docs in DocumentObjectBinder

2015-08-06 Thread Preetam Dwivedi (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661291#comment-14661291
 ] 

Preetam Dwivedi commented on SOLR-1945:
---

[~noble.paul] I guess it was an issue with my code as it didn't added the type 
for this field.

{code:java}
@Field
public boolean child;
{code}

 Add support for child docs in DocumentObjectBinder
 --

 Key: SOLR-1945
 URL: https://issues.apache.org/jira/browse/SOLR-1945
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
Assignee: Noble Paul
Priority: Minor
 Fix For: 5.1, Trunk

 Attachments: SOLR-1945.patch, SOLR-1945.patch


 see 
 http://search.lucidimagination.com/search/document/d909d909420aeb4e/does_solrj_support_nested_annotated_beans
 Would be nice to be able to pass an object graph to solrj with @field 
 annotations rather than just a top level class



--
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-7576) Implement RequestHandler in Javascript


[ 
https://issues.apache.org/jira/browse/SOLR-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661318#comment-14661318
 ] 

Erick Erickson commented on SOLR-7576:
--

bq: guys , editing ZK directly is fraught with huge risk. Please don't 
recommend it to users.

Of course it is. Of course not. That's why I said  Totally unsuitable for 
production of course.

But for prototyping/quick experiments on an experimental system it's waay 
cool.

 Implement RequestHandler in Javascript
 --

 Key: SOLR-7576
 URL: https://issues.apache.org/jira/browse/SOLR-7576
 Project: Solr
  Issue Type: New Feature
Reporter: Noble Paul
 Attachments: SOLR-7576.patch, SOLR-7576.patch


 Solr now support dynamic loading (SOLR-7073) of components and it is secured 
 in SOLR-7126
 We can extend the same functionality with JS as well
 the handler {{/js}} is implicitly registered
 To make this work
 * Solr should be started with {{-Denable.js.loading=true}}
 * The javascript must be loaded to the {{.system}} collection using the blob 
 store API
 * Sign the javascript and pass the signature in a param called {{_sig}}
 The {{JSRequestHandler}} is implicitly defined and it can be accessed by 
 hitting {{/js/jsname/version}} 
 Steps for developing scripts
 # start the cluster with the {{enable.js.loading}} . If you are starting 
 using our script it would be {{bin/solr start -e cloud -a 
 -Denable.js.loading=true}} . You would not need security during development 
 , so don't add the private keys to Solr
 # create {{.system}} collection {{bin/solr create -c .system}}
 # Write your javascript code . (say {{test.js}} )
 # post it to {{.system}} collection . {{curl -X POST -H 'Content-Type: 
 application/octet-stream' --data-binary @test.js 
 http://localhost:8983/solr/.system/blob/test}}
 # run your script {{http://host:8983/solr/gettingstarted/js/test/1}}
 # Edit your script and repeat from step #4 . Keep in mind that the version 
 would be bumped up every time you post a new script . So, the second time the 
 url would be {{http://host:8983/solr/gettingstarted/js/test/2}} . So on and 
 so forth
 sample programs
 1) writes a val to output
 {code:javascript}
 //empty line
 $.response().add('testkey','Test Val');
 {code}
 2)  manipulate the output to add an extra field to each doc 
 {code}
 //empty line
 var l = [];
 $.query({
   q: '*:*',
   qt: '/select',
   start:0,
   }).forEach('response', function(doc) {
  doc.put('script', 'Added this 
 value');
  l.push(doc);
   });
  $.response().add('alldocs', l);
 {code}
 3)  stream through all the docs
 {code:Javascript}
 //empty line
 $.query({
   q: '*:*',
   qt: '/select',
   start:0,
   distrib:'false'
   }).pipe('response', 'docs', function(doc) { // the pipe function is 
 executed right before the response writer and right after the transformers   
  if('IT'== doc.get('genre_s')) return 
 null;
  doc.put('script', 'Added this 
 value');
  return doc;
   });
 {code}



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

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

[jira] [Commented] (SOLR-7733) remove/rename optimize references in the UI.

[
https://issues.apache.org/jira/browse/SOLR-7733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661357#comment-14661357
]

Aaron Greenspan commented on SOLR-7733:
---

I would suggest keeping the button but renaming it Consolidate or
Defragment.

Whether or not it technically is, this sounds a lot like the way people used to
think about disk defragmentation on MS-DOS/Windows 3.1/9x systems. Many people
had heard about it almost as a rumor and believed it would serve as a panacea
for all of their deeply-rooted registry problems, when it really only needed to
be done rarely, had minimal benefits for most, and took a long time.

With that context I think the best way to handle it is to keep the button in,
give it a descriptive name, and provide accurate information: something like
Expected processing time: 30h27m. Expected efficiency gain: 0.05%. No one
will waste their time on such a tradeoff unless they have a really good reason,
or unless the numbers look reasonable.

remove/rename optimize references in the UI.
--

Key: SOLR-7733
URL: https://issues.apache.org/jira/browse/SOLR-7733
Project: Solr
Issue Type: Improvement
Components: UI
Affects Versions: 5.3, Trunk
Reporter: Erick Erickson
Assignee: Upayavira
Priority: Minor
Attachments: SOLR-7733.patch

Since optimizing indexes is kind of a special circumstance thing, what do we
think about removing (or renaming) optimize-related stuff on the core admin
and core overview pages? The optimize button is already gone from the core
admin screen (was this intentional?).
My personal feeling is that we should remove this entirely as it's too easy
to think Of course I want my index optimized and look, this screen says my
index isn't optimized, that must mean I should optimize it.
The core admin screen and the core overview page both have an optimized
checkmark, I propose just removing it from the overview page and on the
core admin page changing it to Segment Count #. NOTE: the overview page
already has a Segment Count entry.

--
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-5.x-Windows (64bit/jdk1.7.0_80) - Build # 4988 - Failure!

2015-08-06 Thread Policeman Jenkins Server

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4988/
Java: 64bit/jdk1.7.0_80 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.security.PKIAuthenticationIntegrationTest.testPkiAuth

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([C6B9B26BB4C3E9EB:F6072B3A54756E4A]: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.security.PKIAuthenticationIntegrationTest.testPkiAuth(PKIAuthenticationIntegrationTest.java:96)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at

[jira] [Commented] (SOLR-5642) Query User Interface is Unnecessarily Cryptic


[ 
https://issues.apache.org/jira/browse/SOLR-5642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661297#comment-14661297
 ] 

Aaron Greenspan commented on SOLR-5642:
---

The problem is that I have no idea what they mean, and that's why I need the 
explanation.

This is a problem all throughout the web UI. The field names should be in 
English (or a spoken/written non-computer language), not XML variable names 
that no one knows except a few core programmers.

 Query User Interface is Unnecessarily Cryptic
 -

 Key: SOLR-5642
 URL: https://issues.apache.org/jira/browse/SOLR-5642
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.6
Reporter: Aaron Greenspan
Priority: Minor
   Original Estimate: 1h
  Remaining Estimate: 1h

 Solr depends on a lot of parameters to perform queries. These parameters have 
 one- or two-character names like q and fq and fl and df. It would be 
 extremely easy and extremely helpful to users to use tooltips in the web UI 
 that could explain what these parameters actually mean, and it would be 
 further helpful to link directly to the documentation for each. Right now I 
 have no idea what they mean and since there's several versions of the 
 documentation I'm not even sure how to find the best place to look.
 Also, the word Dataimport on the left should be two words: Data Import 
 both because dataimport is not a word in any language and because the 
 Schema Browser appears as two proper words.



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

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

[jira] [Resolved] (SOLR-7897) Solr Can't Find Singular Versus Plural Words


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

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

Please bring this kind of thing up on the user's list rather than raise JIRAs 
to be sure you're not simply misunderstanding things. If it's a real problem in 
Solr, _then_ raise a JIRA.

In this particular case, you probably aren't employing stemming in your 
analysis chain. Try it and see.



 Solr Can't Find Singular Versus Plural Words
 

 Key: SOLR-7897
 URL: https://issues.apache.org/jira/browse/SOLR-7897
 Project: Solr
  Issue Type: Bug
  Components: search
Affects Versions: 5.2.1
Reporter: Aaron Greenspan

 I have a core with lots of company names in it. If I search for Uber 
 Technologies, Inc. then great. It's an exact match. If I search for Uber 
 Technology then no results found.
 Do I really have to teach Solr that you drop the y and add ies somehow to 
 make words plural? I thought it somehow knew how to do that already... If it 
 doesn't, it should.



--
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-7886) factor out a TestMiniSolrCloudClusterBase class

2015-08-06 Thread Shalin Shekhar Mangar (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661320#comment-14661320
 ] 

Shalin Shekhar Mangar commented on SOLR-7886:
-

But those tests have no business extending TestMiniSolrCloudCluster, do they? 
There are many tests which extend SolrTestCaseJ4 and use MiniSolrCloudCluster 
directly. Perhaps these tests should also do the same?

 factor out a TestMiniSolrCloudClusterBase class
 ---

 Key: SOLR-7886
 URL: https://issues.apache.org/jira/browse/SOLR-7886
 Project: Solr
  Issue Type: Test
Reporter: Christine Poerschke
Priority: Minor

 Please see SOLR-7877 for initial discussion on this.
 Currently we have:
 {code}
 public class TestMiniSolrCloudCluster extends LuceneTestCase
 {code}
 and
 {code}
 public class BasicAuthIntegrationTest extends TestMiniSolrCloudCluster {
 public class TestAuthenticationFramework extends TestMiniSolrCloudCluster {
 public class TestMiniSolrCloudClusterKerberos extends 
 TestMiniSolrCloudCluster {
 {code}



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

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

[jira] [Commented] (SOLR-7896) Solr Administrative Interface Lacks Password Protection


[ 
https://issues.apache.org/jira/browse/SOLR-7896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661339#comment-14661339
 ] 

Aaron Greenspan commented on SOLR-7896:
---

SSL should be enabled by default.

 Solr Administrative Interface Lacks Password Protection
 ---

 Key: SOLR-7896
 URL: https://issues.apache.org/jira/browse/SOLR-7896
 Project: Solr
  Issue Type: Bug
  Components: security, web gui
Affects Versions: 5.2.1
Reporter: Aaron Greenspan
Priority: Critical

 Out of the box, the Solr interface should require an administrative password 
 that the user is required to set. Apparently there are ways of configuring 
 Jetty to do this with HTTP AUTH or whatever. I'm a moderately experienced 
 Linux admin and a programmer; I've tried, numerous times, and I've not once 
 been able to get it to work. The point is this, though:
 *No one should have to try to get their Solr instance to support password 
 authentication and preferably SSL (even if it's just with a self-signed 
 certificate). Solr is designed to store huge amounts of data and is therefore 
 a likely target for malicious users.*
 This needs to be addressed! It's 2015 and Solr is on version 5!



--
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-7576) Implement RequestHandler in Javascript

2015-08-06 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661214#comment-14661214
 ] 

David Smiley commented on SOLR-7576:


I think the pain point here that Upayavira is getting at, and which I see, is 
the annoyance of having to update a file in ZooKeeper from one's file system.  
In stand-alone, there is no extra step between saving certain types of files in 
a conf/ dir on your file system and utilizing it from Solr (perhaps also 
needing a core reload or similar action).  That file list includes script URPs 
(JS and other interpreted languages supported), XSLTs, Velocity templates, 
sometimes DIH config files considering the debug mode, and file based 
Spellcheck  Suggester sources, and ExternalFileField's source file.  Perhaps 
there are others I have overlooked.  To some extent we could say absolutely 
everything in a conf/, but there are now RESTful APIs to modify various things 
in ways that don't involve the need to update the schema or solrconfig.xml 
directly.

What I'd love to see is a file system to ZooKeeper updater that works 
automatically once something is saved.  This might be a utility tool only used 
in development, or perhaps built-in to bin/solr -- either way it'd be super 
helpful.

 Implement RequestHandler in Javascript
 --

 Key: SOLR-7576
 URL: https://issues.apache.org/jira/browse/SOLR-7576
 Project: Solr
  Issue Type: New Feature
Reporter: Noble Paul
 Attachments: SOLR-7576.patch, SOLR-7576.patch


 Solr now support dynamic loading (SOLR-7073) of components and it is secured 
 in SOLR-7126
 We can extend the same functionality with JS as well
 the handler {{/js}} is implicitly registered
 To make this work
 * Solr should be started with {{-Denable.js.loading=true}}
 * The javascript must be loaded to the {{.system}} collection using the blob 
 store API
 * Sign the javascript and pass the signature in a param called {{_sig}}
 The {{JSRequestHandler}} is implicitly defined and it can be accessed by 
 hitting {{/js/jsname/version}} 
 Steps for developing scripts
 # start the cluster with the {{enable.js.loading}} . If you are starting 
 using our script it would be {{bin/solr start -e cloud -a 
 -Denable.js.loading=true}} . You would not need security during development 
 , so don't add the private keys to Solr
 # create {{.system}} collection {{bin/solr create -c .system}}
 # Write your javascript code . (say {{test.js}} )
 # post it to {{.system}} collection . {{curl -X POST -H 'Content-Type: 
 application/octet-stream' --data-binary @test.js 
 http://localhost:8983/solr/.system/blob/test}}
 # run your script {{http://host:8983/solr/gettingstarted/js/test/1}}
 # Edit your script and repeat from step #4 . Keep in mind that the version 
 would be bumped up every time you post a new script . So, the second time the 
 url would be {{http://host:8983/solr/gettingstarted/js/test/2}} . So on and 
 so forth
 sample programs
 1) writes a val to output
 {code:javascript}
 //empty line
 $.response().add('testkey','Test Val');
 {code}
 2)  manipulate the output to add an extra field to each doc 
 {code}
 //empty line
 var l = [];
 $.query({
   q: '*:*',
   qt: '/select',
   start:0,
   }).forEach('response', function(doc) {
  doc.put('script', 'Added this 
 value');
  l.push(doc);
   });
  $.response().add('alldocs', l);
 {code}
 3)  stream through all the docs
 {code:Javascript}
 //empty line
 $.query({
   q: '*:*',
   qt: '/select',
   start:0,
   distrib:'false'
   }).pipe('response', 'docs', function(doc) { // the pipe function is 
 executed right before the response writer and right after the transformers   
  if('IT'== doc.get('genre_s')) return 
 null;
  doc.put('script', 'Added this 
 value');
  return doc;
   });
 {code}



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

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

[jira] [Commented] (SOLR-7576) Implement RequestHandler in Javascript

2015-08-06 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661256#comment-14661256
 ] 

David Smiley commented on SOLR-7576:


Nice tip Erick!   -- for reference: 
https://plugins.jetbrains.com/plugin/7364?pr=idea_ce
I was just playing around with it now.  The only annoyance I've seen is that 
when editing a file I need to right-click and choose to update ZK; closing the 
window loses any edits, it appears.

 Implement RequestHandler in Javascript
 --

 Key: SOLR-7576
 URL: https://issues.apache.org/jira/browse/SOLR-7576
 Project: Solr
  Issue Type: New Feature
Reporter: Noble Paul
 Attachments: SOLR-7576.patch, SOLR-7576.patch


 Solr now support dynamic loading (SOLR-7073) of components and it is secured 
 in SOLR-7126
 We can extend the same functionality with JS as well
 the handler {{/js}} is implicitly registered
 To make this work
 * Solr should be started with {{-Denable.js.loading=true}}
 * The javascript must be loaded to the {{.system}} collection using the blob 
 store API
 * Sign the javascript and pass the signature in a param called {{_sig}}
 The {{JSRequestHandler}} is implicitly defined and it can be accessed by 
 hitting {{/js/jsname/version}} 
 Steps for developing scripts
 # start the cluster with the {{enable.js.loading}} . If you are starting 
 using our script it would be {{bin/solr start -e cloud -a 
 -Denable.js.loading=true}} . You would not need security during development 
 , so don't add the private keys to Solr
 # create {{.system}} collection {{bin/solr create -c .system}}
 # Write your javascript code . (say {{test.js}} )
 # post it to {{.system}} collection . {{curl -X POST -H 'Content-Type: 
 application/octet-stream' --data-binary @test.js 
 http://localhost:8983/solr/.system/blob/test}}
 # run your script {{http://host:8983/solr/gettingstarted/js/test/1}}
 # Edit your script and repeat from step #4 . Keep in mind that the version 
 would be bumped up every time you post a new script . So, the second time the 
 url would be {{http://host:8983/solr/gettingstarted/js/test/2}} . So on and 
 so forth
 sample programs
 1) writes a val to output
 {code:javascript}
 //empty line
 $.response().add('testkey','Test Val');
 {code}
 2)  manipulate the output to add an extra field to each doc 
 {code}
 //empty line
 var l = [];
 $.query({
   q: '*:*',
   qt: '/select',
   start:0,
   }).forEach('response', function(doc) {
  doc.put('script', 'Added this 
 value');
  l.push(doc);
   });
  $.response().add('alldocs', l);
 {code}
 3)  stream through all the docs
 {code:Javascript}
 //empty line
 $.query({
   q: '*:*',
   qt: '/select',
   start:0,
   distrib:'false'
   }).pipe('response', 'docs', function(doc) { // the pipe function is 
 executed right before the response writer and right after the transformers   
  if('IT'== doc.get('genre_s')) return 
 null;
  doc.put('script', 'Added this 
 value');
  return doc;
   });
 {code}



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

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

[jira] [Commented] (SOLR-7838) Implement a RuleBasedAuthorizationPlugin


[ 
https://issues.apache.org/jira/browse/SOLR-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661257#comment-14661257
 ] 

Noble Paul commented on SOLR-7838:
--

Sorry for the trouble. The description is same as that in SOLR-7692 (the parent 
ticket) other committers insisted on splitting this into multiple pieces. So I 
just  created a ticket for committing stuff. I'll copy the description over 

 Implement a RuleBasedAuthorizationPlugin
 

 Key: SOLR-7838
 URL: https://issues.apache.org/jira/browse/SOLR-7838
 Project: Solr
  Issue Type: Sub-task
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] [Updated] (SOLR-7837) Implement BasicAuth Authentication Plugin


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

Noble Paul updated SOLR-7837:
-
Description: 
The sample config in ZK would look like
{code}
{

authentication:{

   class:solr.BasicAuthPlugin,

   credentials:{solr:IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0= 
Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c=}

}}

{code}

There is an API to add, edit or remove users. Please note that the commands 
shown below are tied to this specific Basic authentication implementation and 
the same set of commands are not valid if the implementation class is not 
solr.BasicAuthPlugin.
Example 1: Adding a user and editing a password

{code}
curl --user solr:SolrRocks http://localhost:8983/solr/admin/authentication -H 
'Content-type:application/json'-d '{ 
  set-user: {tom : TomIsCool , 
   harry:HarrysSecret}}'
 {code}

Example 2: Deleting a user
{code}
curl --user solr:SolrRocks http://localhost:8983/solr/admin/authentication -H 
'Content-type:application/json'-d  '{
 delete-user: [tom,harry]}'
{code}



 Implement BasicAuth Authentication Plugin
 -

 Key: SOLR-7837
 URL: https://issues.apache.org/jira/browse/SOLR-7837
 Project: Solr
  Issue Type: Sub-task
Reporter: Noble Paul
Assignee: Noble Paul

 The sample config in ZK would look like
 {code}
 {
 authentication:{
class:solr.BasicAuthPlugin,
credentials:{solr:IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0= 
 Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c=}
 }}
 {code}
 There is an API to add, edit or remove users. Please note that the commands 
 shown below are tied to this specific Basic authentication implementation and 
 the same set of commands are not valid if the implementation class is not 
 solr.BasicAuthPlugin.
 Example 1: Adding a user and editing a password
 {code}
 curl --user solr:SolrRocks http://localhost:8983/solr/admin/authentication -H 
 'Content-type:application/json'-d '{ 
   set-user: {tom : TomIsCool , 
harry:HarrysSecret}}'
  {code}
 Example 2: Deleting a user
 {code}
 curl --user solr:SolrRocks http://localhost:8983/solr/admin/authentication -H 
 'Content-type:application/json'-d  '{
  delete-user: [tom,harry]}'
 {code}



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

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

[jira] [Commented] (SOLR-7576) Implement RequestHandler in Javascript


[ 
https://issues.apache.org/jira/browse/SOLR-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661282#comment-14661282
 ] 

Noble Paul commented on SOLR-7576:
--

[~dsmiley]
bq. is the annoyance of having to update a file in ZooKeeper from one's file 
system 

I can see that pain point.

But the current model is totally broken and we MUST move away from from that
* we can't keep large amounts data in ZK
* We should not give a new feature out which requires a developer direct access 
to write to ZK.We are talking about the same thing for a toy single node system 
to large clusters with 1000's of nodes. Any screw up in ZK will have huge 
impact . It is not like a solr node going down, it is going to blow up a huge 
cluster 
* Editing files and picking them up immediately may sound ok if you don't cache 
stuff. Which is terrible for performance. So there has to be a way to tell Solr 
that a particular resource is changed
* In real production systems we need to rollback stuff if things are broken. 
This design lets you do that. You always upload a new version of the same file 
like a version control system. Uploading a new version will have no impact till 
you push it to production. Play with the new version till you are happy and 
then push it to production. The point is , the developer can't screw up the 
cluster by introducing a small syntax error 

I'm not against adding an easier dev sandbox for such features. This is just 
the first step. First of all we need to get the feature right for a deployed 
large cluster. That is the story that we will want to discuss first. This just 
one extra step for a developer in that phase. Ease of use stuff for playing 
with things is a secondary thing and we should be able to do it as a separate 
ticket. Understand that a standalone process and a huge cluster with 1000's of 
nodes will have some difference in the way stuff is deployed

guys , editing ZK directly is fraught with huge risk. Please don't recommend it 
to users. I understand that we have a lot of legacy stuff without proper APIs 
and we need to edit things directly. We MUST have a safe way of achieving the 
same through APIs (eventually). 

So please do not introduce any new feature that needs ZK write.  

 Implement RequestHandler in Javascript
 --

 Key: SOLR-7576
 URL: https://issues.apache.org/jira/browse/SOLR-7576
 Project: Solr
  Issue Type: New Feature
Reporter: Noble Paul
 Attachments: SOLR-7576.patch, SOLR-7576.patch


 Solr now support dynamic loading (SOLR-7073) of components and it is secured 
 in SOLR-7126
 We can extend the same functionality with JS as well
 the handler {{/js}} is implicitly registered
 To make this work
 * Solr should be started with {{-Denable.js.loading=true}}
 * The javascript must be loaded to the {{.system}} collection using the blob 
 store API
 * Sign the javascript and pass the signature in a param called {{_sig}}
 The {{JSRequestHandler}} is implicitly defined and it can be accessed by 
 hitting {{/js/jsname/version}} 
 Steps for developing scripts
 # start the cluster with the {{enable.js.loading}} . If you are starting 
 using our script it would be {{bin/solr start -e cloud -a 
 -Denable.js.loading=true}} . You would not need security during development 
 , so don't add the private keys to Solr
 # create {{.system}} collection {{bin/solr create -c .system}}
 # Write your javascript code . (say {{test.js}} )
 # post it to {{.system}} collection . {{curl -X POST -H 'Content-Type: 
 application/octet-stream' --data-binary @test.js 
 http://localhost:8983/solr/.system/blob/test}}
 # run your script {{http://host:8983/solr/gettingstarted/js/test/1}}
 # Edit your script and repeat from step #4 . Keep in mind that the version 
 would be bumped up every time you post a new script . So, the second time the 
 url would be {{http://host:8983/solr/gettingstarted/js/test/2}} . So on and 
 so forth
 sample programs
 1) writes a val to output
 {code:javascript}
 //empty line
 $.response().add('testkey','Test Val');
 {code}
 2)  manipulate the output to add an extra field to each doc 
 {code}
 //empty line
 var l = [];
 $.query({
   q: '*:*',
   qt: '/select',
   start:0,
   }).forEach('response', function(doc) {
  doc.put('script', 'Added this 
 value');
  l.push(doc);
   });
  $.response().add('alldocs', l);
 {code}
 3)  stream through all the docs
 {code:Javascript}
 //empty line
 $.query({
   q: '*:*',
   qt: '/select',
   start:0,
   distrib:'false'
   }).pipe('response', 'docs', function(doc) { // the pipe function is 
 executed right before the response writer and right after the transformers

[jira] [Commented] (SOLR-7880) Update commons-cli to 1.3.1, fix usage of deprecated classes/methods


[ 
https://issues.apache.org/jira/browse/SOLR-7880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661284#comment-14661284
 ] 

Shawn Heisey commented on SOLR-7880:


For clarification, I was fixing warnings seen in Eclipse.  I'm well aware that 
Eclipse warns on much more than javac does, but most of the time I think that 
it's worth fixing the IDE warnings as well as the compiler warnings, or 
suppressing them in certain situations.

 Update commons-cli to 1.3.1, fix usage of deprecated classes/methods
 

 Key: SOLR-7880
 URL: https://issues.apache.org/jira/browse/SOLR-7880
 Project: Solr
  Issue Type: Improvement
  Components: scripts and tools
Affects Versions: 5.2.1
Reporter: Shawn Heisey
Assignee: Shawn Heisey
 Fix For: 5.4

 Attachments: SOLR-7880.patch, SOLR-7880.patch, SOLR-7880.patch


 While looking at SOLR-7847, I noticed that commons-cli was an old version, 
 and once I upgraded it in the ivy config, found that SolrCLI is using 
 deprecated classes/methods.
 This issue is to complete the upgrade and fix the deprecations.



--
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-7576) Implement RequestHandler in Javascript

[
https://issues.apache.org/jira/browse/SOLR-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661282#comment-14661282
]

Noble Paul edited comment on SOLR-7576 at 8/7/15 4:19 AM:
--

[~dsmiley]
bq. is the annoyance of having to update a file in ZooKeeper from one's file
system

I can see that pain point.

But the current model is totally broken and we MUST move away from from that
* we can't keep large amounts data in ZK
* We should not give a new feature out which requires a developer direct access
to write to ZK.We are talking about the same thing for a toy single node system
to large clusters with 1000's of nodes. Any screw up in ZK will have huge
impact . It is not like a solr node going down, it is going to blow up a huge
cluster
* Editing files and picking them up immediately may sound ok if you don't cache
stuff. Which is terrible for performance. So there has to be a way to tell Solr
that a particular resource is changed
* In real production systems we need to rollback stuff if things are broken.
This design lets you do that. You always upload a new version of the same file
like a version control system. Uploading a new version will have no impact till
you push it to production. Play with the new version till you are happy and
then push it to production. The point is , the developer can't screw up the
cluster by introducing a small syntax error .

I'm not against adding an easier dev sandbox for such features. This is just
the first step. First of all we need to get the feature right for a deployed
large cluster. That is the story that we need to discuss first. This is just
one extra step for a developer which is good for him. Ease of use stuff for
playing with things is a secondary thing and we should be able to do it as a
separate ticket. Understand that a standalone process and a huge cluster with
1000's of nodes will have some difference in the way stuff is deployed

guys , editing ZK directly is fraught with huge risk. Please don't recommend it
to users. I understand that we have a lot of legacy stuff without proper APIs
and we need to edit things directly. We MUST have a safe way of achieving the
same through APIs (eventually).

So please do not introduce any new feature that needs ZK write.

was (Author: noble.paul):
[~dsmiley]
bq. is the annoyance of having to update a file in ZooKeeper from one's file
system

I can see that pain point.

I'm not against adding an easier dev sandbox for such features. This is just
the first step. First of all we need to get the feature right for a deployed
large cluster. That is the story that we will want to discuss first. This just
one extra step for a developer in that phase. Ease of use stuff for playing
with things is a secondary thing and we should be able to do it as a separate
ticket. Understand that a standalone process and a huge cluster with 1000's of
nodes will have some difference in the way stuff is deployed

So please do not introduce any new feature that needs ZK write.

Implement RequestHandler in Javascript
--

Key: SOLR-7576
URL: https://issues.apache.org/jira/browse/SOLR-7576
Project: Solr
Issue Type: New Feature
Reporter: Noble Paul
Attachments: SOLR-7576.patch, SOLR-7576.patch

Solr now support dynamic loading (SOLR-7073) of components and it is secured
in SOLR-7126
We can extend the same functionality with JS as well
the handler {{/js}} is

[jira] [Updated] (SOLR-7896) Solr Administrative Interface Lacks Password Protection


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

Aaron Greenspan updated SOLR-7896:
--
Component/s: security

 Solr Administrative Interface Lacks Password Protection
 ---

 Key: SOLR-7896
 URL: https://issues.apache.org/jira/browse/SOLR-7896
 Project: Solr
  Issue Type: Bug
  Components: security, web gui
Affects Versions: 5.2.1
Reporter: Aaron Greenspan
Priority: Critical

 Out of the box, the Solr interface should require an administrative password 
 that the user is required to set. Apparently there are ways of configuring 
 Jetty to do this with HTTP AUTH or whatever. I'm a moderately experienced 
 Linux admin and a programmer; I've tried, numerous times, and I've not once 
 been able to get it to work. The point is this, though:
 *No one should have to try to get their Solr instance to support password 
 authentication and preferably SSL (even if it's just with a self-signed 
 certificate). Solr is designed to store huge amounts of data and is therefore 
 a likely target for malicious users.*
 This needs to be addressed! It's 2015 and Solr is on version 5!



--
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-7896) Solr Administrative Interface Lacks Password Protection

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

Aaron Greenspan updated SOLR-7896:
--
Description:
Out of the box, the Solr interface should require an administrative password
that the user is required to set. Apparently there are ways of configuring
Jetty to do this with HTTP AUTH or whatever. I'm a moderately experienced Linux
admin and a programmer; I've tried, numerous times, and I've not once been able
to get it to work. The point is this, though:

*No one should have to try to get their Solr instance to support password
authentication and preferably SSL (even if it's just with a self-signed
certificate). Solr is designed to store huge amounts of data and is therefore a
likely target for malicious users.*

This needs to be addressed! It's 2015 and Solr is on version 5!

was:
Out of the box, the Solr interface should require an administrative password
that the user is required to set. Apparently there are ways of configuring
Jetty to do this with HTTP AUTH or whatever. I'm a moderately experienced Linux
admin and a programmer; I've tried, numerous times, and I've not once been able
to get it to work. The point is this, though:

*No one should have to try to get their server to support password
authentication and SSL. Solr is designed to store huge amounts of data and is
therefore a likely target for malicious users.*

This needs to be addressed! It's 2015 and Solr is on version 5!

Solr Administrative Interface Lacks Password Protection
---

Key: SOLR-7896
URL: https://issues.apache.org/jira/browse/SOLR-7896
Project: Solr
Issue Type: Bug
Components: security, web gui
Affects Versions: 5.2.1
Reporter: Aaron Greenspan
Priority: Critical

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

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

[jira] [Resolved] (SOLR-7894) Solr Forgets Core Setup And Throws Fake Errors Each Time It Starts

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

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

Please bring this kind of thing up on the user's list rather than raise JIRAs
to be sure you're not simply misunderstanding things. If it's a real problem in
Solr, _then_ raise a JIRA.

Probably in this case you have no core.properties file. Which is mandatory
for Solr finding a core.

Solr Forgets Core Setup And Throws Fake Errors Each Time It Starts
--

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

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

[jira] [Resolved] (SOLR-7896) Solr Administrative Interface Lacks Password Protection

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

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

Please bring this kind of thing up on the user's list rather than raise JIRAs
to be sure you're not simply misunderstanding things. If it's a real problem in
Solr, _then_ raise a JIRA.

Solr has _never_ been intended to allow end-user access and thus has never
implemented this kind of security. You allow me to get to the Solr URL directly
and I can
http://machine:port/solr/collection/update?commit=truestream.body=deletequery*:*/query/delete

All your docs are gone.

Solr Administrative Interface Lacks Password Protection
---

Key: SOLR-7896
URL: https://issues.apache.org/jira/browse/SOLR-7896
Project: Solr
Issue Type: Bug
Components: security, web gui
Affects Versions: 5.2.1
Reporter: Aaron Greenspan
Priority: Critical

--
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-7895) Administrative UI Lacks Obvious Delete Core Contents Button

[
https://issues.apache.org/jira/browse/SOLR-7895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661332#comment-14661332
]

Shawn Heisey commented on SOLR-7895:

The deleteByQuery action will mark all the documents deleted, but when it is
done, the disk still has all the index files, and for many features, those
documents are still utilized, although they will be pruned from results. For
some config/schema changes, deleting all the docs in the index isn't enough to
prevent errors.

I would like to have a button that actually deletes the data directory, after
appropriate confirmation. In order to allow it to work on Windows, it would
probably need to unload the core, delete the directory and all its contents,
and then re-create the core. When the core is created, the dataDir and its
index directory will be rebuilt. Appropriate permissions on the filesystem are
required, but usually if you can delete the directory, you can create it again.

Administrative UI Lacks Obvious Delete Core Contents Button
-

Key: SOLR-7895
URL: https://issues.apache.org/jira/browse/SOLR-7895
Project: Solr
Issue Type: Improvement
Affects Versions: 5.2.1
Reporter: Aaron Greenspan

When Solr screws up, which is practically on a daily basis, I often want to
delete the contents of a core without deleting its structure. Instead of
clicking on a button and perhaps an Are you sure? prompt, I have to
remember this incredibly unwieldy and dangerous-to-bookmark URL:
http://[server]:8983/solr/[core
name]/update?stream.body=%3Cdelete%3E%3Cquery%3Eid:*%3C/query%3E%3C/delete%3Ecommit=true
To say that this is not user-friendly is a gross understatement. If there is
a better way or an obvious easy way, I have not found 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-7896) Solr Administrative Interface Lacks Password Protection

[
https://issues.apache.org/jira/browse/SOLR-7896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661341#comment-14661341
]

Aaron Greenspan commented on SOLR-7896:
---

It's all well and good to say that users shouldn't do things, but they're being
done, and the code needs to be written to account for real-world use, not some
hypothetical ideal that doesn't exist.

Solr Administrative Interface Lacks Password Protection
---

Key: SOLR-7896
URL: https://issues.apache.org/jira/browse/SOLR-7896
Project: Solr
Issue Type: Bug
Components: security, web gui
Affects Versions: 5.2.1
Reporter: Aaron Greenspan
Priority: Critical

--
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-7896) Solr Administrative Interface Lacks Password Protection


[ 
https://issues.apache.org/jira/browse/SOLR-7896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661342#comment-14661342
 ] 

Aaron Greenspan commented on SOLR-7896:
---

I find it incredibly surprising that you could write the above and then change 
the issue status to Not a Problem.

 Solr Administrative Interface Lacks Password Protection
 ---

 Key: SOLR-7896
 URL: https://issues.apache.org/jira/browse/SOLR-7896
 Project: Solr
  Issue Type: Bug
  Components: security, web gui
Affects Versions: 5.2.1
Reporter: Aaron Greenspan
Priority: Critical

 Out of the box, the Solr interface should require an administrative password 
 that the user is required to set. Apparently there are ways of configuring 
 Jetty to do this with HTTP AUTH or whatever. I'm a moderately experienced 
 Linux admin and a programmer; I've tried, numerous times, and I've not once 
 been able to get it to work. The point is this, though:
 *No one should have to try to get their Solr instance to support password 
 authentication and preferably SSL (even if it's just with a self-signed 
 certificate). Solr is designed to store huge amounts of data and is therefore 
 a likely target for malicious users.*
 This needs to be addressed! It's 2015 and Solr is on version 5!



--
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-7895) Administrative UI Lacks Obvious Delete Core Contents Button