date:20150506

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

3 tests failed.
FAILED:  org.apache.solr.cloud.SaslZkACLProviderTest.testSaslZkACLProvider

Error Message:
Could not get the port for ZooKeeper server

Stack Trace:
java.lang.RuntimeException: Could not get the port for ZooKeeper server
at org.apache.solr.cloud.ZkTestServer.run(ZkTestServer.java:506)
at 
org.apache.solr.cloud.SaslZkACLProviderTest$SaslZkTestServer.run(SaslZkACLProviderTest.java:226)
at 
org.apache.solr.cloud.SaslZkACLProviderTest.setUp(SaslZkACLProviderTest.java:91)
at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
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$7.evaluate(RandomizedRunner.java:870)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
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 java.lang.Thread.run(Thread.java:745)


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

Error Message:
6 threads leaked from SUITE scope at 
org.apache.solr.cloud.SaslZkACLProviderTest: 1) Thread[id=5626, 
name=NioSocketAcceptor-1, state=RUNNABLE, group=TGRP-SaslZkACLProviderTest] 
at sun.nio.ch.KQueueArrayWrapper.kevent0(Native Method) at 
sun.nio.ch.KQueueArrayWrapper.poll(KQueueArrayWrapper.java:198) at

[jira] [Created] (LUCENE-6466) Move SpanQuery.getSpans() to SpanWeight

2015-05-06 Thread Alan Woodward (JIRA)

Alan Woodward created LUCENE-6466:
-

 Summary: Move SpanQuery.getSpans() to SpanWeight
 Key: LUCENE-6466
 URL: https://issues.apache.org/jira/browse/LUCENE-6466
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Alan Woodward
Priority: Minor


SpanQuery.getSpans() should only be called on rewritten queries, so it seems to 
make more sense to have this being called from SpanWeight



--
This message was sent by Atlassian 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-6466) Move SpanQuery.getSpans() to SpanWeight

2015-05-06 Thread Alan Woodward (JIRA)


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

Alan Woodward updated LUCENE-6466:
--
Attachment: LUCENE-6466.patch

Here is a patch.  SpanQuery.createWeight() is now final, and delegates on to an 
abstract method #createSpanWeight().  This takes an additional boolean 
parameter to determine whether or not the weight is at the top of a span tree, 
in which case it should build term stats.

Ideally I'd have liked to move SpanQuery.extractTerms() to SpanWeight as well, 
but that causes complications when collecting terms in the SpanWeight 
constructor (basically you can't call extractTerms on a delegate from a super 
constructor, because the delegate hasn't been set yet).

 Move SpanQuery.getSpans() to SpanWeight
 ---

 Key: LUCENE-6466
 URL: https://issues.apache.org/jira/browse/LUCENE-6466
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Alan Woodward
Priority: Minor
 Attachments: LUCENE-6466.patch


 SpanQuery.getSpans() should only be called on rewritten queries, so it seems 
 to make more sense to have this being called from SpanWeight



--
This message was sent by Atlassian 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-7436) Solr stops printing stacktraces in log and output

2015-05-06 Thread Ramkumar Aiyengar (JIRA)


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

Ramkumar Aiyengar commented on SOLR-7436:
-

I remember encountering this quite a few months and being left completely 
puzzled, and gave up after trying stuff like digging into code for Exception 
classes. Hoss' links seem to explain this.

For a server at least this is really trippy behaviour and we should switch it 
off with the startup script. Imagine you having cloud trouble and you 
eventually resolving it. All exceptions thrown during the trouble will now be 
hot and any unrelated issues after the issue is past will be hard to debug..

 Solr stops printing stacktraces in log and output
 -

 Key: SOLR-7436
 URL: https://issues.apache.org/jira/browse/SOLR-7436
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.1
 Environment: Local 5.1
Reporter: Markus Jelsma
 Attachments: solr-8983-console.log


 After a short while, Solr suddenly stops printing stacktraces in the log and 
 output. 
 {code}
 251043 [qtp1121454968-17] INFO  org.apache.solr.core.SolrCore.Request  [   
 suggests] - [suggests] webapp=/solr path=/select 
 params={q=*:*fq={!collapse+field%3Dquery_digest}fq={!collapse+field%3Dresult_digest}}
  status=500 QTime=3 
 251043 [qtp1121454968-17] ERROR org.apache.solr.servlet.SolrDispatchFilter  [ 
   suggests] - null:java.lang.NullPointerException
 at 
 org.apache.solr.search.CollapsingQParserPlugin$IntScoreCollector.finish(CollapsingQParserPlugin.java:743)
 at 
 org.apache.solr.search.CollapsingQParserPlugin$IntScoreCollector.finish(CollapsingQParserPlugin.java:780)
 at 
 org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:203)
 at 
 org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1660)
 at 
 org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1479)
 at 
 org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:556)
 at 
 org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:518)
 at 
 org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:222)
 at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
 at org.apache.solr.core.SolrCore.execute(SolrCore.java:1984)
 at 
 org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:829)
 at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:446)
 at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:220)
 at 
 org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
 at 
 org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
 at 
 org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
 at 
 org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
 at 
 org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
 at 
 org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
 at 
 org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
 at 
 org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
 at 
 org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
 at 
 org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
 at 
 org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
 at 
 org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
 at 
 org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
 at org.eclipse.jetty.server.Server.handle(Server.java:368)
 at 
 org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
 at 
 org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
 at 
 org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
 at 
 org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
 at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
 at 
 org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
 at 
 org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
 at

Re: Modifying DefaultSolrHighlighter

2015-05-06 Thread Dmitry Kan

Thanks, David.

Will let you know, how it went.

On 5 May 2015 at 20:01, david.w.smi...@gmail.com david.w.smi...@gmail.com
wrote:

 Yes.

 On Tue, May 5, 2015 at 8:29 AM Dmitry Kan dmitry.luc...@gmail.com wrote:

 Hi David,

 Thanks for replying so quick! Indeed, the NPE points to SolrCore being
 null. So of the following two ctors:

 public DefaultSolrHighlighter() {
 }

 public DefaultSolrHighlighter(SolrCore solrCore) {
   this.solrCore = solrCore;
 }



 should we use the second one?

 Regards,
 Dmitry

 On 5 May 2015 at 15:03, david.w.smi...@gmail.com 
 david.w.smi...@gmail.com wrote:

 Hi Dmitry,

 I am pretty well versed in the sub-class-ability of
 DefaultSolrHighlighter.  Most likely the problem you see is that you are
 using the no-arg constructor.  Instead, pass in a SolrCore.  It is called
 via reflection.  In 5.2 I removed the no-arg constructor.

 ~ David

 On Tue, May 5, 2015 at 4:24 AM Dmitry Kan dmitry.luc...@gmail.com
 wrote:

 Hi,

 We need to modify the behaviour of DefaultSolrHighlighter class
 slightly. When we tried to extend the class, Solr prints NPE.

 Is there some reason to the NPE when extending the class?

 Thanks,

 Dmitry Kan

[jira] [Commented] (LUCENE-6372) Simplify hashCode/equals for SpanQuery subclasses


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

Paul Elschot commented on LUCENE-6372:
--

I'll remove the comment and use a multiplicative hash instead of rotations.

Query has a this == other test in equals().
When this passes in the Query superclass, the subclass still has to check its 
members.
Wouldn't it be better to do that test only in non abstract classes as the first 
thing to be checked, if at all?
This is actually another issue, but anyway.

 Simplify hashCode/equals for SpanQuery subclasses
 -

 Key: LUCENE-6372
 URL: https://issues.apache.org/jira/browse/LUCENE-6372
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Paul Elschot
 Attachments: LUCENE-6372.patch


 Spin off from LUCENE-6308, see the comments there from around 23 March 2015.



--
This message was sent by Atlassian 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-6412) Merge SpanTermQuery into TermQuery

2015-05-06 Thread Alan Woodward (JIRA)


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

Alan Woodward resolved LUCENE-6412.
---
Resolution: Won't Fix

I'll resolve this as Won't Fix, then, for now at least.

 Merge SpanTermQuery into TermQuery
 --

 Key: LUCENE-6412
 URL: https://issues.apache.org/jira/browse/LUCENE-6412
 Project: Lucene - Core
  Issue Type: Improvement
Affects Versions: Trunk, 5.2
Reporter: Alan Woodward
Priority: Minor
 Attachments: LUCENE-6412.patch


 Having a separate SpanTermQuery doesn't actually gain us anything now, and 
 it's trivial enough to make TermQuery extend SpanQuery copy the getSpans() 
 and getField() impls over from STQ.



--
This message was sent by Atlassian 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-6463) Share more logic between our approximated queries


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

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

Thanks for having a look David, I added RandomAccessWeight and applied your 
suggestions!

 Share more logic between our approximated queries
 -

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


 We have several queries that support approximations, and in particular the 
 ones based on random-access (doc values terms/range, FieldValueFilter, ...) 
 duplicate some logic.



--
This message was sent by Atlassian 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-6465) Add protectiondomain to expressions compiler

2015-05-06 Thread Robert Muir (JIRA)

Robert Muir created LUCENE-6465:
---

 Summary: Add protectiondomain to expressions compiler
 Key: LUCENE-6465
 URL: https://issues.apache.org/jira/browse/LUCENE-6465
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir


Today the classloader is somewhat hidden, you don't have a way to pass this. 
But since we are generating classes on the fly, we should allow it to be 
optionally specified.



--
This message was sent by Atlassian 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-7275) Pluggable authorization module in Solr

2015-05-06 Thread Anshum Gupta (JIRA)


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

Anshum Gupta updated SOLR-7275:
---
Attachment: SOLR-7275.patch

Updated patch that returns a request type and the list of collections involved 
in the request. It also works for aliases i.e. returns the collection list 
instead of alias name.
The request type right now is left to unknown for cases other than ADMIN 
requests. In case of admin requests, it's set to 'ADMIN'.

 Pluggable authorization module in Solr
 --

 Key: SOLR-7275
 URL: https://issues.apache.org/jira/browse/SOLR-7275
 Project: Solr
  Issue Type: Sub-task
Reporter: Anshum Gupta
Assignee: Anshum Gupta
 Attachments: SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, 
 SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch


 Solr needs an interface that makes it easy for different authorization 
 systems to be plugged into it. Here's what I plan on doing:
 Define an interface {{SolrAuthorizationPlugin}} with one single method 
 {{isAuthorized}}. This would take in a {{SolrRequestContext}} object and 
 return an {{SolrAuthorizationResponse}} object. The object as of now would 
 only contain a single boolean value but in the future could contain more 
 information e.g. ACL for document filtering etc.
 The reason why we need a context object is so that the plugin doesn't need to 
 understand Solr's capabilities e.g. how to extract the name of the collection 
 or other information from the incoming request as there are multiple ways to 
 specify the target collection for a request. Similarly request type can be 
 specified by {{qt}} or {{/handler_name}}.
 Flow:
 Request - SolrDispatchFilter - isAuthorized(context) - Process/Return.
 {code}
 public interface SolrAuthorizationPlugin {
   public SolrAuthorizationResponse isAuthorized(SolrRequestContext context);
 }
 {code}
 {code}
 public  class SolrRequestContext {
   UserInfo; // Will contain user context from the authentication layer.
   HTTPRequest request;
   Enum OperationType; // Correlated with user roles.
   String[] CollectionsAccessed;
   String[] FieldsAccessed;
   String Resource;
 }
 {code}
 {code}
 public class SolrAuthorizationResponse {
   boolean authorized;
   public boolean isAuthorized();
 }
 {code}
 User Roles: 
 * Admin
 * Collection Level:
   * Query
   * Update
   * Admin
 Using this framework, an implementation could be written for specific 
 security systems e.g. Apache Ranger or Sentry. It would keep all the security 
 system specific code out of 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] (LUCENE-6465) Add protectiondomain to expressions compiler

2015-05-06 Thread Ryan Ernst (JIRA)


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

Ryan Ernst commented on LUCENE-6465:


+1

Do we really need to have so many variants of compile? Could we stick with a 
simple one (just takes the expression text) and one full featured one? It is 
simple for advanced users who need to set protectiond omain to use the more 
advanced one with JavascriptComipiler.DEFAULT_FUNCTIONS and 
JavascriptCompiler.class.getClassLoader()?

 Add protectiondomain to expressions compiler
 

 Key: LUCENE-6465
 URL: https://issues.apache.org/jira/browse/LUCENE-6465
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-6465.patch


 Today the classloader is somewhat hidden, you don't have a way to pass this. 
 But since we are generating classes on the fly, we should allow it to be 
 optionally specified.



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

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

Re: [jira] [Commented] (LUCENE-6465) Add protectiondomain to expressions compiler

2015-05-06 Thread Robert Muir

Hi Uwe,

http://pastebin.com/TLfNEnHt

One thing I'm worried about is that it works for anything more than a
simple static permissions case. The sophisticated ctor requires
classloader, but we actually make our own internally.


On Wed, May 6, 2015 at 4:01 AM, Uwe Schindler u...@thetaphi.de wrote:
 Hi,

 I would like to review this - because I was talking with Robert about this 
 yesterday, but JIRA does not work for me (loads endless so Chrome says: page 
 does not respond). Can you post a link to the patch here?

 Uwe

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


 -Original Message-
 From: Ryan Ernst (JIRA) [mailto:j...@apache.org]
 Sent: Wednesday, May 06, 2015 9:45 AM
 To: dev@lucene.apache.org
 Subject: [jira] [Commented] (LUCENE-6465) Add protectiondomain to
 expressions compiler


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

 Ryan Ernst commented on LUCENE-6465:
 

 +1

 Do we really need to have so many variants of compile? Could we stick with a
 simple one (just takes the expression text) and one full featured one? It is
 simple for advanced users who need to set protectiond omain to use the
 more advanced one with JavascriptComipiler.DEFAULT_FUNCTIONS and
 JavascriptCompiler.class.getClassLoader()?

  Add protectiondomain to expressions compiler
  
 
  Key: LUCENE-6465
  URL: https://issues.apache.org/jira/browse/LUCENE-6465
  Project: Lucene - Core
   Issue Type: Bug
 Reporter: Robert Muir
  Attachments: LUCENE-6465.patch
 
 
  Today the classloader is somewhat hidden, you don't have a way to pass
 this. But since we are generating classes on the fly, we should allow it to 
 be
 optionally specified.



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

 -
 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] (SOLR-5200) Add REST support for reading and modifying Solr configuration

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


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

Shalin Shekhar Mangar updated SOLR-5200:

Description: 
There should be a REST API to allow full read access to, and write access to 
some elements of, Solr's per-core and per-node configuration not already 
covered by the Schema REST API: 
{{solrconfig.xml}}/{{core.properties}}/{{solrcore.properties}} and 
{{solr.xml}}/{{solr.properties}} (SOLR-4718 discusses addition of 
{{solr.properties}}).

Use cases for runtime configuration modification include scripted setup, 
troubleshooting, and tuning.

Tentative rules-of-thumb about configuration items that should not be 
modifiable at runtime:

# Startup-only items, e.g. where to start core discovery
# Items that are deprecated in 4.X and will be removed in 5.0
# Items that if modified should be followed by a full re-index

Some issues to consider:

Persistence: How (and even whether) to handle persistence for configuration 
modifications via REST API is not clear - e.g. persisting the entire config 
file or having one or more sidecar config files that get persisted.  The extent 
of what should be modifiable will likely affect how persistence is implemented. 
 For example, if the only {{solrconfig.xml}} modifiable items turn out to be 
plugin configurations, an alternative to full-{{solrconfig.xml}} persistence 
could be individual plugin registration of runtime config modifiable items, 
along with per-plugin sidecar config persistence.

Live reload: Most (if not all) per-core configuration modifications will 
require core reload, though it will be a live reload, so some things won't be 
modifiable, e.g. {{dataDir}} and {{IndexWriter}} related settings in 
{{indexConfig}} - see SOLR-3592.  (Should a full reload be supported to 
handle changes in these places?)

Interpolation aka property substitution: I think it would be useful on read 
access to optionally return raw values in addition to the interpolated values, 
e.g. {{solr.xml}} {{hostPort}} raw value {{$\{jetty.port:8983}}} vs. 
interpolated value {{8983}}.   Modification requests will accept raw values - 
property interpolation will be applied.  At present interpolation is done once, 
at parsing time, but if property value modificationmvn archetype:generate 
-DgroupId=com.mkyong.core -DartifactId=ProjectName
-DarchetypeArtifactId=maven-archetype-quickstart 
-DinteractiveMode=falsemvn archetype:generate -DgroupId=com.mkyong.core 
-DartifactId=ProjectName
-DarchetypeArtifactId=maven-archetype-quickstart 
-DinteractiveMode=falsemvn archetype:generate -DgroupId=com.mkyong.core 
-DartifactId=ProjectName
-DarchetypeArtifactId=maven-archetype-quickstart 
-DinteractiveMode=false is supported via the REST API, an alternative could be 
to delay interpolation until values are requested; in this way, property value 
modification would not trigger re-parsing the affected configuration source.

Response format: Similarly to the schema REST API, results could be returned in 
XML, JSON, or any other response writer's output format.

Transient cores: How should non-loaded transient cores be handled?  Simplest 
thing would be to load the transient core before handling the request, just 
like other requests.

Below I provide an exhaustive list of configuration items in the files in 
question and indicate which ones I think could be modifiable at runtime.  I 
don't mean to imply that these must all be made modifiable, or for those that 
are made modifiable, that they must be made so at once - a piecemeal approach 
will very likely be more appropriate.

h2. {{solrconfig.xml}}

Note that XIncludes and includes via Document Entities won't survive a 
modification request (assuming persistence is via overwriting the original 
file).

||XPath under {{/config/}}||Should be modifiable via REST 
API?||Rationale||Description||
|{{luceneMatchVersion}}|No|Modifying this should be followed by a full 
re-index|Controls what version of Lucene various components of Solr adhere to|
|{{lib}}|Yes|Required for adding plugins at runtime|Contained jars available 
via classloader for {{solrconfig.xml}} and {{schema.xml}}| 
|{{dataDir}}|No|Not supported by live RELOAD|Holds all index data|
|{{directoryFactory}}|No|Not supported by live RELOAD|index directory factory|
|{{codecFactory}}|No|Modifying this should be followed by a full re-index|index 
codec factory, per-field SchemaCodecFactory by default|
|{{schemaFactory}}|Partial|Although the class shouldn't be modifiable, it 
should be possible to modify an already Managed schema's mutability|Managed or 
Classic (non-mutable) schema factory|
|{{indexConfig}}|No|{{IndexWriter}}-related settings not supported by live 
RELOAD|low-level indexing behavior|
|{{jmx}}|Yes| |Enables JMX if an MBeanServer is found|
|{{updateHandler@class}}|No| |Defaults to DirectUpdateHandler2|
|{{updateHandler/updateLog}}|No|

[jira] [Updated] (LUCENE-6465) Add protectiondomain to expressions compiler

2015-05-06 Thread Robert Muir (JIRA)


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

Robert Muir updated LUCENE-6465:

Attachment: LUCENE-6465.patch

patch with a simple test.

 Add protectiondomain to expressions compiler
 

 Key: LUCENE-6465
 URL: https://issues.apache.org/jira/browse/LUCENE-6465
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-6465.patch


 Today the classloader is somewhat hidden, you don't have a way to pass this. 
 But since we are generating classes on the fly, we should allow it to be 
 optionally specified.



--
This message was sent by Atlassian 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-7012) add an ant target to package a plugin into a jar

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


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

Shalin Shekhar Mangar commented on SOLR-7012:
-

I propose that we piggy back on maven's archetype support and have Solr publish 
its own solr-plugin archetype. Then anybody who wants to write a solr plugin 
can execute e.g.
{code}
mvn archetype:generate -DgroupId=com.my.solrplugin -DartifactId=my-solr-plugin
-DarchetypeGroupId=org.apache.solr -DarchetypeArtifactId=solr-plugin 
-DinteractiveMode=false
{code}

This will create project structure with a custom pom.xml with appropriate 
defaults that we (Solr) can control.

 add an ant target to package a plugin into a jar
 

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


 Now it is extremely hard to create  plugin because the user do not know about 
 the exact dependencies and their poms
 we will add a target to solr/build.xml called plugin-jar
 invoke it as follows
 {code}
 ant -Dplugin.package=my.package -Djar.location=/tmp/my.jar plugin-jar
 {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] [Comment Edited] (SOLR-7012) add an ant target to package a plugin into a jar

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


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

Shalin Shekhar Mangar edited comment on SOLR-7012 at 5/6/15 7:53 AM:
-

I propose that we piggy back on maven's archetype support and have Solr publish 
its own solr-plugin archetype. Then anybody who wants to write a solr plugin 
can execute e.g.
{code}
mvn archetype:generate -DgroupId=com.my.solrplugin -DartifactId=my-solr-plugin
-DarchetypeGroupId=org.apache.solr -DarchetypeArtifactId=solr-plugin 
-DinteractiveMode=false
{code}

This will create project structure with a custom pom.xml with appropriate 
defaults that we (Solr) can control.

See http://maven.apache.org/guides/mini/guide-creating-archetypes.html


was (Author: shalinmangar):
I propose that we piggy back on maven's archetype support and have Solr publish 
its own solr-plugin archetype. Then anybody who wants to write a solr plugin 
can execute e.g.
{code}
mvn archetype:generate -DgroupId=com.my.solrplugin -DartifactId=my-solr-plugin
-DarchetypeGroupId=org.apache.solr -DarchetypeArtifactId=solr-plugin 
-DinteractiveMode=false
{code}

This will create project structure with a custom pom.xml with appropriate 
defaults that we (Solr) can control.

 add an ant target to package a plugin into a jar
 

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


 Now it is extremely hard to create  plugin because the user do not know about 
 the exact dependencies and their poms
 we will add a target to solr/build.xml called plugin-jar
 invoke it as follows
 {code}
 ant -Dplugin.package=my.package -Djar.location=/tmp/my.jar plugin-jar
 {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

RE: [jira] [Commented] (LUCENE-6465) Add protectiondomain to expressions compiler

2015-05-06 Thread Uwe Schindler

Hi,

I would like to review this - because I was talking with Robert about this 
yesterday, but JIRA does not work for me (loads endless so Chrome says: page 
does not respond). Can you post a link to the patch here?

Uwe

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


 -Original Message-
 From: Ryan Ernst (JIRA) [mailto:j...@apache.org]
 Sent: Wednesday, May 06, 2015 9:45 AM
 To: dev@lucene.apache.org
 Subject: [jira] [Commented] (LUCENE-6465) Add protectiondomain to
 expressions compiler
 
 
 [ https://issues.apache.org/jira/browse/LUCENE-
 6465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
 tabpanelfocusedCommentId=14530102#comment-14530102 ]
 
 Ryan Ernst commented on LUCENE-6465:
 
 
 +1
 
 Do we really need to have so many variants of compile? Could we stick with a
 simple one (just takes the expression text) and one full featured one? It is
 simple for advanced users who need to set protectiond omain to use the
 more advanced one with JavascriptComipiler.DEFAULT_FUNCTIONS and
 JavascriptCompiler.class.getClassLoader()?
 
  Add protectiondomain to expressions compiler
  
 
  Key: LUCENE-6465
  URL: https://issues.apache.org/jira/browse/LUCENE-6465
  Project: Lucene - Core
   Issue Type: Bug
 Reporter: Robert Muir
  Attachments: LUCENE-6465.patch
 
 
  Today the classloader is somewhat hidden, you don't have a way to pass
 this. But since we are generating classes on the fly, we should allow it to be
 optionally specified.
 
 
 
 --
 This message was sent by Atlassian JIRA
 (v6.3.4#6332)
 
 -
 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] [Closed] (LUCENE-6372) Simplify hashCode/equals for SpanQuery subclasses


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

Paul Elschot closed LUCENE-6372.

Resolution: Fixed

 Simplify hashCode/equals for SpanQuery subclasses
 -

 Key: LUCENE-6372
 URL: https://issues.apache.org/jira/browse/LUCENE-6372
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Paul Elschot
Assignee: Adrien Grand
 Attachments: LUCENE-6372.patch, LUCENE-6372.patch


 Spin off from LUCENE-6308, see the comments there from around 23 March 2015.



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

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

[jira] [Closed] (LUCENE-6373) Complete two phase doc id iteration support for Spans


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

Paul Elschot closed LUCENE-6373.


 Complete two phase doc id iteration support for Spans
 -

 Key: LUCENE-6373
 URL: https://issues.apache.org/jira/browse/LUCENE-6373
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Paul Elschot
 Fix For: Trunk, 5.2

 Attachments: LUCENE-6373-20150426.patch, LUCENE-6373-SpanOr.patch, 
 LUCENE-6373.patch, LUCENE-6373.patch, LUCENE-6737-SpanOr-oneTestFails.patch


 Spin off from LUCENE-6308, see comments there from about 23 March 2015.



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

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

[jira] [Closed] (LUCENE-3325) Transpose positions in index


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

Paul Elschot closed LUCENE-3325.


 Transpose positions in index
 

 Key: LUCENE-3325
 URL: https://issues.apache.org/jira/browse/LUCENE-3325
 Project: Lucene - Core
  Issue Type: Wish
  Components: core/index
Reporter: Paul Elschot
Priority: Minor

 When positions are used in queries with many terms, each term in each 
 document causes a seek in the positions, and in large indexes these seeks can 
 be far apart even when the terms are in the same document.
 The number of (disk) cache misses of such position seeks might be reduced by 
 putting the positions for all terms in the same document directly behind each 
 other. This should have a noticable effect when terms are alphabetically 
 close, for example for truncations, and it should also help when the 
 documents have few enough positions to fill a cache entry (disk page, cache 
 line).
 This might also help the performance of highlighting based on indexed 
 positions.



--
This message was sent by Atlassian 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-7341) xjoin - join data from external sources


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

Tom Winch updated SOLR-7341:

Description: 
h2. XJoin

The xjoin SOLR contrib allows external results to be joined with SOLR results 
in a query and the SOLR result set to be filtered by the results of an external 
query. Values from the external results are made available in the SOLR results 
and may also be used to boost the scores of corresponding documents during the 
search. The contrib consists of the Java classes XJoinSearchComponent, 
XJoinValueSourceParser and XJoinQParserPlugin (and associated classes), which 
must be configured in solrconfig.xml, and the interfaces XJoinResultsFactory 
and XJoinResults, which are implemented by the user to provide the link between 
SOLR and the external results source. External results and SOLR documents are 
matched via a single configurable attribute (the join field). The contrib JAR 
solr-xjoin-4.10.3.jar contains these classes and interfaces and should be 
included in SOLR's class path from solrconfig.xml, as should a JAR containing 
the user implementations of the previously mentioned interfaces. For example:

{code:xml}
config
  ..
  !-- XJoin contrib JAR file --
  lib dir=${solr.install.dir:../../..}/dist/ regex=solr-xjoin-\d.*\.jar /
  ..
  !-- user implementations of XJoin interfaces --
  lib path=/path/to/xjoin_test.jar /
  ..
/config
{code}

h2. Java classes and interfaces

h3. XJoinResultsFactory

The user implementation of this interface is responsible for connecting to an 
external source to perform a query (or otherwise collect results). Parameters 
with prefix component name.external. are passed from the SOLR query URL to 
pararameterise the search. The interface has the following methods:

* void init(NamedList args) - this is called during SOLR initialisation, and 
passed parameters from the search component configuration (see below)
* XJoinResults getResults(SolrParams params) - this is called during a SOLR 
search to generate external results, and is passed parameters from the SOLR 
query URL (as above)

For example, the implementation might perform queries of an external source 
based on the 'q' SOLR query URL parameter (in full, component 
name.external.q).

h3. XJoinResults
A user implementation of this interface is returned by the getResults() method 
of the XJoinResultsFactory implementation. It has methods:

* Object getResult(String joinId) - this should return a particular result 
given the value of the join attribute
* IterableString getJoinIds() - this should return the join attribute values 
for all results of the external search

h3. XJoinSearchComponent

This is the central Java class of the contrib. It is a SOLR search component, 
configured in solrconfig.xml and included in one or more SOLR request handlers. 
There is one XJoin search component per external source, and each has two main 
responsibilities:

* Before the SOLR search, it connects to the external source and retrieves 
results, storing them in the SOLR request context
* After the SOLR search, it matches SOLR document in the results set and 
external results via the join field, adding attributes from the external 
results to documents in the SOLR results set

It takes the following initialisation parameters:

* factoryClass - this specifies the user-supplied class implementing 
XJoinResultsFactory, used to generate external results
* joinField - this specifies the attribute on which to join between SOLR 
documents and external results
* external - this parameter set is passed to configure the XJoinResultsFactory 
implementation

For example, in solrconfig.xml:

{code:xml}
searchComponent name=xjoin_test 
class=org.apache.solr.search.xjoin.XJoinSearchComponent
  str name=factoryClasstest.TestXJoinResultsFactory/str
  str name=joinFieldid/str
  lst name=external
str name=values1,2,3/str
  /lst
/searchComponent
{code}

Here, the search component instantiates a new TextXJoinResultsFactory during 
initialisation, and passes it the values parameter (1, 2, 3) to configure it. 
To properly use the XJoinSearchComponent in a request handler, it must be 
included at the start and end of the component list, and may be configured with 
the following query parameters:

* results - a comma-separated list of attributes from the XJoinResults 
implementation (created by the factory at search time) to be included in the 
SOLR results
* fl - a comma-separated list of attributes from results objects (contained in 
an XJoinResults implementation) to be included in the SOLR results

For example:
{code:xml}
requestHandler name=/xjoin class=solr.SearchHandler startup=lazy
  lst name=defaults
..
bool name=xjoin_testtrue/bool
str name=xjoin_test.listParameterxx/str
str name=xjoin_test.resultstest_count/str
str name=xjoin_test.flid,value/str
  /lst
  arr name=first-components
strxjoin_test/str
  /arr
  arr

[jira] [Commented] (SOLR-6688) There should be no error about a non-required file admin-extra.html

2015-05-06 Thread Marcos Loureiro (JIRA)


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

Marcos Loureiro commented on SOLR-6688:
---

[~arafalov]

I was having the same issue, on the {{solrconfig.xml}} removed the tag 
{{admin}}
And the error vanished

  !-- Legacy config for the admin interface --
  admin
defaultQuery*:*/defaultQuery
  /admin

 There should be no error about a non-required file admin-extra.html
 ---

 Key: SOLR-6688
 URL: https://issues.apache.org/jira/browse/SOLR-6688
 Project: Solr
  Issue Type: Bug
Reporter: Arkadiusz Robiński
Priority: Minor

 I am using SOLR 4.10.1. I have a simple configuration with 2 cores. Every 
 time I open the SOLR admin interface, I get the following errors:
 {noformat}
 Can not find: admin-extra.html
 Can not find: admin-extra.menu-top.html
 Can not find: admin-extra.menu-bottom.html
 {noformat}
 As far as I know, the files are optional. Therefore I should not get any 
 error, not even a warning.
 I do not want to create the files because I do not need them. The error 
 should simply not be there.



--
This message was sent by Atlassian 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-6372) Simplify hashCode/equals for SpanQuery subclasses


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

Paul Elschot commented on LUCENE-6372:
--

One typical case for equals() is a newly constructed query compared against a 
query as a key in a cache.
In that case the this == other test in Query.equals() will fail, so it can just 
as well be removed, and never done.

Are there other typical cases for Query.equals()?
For example one could cache the result of a query parser by its input string, 
and reuse a query from that cache to check a cache with query results. In that 
case the this == other test might help in equals() for non abstract Query 
subclasses.

 Simplify hashCode/equals for SpanQuery subclasses
 -

 Key: LUCENE-6372
 URL: https://issues.apache.org/jira/browse/LUCENE-6372
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Paul Elschot
 Attachments: LUCENE-6372.patch, LUCENE-6372.patch


 Spin off from LUCENE-6308, see the comments there from around 23 March 2015.



--
This message was sent by Atlassian 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-6372) Simplify hashCode/equals for SpanQuery subclasses


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

Adrien Grand commented on LUCENE-6372:
--

The patch looks good to me! I'll commit shortly.

 Simplify hashCode/equals for SpanQuery subclasses
 -

 Key: LUCENE-6372
 URL: https://issues.apache.org/jira/browse/LUCENE-6372
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Paul Elschot
 Attachments: LUCENE-6372.patch, LUCENE-6372.patch


 Spin off from LUCENE-6308, see the comments there from around 23 March 2015.



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

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

[Apache Solr] Solrj - Suggestions and Clusters properly managed in the response

2015-05-06 Thread Alessandro Benedetti

Hi guys,
as we well know the SolrJ QueryResponse[1] class has a set of methods to
return particular components of the response in a pretty and organised way.
This allow the SolrJ user to easily get Facets, spellcheck
suggestions ect ect avoiding the Json parsing of the response.

Currently this is not implemented for suggestions ( from the suggester
components), or for clusters ( using the clustering plugin) .

Is it going to be available soon ? Any issue related ?

Cheers


[1] http://lucene.apache.org/solr/5_1_0/solr-solrj/index.html

-- 
--

Benedetti Alessandro
Visiting card : http://about.me/alessandro_benedetti

Tyger, tyger burning bright
In the forests of the night,
What immortal hand or eye
Could frame thy fearful symmetry?

William Blake - Songs of Experience -1794 England

[jira] [Commented] (SOLR-7436) Solr stops printing stacktraces in log and output

2015-05-06 Thread Markus Jelsma (JIRA)


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

Markus Jelsma commented on SOLR-7436:
-

I can confirm OmitStackTraceInFastThrow resolves the issue. This should indeed 
be part of the JVM flags for Solr instances.

 Solr stops printing stacktraces in log and output
 -

 Key: SOLR-7436
 URL: https://issues.apache.org/jira/browse/SOLR-7436
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.1
 Environment: Local 5.1
Reporter: Markus Jelsma
 Attachments: solr-8983-console.log


 After a short while, Solr suddenly stops printing stacktraces in the log and 
 output. 
 {code}
 251043 [qtp1121454968-17] INFO  org.apache.solr.core.SolrCore.Request  [   
 suggests] - [suggests] webapp=/solr path=/select 
 params={q=*:*fq={!collapse+field%3Dquery_digest}fq={!collapse+field%3Dresult_digest}}
  status=500 QTime=3 
 251043 [qtp1121454968-17] ERROR org.apache.solr.servlet.SolrDispatchFilter  [ 
   suggests] - null:java.lang.NullPointerException
 at 
 org.apache.solr.search.CollapsingQParserPlugin$IntScoreCollector.finish(CollapsingQParserPlugin.java:743)
 at 
 org.apache.solr.search.CollapsingQParserPlugin$IntScoreCollector.finish(CollapsingQParserPlugin.java:780)
 at 
 org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:203)
 at 
 org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1660)
 at 
 org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1479)
 at 
 org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:556)
 at 
 org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:518)
 at 
 org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:222)
 at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
 at org.apache.solr.core.SolrCore.execute(SolrCore.java:1984)
 at 
 org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:829)
 at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:446)
 at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:220)
 at 
 org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
 at 
 org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
 at 
 org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
 at 
 org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
 at 
 org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
 at 
 org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
 at 
 org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
 at 
 org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
 at 
 org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
 at 
 org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
 at 
 org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
 at 
 org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
 at 
 org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
 at org.eclipse.jetty.server.Server.handle(Server.java:368)
 at 
 org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
 at 
 org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
 at 
 org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
 at 
 org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
 at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
 at 
 org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
 at 
 org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
 at 
 org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
 at 
 org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
 at 
 org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
 at java.lang.Thread.run(Thread.java:745)
 251184 [qtp1121454968-17] ERROR org.apache.solr.core.SolrCore  [   suggests] 
 -

[jira] [Updated] (LUCENE-6372) Simplify hashCode/equals for SpanQuery subclasses


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

Paul Elschot updated LUCENE-6372:
-
Attachment: LUCENE-6372.patch

Patch of 6 May 2015.
Compared to previous patch this changes hash code rotations to multiplicative 
hashes, and this includes an implementation for SpanPayloadCheckQuery.

 Simplify hashCode/equals for SpanQuery subclasses
 -

 Key: LUCENE-6372
 URL: https://issues.apache.org/jira/browse/LUCENE-6372
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Paul Elschot
 Attachments: LUCENE-6372.patch, LUCENE-6372.patch


 Spin off from LUCENE-6308, see the comments there from around 23 March 2015.



--
This message was sent by Atlassian 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-6350) switch TermsQuery to prefixcodedterms


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

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

Here is a new patch that iterates on Robert's and tries to address Mike's 
comments:
 - Updated to trunk and uses the new iterator from LUCENE-6315
 - PrefixCodedTerms is @lucene.internal
 - When building the scorer we use == instead of equals to compare fields 
(which is correct as per FieldTermIterator.field() javadocs)

 switch TermsQuery to prefixcodedterms
 -

 Key: LUCENE-6350
 URL: https://issues.apache.org/jira/browse/LUCENE-6350
 Project: Lucene - Core
  Issue Type: Task
Reporter: Robert Muir
 Attachments: LUCENE-6350.patch, LUCENE-6350.patch, LUCENE-6350.patch


 This will save ram and cleanup a lot of the code.
 Unfortunately the code is still a mess, it has a custom iterator api, and 
 prefixcodedterms has yet another custom iterator api (seriously, maybe the 
 worst one ever). 



--
This message was sent by Atlassian 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-6467) Simplify Query.equals()


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

Paul Elschot updated LUCENE-6467:
-
Attachment: LUCENE-6474.patch

 Simplify Query.equals()
 ---

 Key: LUCENE-6467
 URL: https://issues.apache.org/jira/browse/LUCENE-6467
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/search
Reporter: Paul Elschot
Priority: Minor
 Attachments: LUCENE-6474.patch


 Remove this == other test in Query.equals().



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

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

[jira] [Closed] (LUCENE-6250) Approximations on Spans


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

Paul Elschot closed LUCENE-6250.


 Approximations on Spans
 ---

 Key: LUCENE-6250
 URL: https://issues.apache.org/jira/browse/LUCENE-6250
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Paul Elschot
 Attachments: ApproxSpans-20150216a.patch


 Approximate spans using existing conjunction/disjunction approximations



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

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

[jira] [Closed] (LUCENE-6083) Span containing/contained queries


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

Paul Elschot closed LUCENE-6083.


 Span containing/contained queries
 -

 Key: LUCENE-6083
 URL: https://issues.apache.org/jira/browse/LUCENE-6083
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/search
Reporter: Paul Elschot
Priority: Minor
 Fix For: Trunk, 5.2

 Attachments: LUCENE-6083.patch, LUCENE-6083.patch, LUCENE-6083.patch, 
 LUCENE-6083.patch, LUCENE-6083.patch, LUCENE-6083.patch, LUCENE-6083.patch, 
 LUCENE-6083.patch


 SpanContainingQuery reducing a spans to where it is containing another spans.
 SpanContainedQuery reducing a spans to where it is contained in another spans.



--
This message was sent by Atlassian 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-6372) Simplify hashCode/equals for SpanQuery subclasses


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

Adrien Grand commented on LUCENE-6372:
--

{quote}
Query has a this == other test in equals().
{quote}

I'm not sure how much it helps and I wouldn't mind seeing it removed, but to 
answer your question I think it still kicks in for queries that do not need to 
override equals/hashcode like MatchAllDocsQuery?

 Simplify hashCode/equals for SpanQuery subclasses
 -

 Key: LUCENE-6372
 URL: https://issues.apache.org/jira/browse/LUCENE-6372
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Paul Elschot
 Attachments: LUCENE-6372.patch


 Spin off from LUCENE-6308, see the comments there from around 23 March 2015.



--
This message was sent by Atlassian 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-6372) Simplify hashCode/equals for SpanQuery subclasses


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

Adrien Grand commented on LUCENE-6372:
--

Indeed, I don't think these == checks are useful for anything but corner cases, 
especially given that query rewriting often involves cloning.

 Simplify hashCode/equals for SpanQuery subclasses
 -

 Key: LUCENE-6372
 URL: https://issues.apache.org/jira/browse/LUCENE-6372
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Paul Elschot
 Attachments: LUCENE-6372.patch, LUCENE-6372.patch


 Spin off from LUCENE-6308, see the comments there from around 23 March 2015.



--
This message was sent by Atlassian 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-6467) Simplify Query.equals()

Paul Elschot created LUCENE-6467:


 Summary: Simplify Query.equals()
 Key: LUCENE-6467
 URL: https://issues.apache.org/jira/browse/LUCENE-6467
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/search
Reporter: Paul Elschot
Priority: Minor


Remove this == other test in Query.equals().



--
This message was sent by Atlassian 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-6365) Optimized iteration of finite strings


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

Markus Heiden updated LUCENE-6365:
--
Attachment: FiniteStringsIterator2.patch

 Optimized iteration of finite strings
 -

 Key: LUCENE-6365
 URL: https://issues.apache.org/jira/browse/LUCENE-6365
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/other
Affects Versions: 5.0
Reporter: Markus Heiden
Priority: Minor
  Labels: patch, performance
 Attachments: FiniteStringsIterator.patch, FiniteStringsIterator2.patch


 Replaced Operations.getFiniteStrings() by an optimized FiniteStringIterator.
 Benefits:
 Avoid huge hash set of finite strings.
 Avoid massive object/array creation during processing.
 Downside:
 Iteration order changed, so when iterating with a limit, the result may 
 differ slightly. Old: emit current node, if accept / recurse. New: recurse / 
 emit current node, if accept.
 The old method Operations.getFiniteStrings() still exists, because it eases 
 the tests. It is now implemented by use of the new FiniteStringIterator.



--
This message was sent by Atlassian 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-6365) Optimized iteration of finite strings


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

Markus Heiden updated LUCENE-6365:
--
Attachment: (was: FiniteStringsIterator2.patch)

 Optimized iteration of finite strings
 -

 Key: LUCENE-6365
 URL: https://issues.apache.org/jira/browse/LUCENE-6365
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/other
Affects Versions: 5.0
Reporter: Markus Heiden
Priority: Minor
  Labels: patch, performance
 Attachments: FiniteStringsIterator.patch, FiniteStringsIterator2.patch


 Replaced Operations.getFiniteStrings() by an optimized FiniteStringIterator.
 Benefits:
 Avoid huge hash set of finite strings.
 Avoid massive object/array creation during processing.
 Downside:
 Iteration order changed, so when iterating with a limit, the result may 
 differ slightly. Old: emit current node, if accept / recurse. New: recurse / 
 emit current node, if accept.
 The old method Operations.getFiniteStrings() still exists, because it eases 
 the tests. It is now implemented by use of the new FiniteStringIterator.



--
This message was sent by Atlassian 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] (LUCENE-6365) Optimized iteration of finite strings

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

Markus Heiden edited comment on LUCENE-6365 at 5/6/15 1:49 PM:
---

Sorry for the delay.

I moved Operations.getFiniteStrings() to TestOperations.getFiniteStrings(),
because using the iterator for assertions is a pain. Production code using this
method has been replaced by direct usage of the new iterator.

I got one problem with that:
I am not sure if the implementation change of CompletionTokenStream is OK,
because I set the position attribute at the end of the iteration instead of at
the start of the iteration. The tests run fine, but someone should review that.

I marked the new iterator as @lucene.experimental and added a comment, that the
iteration order may change.

was (Author: markus_heiden):
Sorry for the delay.

I marked the new iterator as @lucene.experimental and added a comment, that the
iteration order may change.

Optimized iteration of finite strings
-

Key: LUCENE-6365
URL: https://issues.apache.org/jira/browse/LUCENE-6365
Project: Lucene - Core
Issue Type: Improvement
Components: core/other
Affects Versions: 5.0
Reporter: Markus Heiden
Priority: Minor
Labels: patch, performance
Attachments: FiniteStringsIterator.patch, FiniteStringsIterator2.patch

Replaced Operations.getFiniteStrings() by an optimized FiniteStringIterator.
Benefits:
Avoid huge hash set of finite strings.
Avoid massive object/array creation during processing.
Downside:
Iteration order changed, so when iterating with a limit, the result may
differ slightly. Old: emit current node, if accept / recurse. New: recurse /
emit current node, if accept.
The old method Operations.getFiniteStrings() still exists, because it eases
the tests. It is now implemented by use of the new FiniteStringIterator.

--
This message was sent by Atlassian 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] (LUCENE-6365) Optimized iteration of finite strings

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

Markus Heiden edited comment on LUCENE-6365 at 5/6/15 1:48 PM:
---

Sorry for the delay.

I marked the new iterator as @lucene.experimental and added a comment, that the
iteration order may change.

was (Author: markus_heiden):
Sorry for the delay.

I marked the new iterator as @lucene.experimental and added a comment, that the
iteration order may change.

Optimized iteration of finite strings
-

--
This message was sent by Atlassian 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] (LUCENE-6365) Optimized iteration of finite strings

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

Markus Heiden edited comment on LUCENE-6365 at 5/6/15 1:48 PM:
---

Sorry for the delay.

I marked the new iterator as @lucene.experimental and added a comment, that the
iteration order may change.

was (Author: markus_heiden):
Sorry for the delay.

I marked the new iterator as @lucene.experimental and added a comment, that the
iteration order may change.

Optimized iteration of finite strings
-

--
This message was sent by Atlassian 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-7341) xjoin - join data from external sources


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

Tom Winch updated SOLR-7341:

Description: 
h2. XJoin

The xjoin SOLR contrib allows external results to be joined with SOLR results 
in a query and the SOLR result set to be filtered by the results of an external 
query. Values from the external results are made available in the SOLR results 
and may also be used to boost the scores of corresponding documents during the 
search. The contrib consists of the Java classes XJoinSearchComponent, 
XJoinValueSourceParser and XJoinQParserPlugin (and associated classes), which 
must be configured in solrconfig.xml, and the interfaces XJoinResultsFactory 
and XJoinResults, which are implemented by the user to provide the link between 
SOLR and the external results source. External results and SOLR documents are 
matched via a single configurable attribute (the join field). The contrib JAR 
solr-xjoin-4.10.3.jar contains these classes and interfaces and should be 
included in SOLR's class path from solrconfig.xml, as should a JAR containing 
the user implementations of the previously mentioned interfaces. For example:

{code:xml}
config
  ..
  !-- XJoin contrib JAR file --
  lib dir=${solr.install.dir:../../..}/dist/ regex=solr-xjoin-\d.*\.jar /
  ..
  !-- user implementations of XJoin interfaces --
  lib path=/path/to/xjoin_test.jar /
  ..
/config
{code}

h2. Java classes and interfaces

h3. XJoinResultsFactory

The user implementation of this interface is responsible for connecting to an 
external source to perform a query (or otherwise collect results). Parameters 
with prefix component name.external. are passed from the SOLR query URL to 
pararameterise the search. The interface has the following methods:

* void init(NamedList args) - this is called during SOLR initialisation, and 
passed parameters from the search component configuration (see below)
* XJoinResults getResults(SolrParams params) - this is called during a SOLR 
search to generate external results, and is passed parameters from the SOLR 
query URL (as above)

For example, the implementation might perform queries of an external source 
based on the 'q' SOLR query URL parameter (in full, component 
name.external.q).

h3. XJoinResults
A user implementation of this interface is returned by the getResults() method 
of the XJoinResultsFactory implementation. It has methods:

* Object getResult(String joinId) - this should return a particular result 
given the value of the join attribute
* IterableString getJoinIds() - this should return the join attribute values 
for all results of the external search

h3. XJoinSearchComponent

This is the central Java class of the contrib. It is a SOLR search component, 
configured in solrconfig.xml and included in one or more SOLR request handlers. 
There is one XJoin search component per external source, and each has two main 
responsibilities:

* Before the SOLR search, it connects to the external source and retrieves 
results, storing them in the SOLR request context
* After the SOLR search, it matches SOLR document in the results set and 
external results via the join field, adding attributes from the external 
results to documents in the SOLR results set

It takes the following initialisation parameters:

* factoryClass - this specifies the user-supplied class implementing 
XJoinResultsFactory, used to generate external results
* joinField - this specifies the attribute on which to join between SOLR 
documents and external results
* external - this parameter set is passed to configure the XJoinResultsFactory 
implementation

For example, in solrconfig.xml:

{code:xml}
searchComponent name=xjoin_test 
class=org.apache.solr.search.xjoin.XJoinSearchComponent
  str name=factoryClasstest.TestXJoinResultsFactory/str
  str name=joinFieldid/str
  lst name=external
str name=values1,2,3/str
  /lst
/searchComponent
{code}

Here, the search component instantiates a new TextXJoinResultsFactory during 
initialisation, and passes it the values parameter (1, 2, 3) to configure it. 
To properly use the XJoinSearchComponent in a request handler, it must be 
included at the start and end of the component list, and may be configured with 
the following query parameters:

* results - a comma-separated list of attributes from the XJoinResults 
implementation (created by the factory at search time) to be included in the 
SOLR results
* fl - a comma-separated list of attributes from results objects (contained in 
an XJoinResults implementation) to be included in the SOLR results

For example:
{code:xml}
requestHandler name=/xjoin class=solr.SearchHandler startup=lazy
  lst name=defaults
..
bool name=xjoin_testtrue/bool
str name=xjoin_test.listParameterxx/str
str name=xjoin_test.resultstest_count/str
str name=xjoin_test.flid,value/str
  /lst
  arr name=first-components
strxjoin_test/str
  /arr
  arr

[jira] [Updated] (SOLR-7341) xjoin - join data from external sources

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


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

Tom Winch updated SOLR-7341:

Description: 
h2. XJoin

The xjoin SOLR contrib allows external results to be joined with SOLR results 
in a query and the SOLR result set to be filtered by the results of an external 
query. Values from the external results are made available in the SOLR results 
and may also be used to boost the scores of corresponding documents during the 
search. The contrib consists of the Java classes XJoinSearchComponent, 
XJoinValueSourceParser and XJoinQParserPlugin (and associated classes), which 
must be configured in solrconfig.xml, and the interfaces XJoinResultsFactory 
and XJoinResults, which are implemented by the user to provide the link between 
SOLR and the external results source. External results and SOLR documents are 
matched via a single configurable attribute (the join field). The contrib JAR 
solr-xjoin-4.10.3.jar contains these classes and interfaces and should be 
included in SOLR's class path from solrconfig.xml, as should a JAR containing 
the user implementations of the previously mentioned interfaces. For example:

{code:xml}
config
  ..
  !-- XJoin contrib JAR file --
  lib dir=${solr.install.dir:../../..}/dist/ regex=solr-xjoin-\d.*\.jar /
  ..
  !-- user implementations of XJoin interfaces --
  lib path=/path/to/xjoin_test.jar /
  ..
/config
{code}

h2. Java classes and interfaces

h3. XJoinResultsFactory

The user implementation of this interface is responsible for connecting to an 
external source to perform a query (or otherwise collect results). Parameters 
with prefix component name.external. are passed from the SOLR query URL to 
pararameterise the search. The interface has the following methods:

* void init(NamedList args) - this is called during SOLR initialisation, and 
passed parameters from the search component configuration (see below)
* XJoinResults getResults(SolrParams params) - this is called during a SOLR 
search to generate external results, and is passed parameters from the SOLR 
query URL (as above)

For example, the implementation might perform queries of an external source 
based on the 'q' SOLR query URL parameter (in full, component 
name.external.q).

h3. XJoinResults
A user implementation of this interface is returned by the getResults() method 
of the XJoinResultsFactory implementation. It has methods:

* Object getResult(String joinId) - this should return a particular result 
given the value of the join attribute
* IterableString getJoinIds() - this should return the join attribute values 
for all results of the external search

h3. XJoinSearchComponent

This is the central Java class of the contrib. It is a SOLR search component, 
configured in solrconfig.xml and included in one or more SOLR request handlers. 
There is one XJoin search component per external source, and each has two main 
responsibilities:

* Before the SOLR search, it connects to the external source and retrieves 
results, storing them in the SOLR request context
* After the SOLR search, it matches SOLR document in the results set and 
external results via the join field, adding attributes from the external 
results to documents in the SOLR results set

It takes the following initialisation parameters:

* factoryClass - this specifies the user-supplied class implementing 
XJoinResultsFactory, used to generate external results
* joinField - this specifies the attribute on which to join between SOLR 
documents and external results
* external - this parameter set is passed to configure the XJoinResultsFactory 
implementation

For example, in solrconfig.xml:

{code:xml}
searchComponent name=xjoin_test 
class=org.apache.solr.search.xjoin.XJoinSearchComponent
  str name=factoryClasstest.TestXJoinResultsFactory/str
  str name=joinFieldid/str
  lst name=external
str name=values1,2,3/str
  /lst
/searchComponent
{code}

Here, the search component instantiates a new TextXJoinResultsFactory during 
initialisation, and passes it the values parameter (1, 2, 3) to configure it. 
To properly use the XJoinSearchComponent in a request handler, it must be 
included at the start and end of the component list, and may be configured with 
the following query parameters:

* results - a comma-separated list of attributes from the XJoinResults 
implementation (created by the factory at search time) to be included in the 
SOLR results
* fl - a comma-separated list of attributes from results objects (contained in 
an XJoinResults implementation) to be included in the SOLR results

For example:
{code:xml}
requestHandler name=/xjoin class=solr.SearchHandler startup=lazy
  lst name=defaults
..
bool name=xjoin_testtrue/bool
str name=xjoin_test.listParameterxx/str
str name=xjoin_test.resultstest_count/str
str name=xjoin_test.flid,value/str
  /lst
  arr name=first-components
strxjoin_test/str
  /arr
  arr

[jira] [Commented] (LUCENE-6196) Include geo3d package, along with Lucene integration to make it useful


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

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

Commit 1678005 from [~dsmiley] in branch 'dev/trunk'
[ https://svn.apache.org/r1678005 ]

LUCENE-6196: Geo3d API, 3d planar geometry for surface of a sphere.
This merge commit renames a couple test utilities that appeared to be tests but 
weren't.

 Include geo3d package, along with Lucene integration to make it useful
 --

 Key: LUCENE-6196
 URL: https://issues.apache.org/jira/browse/LUCENE-6196
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/spatial
Reporter: Karl Wright
Assignee: David Smiley
 Attachments: LUCENE-6196-additions.patch, LUCENE-6196-fixes.patch, 
 LUCENE-6196_Geo3d.patch, ShapeImpl.java, geo3d-tests.zip, geo3d.zip


 I would like to explore contributing a geo3d package to Lucene.  This can be 
 used in conjunction with Lucene search, both for generating geohashes (via 
 spatial4j) for complex geographic shapes, as well as limiting results 
 resulting from those queries to those results within the exact shape in 
 highly performant ways.
 The package uses 3d planar geometry to do its magic, which basically limits 
 computation necessary to determine membership (once a shape has been 
 initialized, of course) to only multiplications and additions, which makes it 
 feasible to construct a performant BoostSource-based filter for geographic 
 shapes.  The math is somewhat more involved when generating geohashes, but is 
 still more than fast enough to do a good job.



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

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

[jira] [Closed] (SOLR-3428) SolrCmdDistributor flushAdds/flushDeletes problems

2015-05-06 Thread Per Steffensen (JIRA)


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

Per Steffensen closed SOLR-3428.

Resolution: Fixed

None of the problems are present in latest code (looking at 5.1.0 release)

 SolrCmdDistributor flushAdds/flushDeletes problems
 --

 Key: SOLR-3428
 URL: https://issues.apache.org/jira/browse/SOLR-3428
 Project: Solr
  Issue Type: Bug
  Components: replication (java), SolrCloud, update
Affects Versions: 4.0-ALPHA
Reporter: Per Steffensen
Assignee: Per Steffensen
  Labels: add, delete, replica, solrcloud, update
   Original Estimate: 24h
  Remaining Estimate: 24h

 A few problems with SolrCmdDistributor.flushAdds/flushDeletes
 * If number of AddRequests/DeleteRequests in alist/dlist is below limit for a 
 specific node the method returns immediately and doesnt flush for subsequent 
 nodes
 * When returning immediately because there is below limit requests for a 
 given node, then previous nodes that have already been flushed/submitted are 
 not removed from adds/deletes maps (causing them to be flushed/submitted 
 again the next time flushAdds/flushDeletes is executed)
 * The idea about just combining params does not work for SEEN_LEADER params 
 (and probably others as well). Since SEEN_LEADER cannot be expressed (unlike 
 commitWithin and overwrite) for individual operations in the request, you 
 need to sent two separate submits. One containing requests with 
 SEEN_LEADER=true and one with SEEN_LEADER=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] [Resolved] (LUCENE-6196) Include geo3d package, along with Lucene integration to make it useful

2015-05-06 Thread David Smiley (JIRA)


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

David Smiley resolved LUCENE-6196.
--
   Resolution: Fixed
Fix Version/s: 5.2

Committed.  Thanks again for your contribution Karl!  On the Spatial4j side 
I'll be adding some changes to get this in with more integration (e.g. tie-in 
to WKT parse  SpatialContext).  I'm not sure if it'll be the next release or 
the one after.

 Include geo3d package, along with Lucene integration to make it useful
 --

 Key: LUCENE-6196
 URL: https://issues.apache.org/jira/browse/LUCENE-6196
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/spatial
Reporter: Karl Wright
Assignee: David Smiley
 Fix For: 5.2

 Attachments: LUCENE-6196-additions.patch, LUCENE-6196-fixes.patch, 
 LUCENE-6196_Geo3d.patch, ShapeImpl.java, geo3d-tests.zip, geo3d.zip


 I would like to explore contributing a geo3d package to Lucene.  This can be 
 used in conjunction with Lucene search, both for generating geohashes (via 
 spatial4j) for complex geographic shapes, as well as limiting results 
 resulting from those queries to those results within the exact shape in 
 highly performant ways.
 The package uses 3d planar geometry to do its magic, which basically limits 
 computation necessary to determine membership (once a shape has been 
 initialized, of course) to only multiplications and additions, which makes it 
 feasible to construct a performant BoostSource-based filter for geographic 
 shapes.  The math is somewhat more involved when generating geohashes, but is 
 still more than fast enough to do a good job.



--
This message was sent by Atlassian 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-6196) Include geo3d package, along with Lucene integration to make it useful

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


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

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

Commit 1678007 from [~dsmiley] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1678007 ]

LUCENE-6196: Geo3d API, 3d planar geometry for surface of a sphere.
This merge commit renames a couple test utilities that appeared to be tests but 
weren't.

 Include geo3d package, along with Lucene integration to make it useful
 --

 Key: LUCENE-6196
 URL: https://issues.apache.org/jira/browse/LUCENE-6196
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/spatial
Reporter: Karl Wright
Assignee: David Smiley
 Attachments: LUCENE-6196-additions.patch, LUCENE-6196-fixes.patch, 
 LUCENE-6196_Geo3d.patch, ShapeImpl.java, geo3d-tests.zip, geo3d.zip


 I would like to explore contributing a geo3d package to Lucene.  This can be 
 used in conjunction with Lucene search, both for generating geohashes (via 
 spatial4j) for complex geographic shapes, as well as limiting results 
 resulting from those queries to those results within the exact shape in 
 highly performant ways.
 The package uses 3d planar geometry to do its magic, which basically limits 
 computation necessary to determine membership (once a shape has been 
 initialized, of course) to only multiplications and additions, which makes it 
 feasible to construct a performant BoostSource-based filter for geographic 
 shapes.  The math is somewhat more involved when generating geohashes, but is 
 still more than fast enough to do a good job.



--
This message was sent by Atlassian 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-6422) Add PackedQuadPrefixTree

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


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

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

Commit 1678008 from [~dsmiley] in branch 'dev/trunk'
[ https://svn.apache.org/r1678008 ]

Fix CHANGES.txt formatting for LUCENE-6422

 Add PackedQuadPrefixTree
 

 Key: LUCENE-6422
 URL: https://issues.apache.org/jira/browse/LUCENE-6422
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/spatial
Affects Versions: 5.x
Reporter: Nicholas Knize
Assignee: David Smiley
 Fix For: 5.2

 Attachments: LUCENE-6422-TRUNK.patch, LUCENE-6422.patch, 
 LUCENE-6422.patch, LUCENE-6422.patch, LUCENE-6422.patch, LUCENE-6422.patch, 
 LUCENE-6422_with_SPT_factory_and_benchmark.patch


 This task introduces a PackedQuadPrefixTree that includes two things:
 1.  A packed 8 byte representation for a QuadCell, including more efficient 
 implementations of the SPT API than the existing QuadPrefixTree or 
 GeoHashPrefixTree.
 2.  An alternative implementation to RPT's pruneLeafyBranches that streams 
 the cells without buffering them all, which is way more memory efficient.  
 However pruning is limited to the target detail level, where it accomplishes 
 the most good.
 Future improvements over this approach may include the generation of the 
 packed cells using an AutoPrefixAutomaton



--
This message was sent by Atlassian 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-6422) Add PackedQuadPrefixTree

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


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

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

Commit 1678009 from [~dsmiley] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1678009 ]

Fix CHANGES.txt formatting for LUCENE-6422

 Add PackedQuadPrefixTree
 

 Key: LUCENE-6422
 URL: https://issues.apache.org/jira/browse/LUCENE-6422
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/spatial
Affects Versions: 5.x
Reporter: Nicholas Knize
Assignee: David Smiley
 Fix For: 5.2

 Attachments: LUCENE-6422-TRUNK.patch, LUCENE-6422.patch, 
 LUCENE-6422.patch, LUCENE-6422.patch, LUCENE-6422.patch, LUCENE-6422.patch, 
 LUCENE-6422_with_SPT_factory_and_benchmark.patch


 This task introduces a PackedQuadPrefixTree that includes two things:
 1.  A packed 8 byte representation for a QuadCell, including more efficient 
 implementations of the SPT API than the existing QuadPrefixTree or 
 GeoHashPrefixTree.
 2.  An alternative implementation to RPT's pruneLeafyBranches that streams 
 the cells without buffering them all, which is way more memory efficient.  
 However pruning is limited to the target detail level, where it accomplishes 
 the most good.
 Future improvements over this approach may include the generation of the 
 packed cells using an AutoPrefixAutomaton



--
This message was sent by Atlassian 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 # 3071 - Failure

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

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

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

Error Message:
There were too many update fails (42  40) - we expect it can happen, but 
shouldn't easily

Stack Trace:
java.lang.AssertionError: There were too many update fails (42  40) - we 
expect it can happen, but shouldn't easily
at 
__randomizedtesting.SeedInfo.seed([873F2029AA5E5D6C:F6B1FF304A23094]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertFalse(Assert.java:68)
at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:230)
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:960)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
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

[jira] [Commented] (LUCENE-6372) Simplify hashCode/equals for SpanQuery subclasses


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

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

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

LUCENE-6372: Simplified and improved equals/hashcode of span queries.

 Simplify hashCode/equals for SpanQuery subclasses
 -

 Key: LUCENE-6372
 URL: https://issues.apache.org/jira/browse/LUCENE-6372
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Paul Elschot
 Attachments: LUCENE-6372.patch, LUCENE-6372.patch


 Spin off from LUCENE-6308, see the comments there from around 23 March 2015.



--
This message was sent by Atlassian 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] (LUCENE-6372) Simplify hashCode/equals for SpanQuery subclasses


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

Adrien Grand reassigned LUCENE-6372:


Assignee: Adrien Grand

 Simplify hashCode/equals for SpanQuery subclasses
 -

 Key: LUCENE-6372
 URL: https://issues.apache.org/jira/browse/LUCENE-6372
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Paul Elschot
Assignee: Adrien Grand
 Attachments: LUCENE-6372.patch, LUCENE-6372.patch


 Spin off from LUCENE-6308, see the comments there from around 23 March 2015.



--
This message was sent by Atlassian 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-6467) Simplify Query.equals()


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

Paul Elschot commented on LUCENE-6467:
--

See discussion at LUCENE-6372

 Simplify Query.equals()
 ---

 Key: LUCENE-6467
 URL: https://issues.apache.org/jira/browse/LUCENE-6467
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/search
Reporter: Paul Elschot
Priority: Minor
 Attachments: LUCENE-6474.patch


 Remove this == other test in Query.equals().



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

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

[jira] [Closed] (LUCENE-5416) Performance of a FixedBitSet variant that uses Long.numberOfTrailingZeros()


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

Paul Elschot closed LUCENE-5416.


 Performance of a FixedBitSet variant that uses Long.numberOfTrailingZeros()
 ---

 Key: LUCENE-5416
 URL: https://issues.apache.org/jira/browse/LUCENE-5416
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/search
Affects Versions: Trunk
Reporter: Paul Elschot
Priority: Minor
 Fix For: Trunk


 On my machine the current byte index used in OpenBitSetIterator is slower 
 than Long.numberOfTrailingZeros() for advance().
 The pull request contains the code for benchmarking this taken from an early 
 stage of DocBlocksIterator.
 In case the benchmark shows improvements on more machines, well, we know what 
 to do...



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

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

[jira] [Updated] (LUCENE-6365) Optimized iteration of finite strings

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

Markus Heiden updated LUCENE-6365:
--
Attachment: FiniteStringsIterator2.patch

Sorry for the delay.

I marked the new iterator as @lucene.experimental and added a comment, that the
iteration order may change.

Optimized iteration of finite strings
-

--
This message was sent by Atlassian 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-7341) xjoin - join data from external sources


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

Tom Winch commented on SOLR-7341:
-

Added updated patch with more support for multiple external sources 
(XJoinQParserPlugin)

 xjoin - join data from external sources
 ---

 Key: SOLR-7341
 URL: https://issues.apache.org/jira/browse/SOLR-7341
 Project: Solr
  Issue Type: New Feature
  Components: search
Affects Versions: 4.10.3
Reporter: Tom Winch
Priority: Minor
 Fix For: Trunk

 Attachments: SOLR-7341.patch, SOLR-7341.patch


 h2. XJoin
 The xjoin SOLR contrib allows external results to be joined with SOLR 
 results in a query and the SOLR result set to be filtered by the results of 
 an external query. Values from the external results are made available in the 
 SOLR results and may also be used to boost the scores of corresponding 
 documents during the search. The contrib consists of the Java classes 
 XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and 
 associated classes), which must be configured in solrconfig.xml, and the 
 interfaces XJoinResultsFactory and XJoinResults, which are implemented by the 
 user to provide the link between SOLR and the external results source. 
 External results and SOLR documents are matched via a single configurable 
 attribute (the join field). The contrib JAR solr-xjoin-4.10.3.jar contains 
 these classes and interfaces and should be included in SOLR's class path from 
 solrconfig.xml, as should a JAR containing the user implementations of the 
 previously mentioned interfaces. For example:
 {code:xml}
 config
   ..
   !-- XJoin contrib JAR file --
   lib dir=${solr.install.dir:../../..}/dist/ regex=solr-xjoin-\d.*\.jar 
 /
   ..
   !-- user implementations of XJoin interfaces --
   lib path=/path/to/xjoin_test.jar /
   ..
 /config
 {code}
 h2. Java classes and interfaces
 h3. XJoinResultsFactory
 The user implementation of this interface is responsible for connecting to an 
 external source to perform a query (or otherwise collect results). Parameters 
 with prefix component name.external. are passed from the SOLR query URL 
 to pararameterise the search. The interface has the following methods:
 * void init(NamedList args) - this is called during SOLR initialisation, and 
 passed parameters from the search component configuration (see below)
 * XJoinResults getResults(SolrParams params) - this is called during a SOLR 
 search to generate external results, and is passed parameters from the SOLR 
 query URL (as above)
 For example, the implementation might perform queries of an external source 
 based on the 'q' SOLR query URL parameter (in full, component 
 name.external.q).
 h3. XJoinResults
 A user implementation of this interface is returned by the getResults() 
 method of the XJoinResultsFactory implementation. It has methods:
 * Object getResult(String joinId) - this should return a particular result 
 given the value of the join attribute
 * IterableString getJoinIds() - this should return the join attribute 
 values for all results of the external search
 h3. XJoinSearchComponent
 This is the central Java class of the contrib. It is a SOLR search component, 
 configured in solrconfig.xml and included in one or more SOLR request 
 handlers. There is one XJoin search component per external source, and each 
 has two main responsibilities:
 * Before the SOLR search, it connects to the external source and retrieves 
 results, storing them in the SOLR request context
 * After the SOLR search, it matches SOLR document in the results set and 
 external results via the join field, adding attributes from the external 
 results to documents in the SOLR results set
 It takes the following initialisation parameters:
 * factoryClass - this specifies the user-supplied class implementing 
 XJoinResultsFactory, used to generate external results
 * joinField - this specifies the attribute on which to join between SOLR 
 documents and external results
 * external - this parameter set is passed to configure the 
 XJoinResultsFactory implementation
 For example, in solrconfig.xml:
 {code:xml}
 searchComponent name=xjoin_test 
 class=org.apache.solr.search.xjoin.XJoinSearchComponent
   str name=factoryClasstest.TestXJoinResultsFactory/str
   str name=joinFieldid/str
   lst name=external
 str name=values1,2,3/str
   /lst
 /searchComponent
 {code}
 Here, the search component instantiates a new TextXJoinResultsFactory during 
 initialisation, and passes it the values parameter (1, 2, 3) to configure 
 it. To properly use the XJoinSearchComponent in a request handler, it must be 
 included at the start and end of the component list, and may be configured 
 with the following query parameters:
 * results - a

[jira] [Commented] (SOLR-7433) Maven dependency on solr-core 5.1.0 brings in 4.10.3 artifacts

2015-05-06 Thread Steve Rowe (JIRA)


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

Steve Rowe commented on SOLR-7433:
--

I can't reproduce.  {{mvn -version}} says:

{noformat}
Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; 
2014-12-14T12:29:23-05:00)
Maven home: /usr/local/Cellar/maven/3.2.5/libexec
Java version: 1.7.0_71, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_71.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: mac os x, version: 10.10.3, arch: x86_64, family: mac
{noformat}

Here's what I did:

{noformat}
mvn archetype:generate -DinteractiveMode=false -DgroupId=org.example 
-DartifactId=myproject -Dpackage=org.example.myproject
cd myproject
perl -pi.bak -e 
's~(dependencies)~$1dependencygroupIdorg.apache.solr/groupIdartifactIdsolr-core/artifactIdversion5.1.0/versionscopetest/scope/dependency~'
 pom.xml
rm -rf ~/.m2/repository/org/apache/{lucene,solr}  # Remove all Lucene/Solr 
artifacts from local repo
mvn dependency:tree|grep 'Downloaded\|org\.apache\.\(lucene\|solr\)'
{noformat}

Here's the output:

{noformat}
Downloaded: 
https://repo.maven.apache.org/maven2/org/apache/solr/solr-core/5.1.0/solr-core-5.1.0.pom
 (12 KB at 20.9 KB/sec)
Downloaded: 
https://repo.maven.apache.org/maven2/org/apache/solr/solr-parent/5.1.0/solr-parent-5.1.0.pom
 (7 KB at 54.5 KB/sec)
Downloaded: 
https://repo.maven.apache.org/maven2/org/apache/lucene/lucene-solr-grandparent/5.1.0/lucene-solr-grandparent-5.1.0.pom
 (323 KB at 734.6 KB/sec)
Downloaded: 
https://repo.maven.apache.org/maven2/org/apache/lucene/lucene-analyzers-common/5.1.0/lucene-analyzers-common-5.1.0.pom
 (3 KB at 23.1 KB/sec)
Downloaded: 
https://repo.maven.apache.org/maven2/org/apache/lucene/lucene-parent/5.1.0/lucene-parent-5.1.0.pom
 (5 KB at 33.9 KB/sec)
Downloaded: 
https://repo.maven.apache.org/maven2/org/apache/lucene/lucene-analyzers-kuromoji/5.1.0/lucene-analyzers-kuromoji-5.1.0.pom
 (4 KB at 25.2 KB/sec)
Downloaded: 
https://repo.maven.apache.org/maven2/org/apache/lucene/lucene-analyzers-phonetic/5.1.0/lucene-analyzers-phonetic-5.1.0.pom
 (4 KB at 25.9 KB/sec)
Downloaded: 
https://repo.maven.apache.org/maven2/org/apache/lucene/lucene-backward-codecs/5.1.0/lucene-backward-codecs-5.1.0.pom
 (5 KB at 31.5 KB/sec)
Downloaded: 
https://repo.maven.apache.org/maven2/org/apache/lucene/lucene-codecs/5.1.0/lucene-codecs-5.1.0.pom
 (4 KB at 24.8 KB/sec)
Downloaded: 
https://repo.maven.apache.org/maven2/org/apache/lucene/lucene-core/5.1.0/lucene-core-5.1.0.pom
 (5 KB at 39.0 KB/sec)
Downloaded: 
https://repo.maven.apache.org/maven2/org/apache/lucene/lucene-expressions/5.1.0/lucene-expressions-5.1.0.pom
 (3 KB at 23.2 KB/sec)
Downloaded: 
https://repo.maven.apache.org/maven2/org/apache/lucene/lucene-grouping/5.1.0/lucene-grouping-5.1.0.pom
 (3 KB at 23.5 KB/sec)
Downloaded: 
https://repo.maven.apache.org/maven2/org/apache/lucene/lucene-highlighter/5.1.0/lucene-highlighter-5.1.0.pom
 (4 KB at 25.8 KB/sec)
Downloaded: 
https://repo.maven.apache.org/maven2/org/apache/lucene/lucene-join/5.1.0/lucene-join-5.1.0.pom
 (3 KB at 23.2 KB/sec)
Downloaded: 
https://repo.maven.apache.org/maven2/org/apache/lucene/lucene-memory/5.1.0/lucene-memory-5.1.0.pom
 (5 KB at 33.3 KB/sec)
Downloaded: 
https://repo.maven.apache.org/maven2/org/apache/lucene/lucene-misc/5.1.0/lucene-misc-5.1.0.pom
 (5 KB at 38.9 KB/sec)
Downloaded: 
https://repo.maven.apache.org/maven2/org/apache/lucene/lucene-queries/5.1.0/lucene-queries-5.1.0.pom
 (3 KB at 22.3 KB/sec)
Downloaded: 
https://repo.maven.apache.org/maven2/org/apache/lucene/lucene-queryparser/5.1.0/lucene-queryparser-5.1.0.pom
 (6 KB at 39.6 KB/sec)
Downloaded: 
https://repo.maven.apache.org/maven2/org/apache/lucene/lucene-spatial/5.1.0/lucene-spatial-5.1.0.pom
 (3 KB at 23.0 KB/sec)
Downloaded: 
https://repo.maven.apache.org/maven2/org/apache/lucene/lucene-suggest/5.1.0/lucene-suggest-5.1.0.pom
 (4 KB at 24.9 KB/sec)
Downloaded: 
https://repo.maven.apache.org/maven2/org/apache/solr/solr-solrj/5.1.0/solr-solrj-5.1.0.pom
 (6 KB at 41.5 KB/sec)
Downloaded: 
https://repo.maven.apache.org/maven2/org/apache/lucene/lucene-analyzers-phonetic/5.1.0/lucene-analyzers-phonetic-5.1.0.jar
 (26 KB at 77.9 KB/sec)
Downloaded: 
https://repo.maven.apache.org/maven2/org/apache/lucene/lucene-backward-codecs/5.1.0/lucene-backward-codecs-5.1.0.jar
 (361 KB at 558.2 KB/sec)
Downloaded: 
https://repo.maven.apache.org/maven2/org/apache/lucene/lucene-codecs/5.1.0/lucene-codecs-5.1.0.jar
 (410 KB at 336.8 KB/sec)
Downloaded: 
https://repo.maven.apache.org/maven2/org/apache/solr/solr-core/5.1.0/solr-core-5.1.0.jar
 (3244 KB at 2429.5 KB/sec)
Downloaded: 
https://repo.maven.apache.org/maven2/org/apache/lucene/lucene-expressions/5.1.0/lucene-expressions-5.1.0.jar
 (74 KB at 51.5 KB/sec)
Downloaded:

[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_60-ea-b12) - Build # 12577 - Failure!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/12577/
Java: 64bit/jdk1.8.0_60-ea-b12 -XX:+UseCompressedOops -XX:+UseParallelGC

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

Error Message:
ERROR: SolrIndexSearcher opens=33 closes=32

Stack Trace:
java.lang.AssertionError: ERROR: SolrIndexSearcher opens=33 closes=32
at __randomizedtesting.SeedInfo.seed([ED410880EDD8F73B]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:496)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:232)
at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)
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$5.evaluate(RandomizedRunner.java:799)
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 java.lang.Thread.run(Thread.java:745)


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

Error Message:
2 threads leaked from SUITE scope at 
org.apache.solr.cloud.BasicDistributedZk2Test: 1) Thread[id=5951, 
name=qtp1977379185-5951, state=RUNNABLE, group=TGRP-BasicDistributedZk2Test]
 at java.util.WeakHashMap.get(WeakHashMap.java:403) at 
org.apache.solr.servlet.cache.HttpCacheHeaderUtil.calcEtag(HttpCacheHeaderUtil.java:101)
 at 
org.apache.solr.servlet.cache.HttpCacheHeaderUtil.doCacheHeaderValidation(HttpCacheHeaderUtil.java:219)
 at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:370)
 at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:176)
 at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:169)
 at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
 at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:105)
 at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
 at 
org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)
 at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364) 
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
 at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)  
   at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221)
 at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
 at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)   
  at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
 at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
 at

[jira] [Created] (LUCENE-6469) Make SortingLeafReader sort postings lists more efficiently

Adrien Grand created LUCENE-6469:


 Summary: Make SortingLeafReader sort postings lists more 
efficiently
 Key: LUCENE-6469
 URL: https://issues.apache.org/jira/browse/LUCENE-6469
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor


We could use a bit set to sort postings lists (similarly to BS1) instead of 
loading the postings list to an int[] and then sorting them using TimSort. I'm 
not totally clear whether it would be faster or slower but at least it would 
have a better worst-case memory usage.

See 
http://search-lucene.com/m/l6pAi1e8sh52n8Uts/sortingatomicreadersubj=Re+SortingAtomicReader+alternate+to+Tim+Sort+
 for more information



--
This message was sent by Atlassian 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-Linux (32bit/jdk1.9.0-ea-b60) - Build # 12575 - Failure!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/12575/
Java: 32bit/jdk1.9.0-ea-b60 -server -XX:+UseG1GC

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

Error Message:
There were too many update fails (44  40) - we expect it can happen, but 
shouldn't easily

Stack Trace:
java.lang.AssertionError: There were too many update fails (44  40) - we 
expect it can happen, but shouldn't easily
at 
__randomizedtesting.SeedInfo.seed([29349A1CDF7D7CD5:A160A5C67181112D]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertFalse(Assert.java:68)
at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:230)
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:502)
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:960)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
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)

[jira] [Updated] (LUCENE-6463) Share more logic between our approximated queries

2015-05-06 Thread David Smiley (JIRA)


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

David Smiley updated LUCENE-6463:
-
Attachment: LUCENE-6463.patch

The patch looks good Adrien (+1).  The patch I'm uploading augments yours with 
a use of ConstantScorScorer in TermsQuery.  No other changes.

I’ve seen at least a few cases where we start from a DocIdSet and then check 
for null, then grab the DISI from it then check for null, and then finally 
return the constant scorer.  Perhaps a static method could be added like 
from(weight, score, DocIdSet)?  I'm not sure if it's worth the method but I 
thought I'd bring it up.


 Share more logic between our approximated queries
 -

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


 We have several queries that support approximations, and in particular the 
 ones based on random-access (doc values terms/range, FieldValueFilter, ...) 
 duplicate some logic.



--
This message was sent by Atlassian 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-7341) xjoin - join data from external sources

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


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

Tom Winch updated SOLR-7341:

Attachment: SOLR-7341.patch

 xjoin - join data from external sources
 ---

 Key: SOLR-7341
 URL: https://issues.apache.org/jira/browse/SOLR-7341
 Project: Solr
  Issue Type: New Feature
  Components: search
Affects Versions: 4.10.3
Reporter: Tom Winch
Priority: Minor
 Fix For: Trunk

 Attachments: SOLR-7341.patch, SOLR-7341.patch


 h2. XJoin
 The xjoin SOLR contrib allows external results to be joined with SOLR 
 results in a query and the SOLR result set to be filtered by the results of 
 an external query. Values from the external results are made available in the 
 SOLR results and may also be used to boost the scores of corresponding 
 documents during the search. The contrib consists of the Java classes 
 XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and 
 associated classes), which must be configured in solrconfig.xml, and the 
 interfaces XJoinResultsFactory and XJoinResults, which are implemented by the 
 user to provide the link between SOLR and the external results source. 
 External results and SOLR documents are matched via a single configurable 
 attribute (the join field). The contrib JAR solr-xjoin-4.10.3.jar contains 
 these classes and interfaces and should be included in SOLR's class path from 
 solrconfig.xml, as should a JAR containing the user implementations of the 
 previously mentioned interfaces. For example:
 {code:xml}
 config
   ..
   !-- XJoin contrib JAR file --
   lib dir=${solr.install.dir:../../..}/dist/ regex=solr-xjoin-\d.*\.jar 
 /
   ..
   !-- user implementations of XJoin interfaces --
   lib path=/path/to/xjoin_test.jar /
   ..
 /config
 {code}
 h2. Java classes and interfaces
 h3. XJoinResultsFactory
 The user implementation of this interface is responsible for connecting to an 
 external source to perform a query (or otherwise collect results). Parameters 
 with prefix component name.external. are passed from the SOLR query URL 
 to pararameterise the search. The interface has the following methods:
 * void init(NamedList args) - this is called during SOLR initialisation, and 
 passed parameters from the search component configuration (see below)
 * XJoinResults getResults(SolrParams params) - this is called during a SOLR 
 search to generate external results, and is passed parameters from the SOLR 
 query URL (as above)
 For example, the implementation might perform queries of an external source 
 based on the 'q' SOLR query URL parameter (in full, component 
 name.external.q).
 h3. XJoinResults
 A user implementation of this interface is returned by the getResults() 
 method of the XJoinResultsFactory implementation. It has methods:
 * Object getResult(String joinId) - this should return a particular result 
 given the value of the join attribute
 * IterableString getJoinIds() - this should return the join attribute 
 values for all results of the external search
 h3. XJoinSearchComponent
 This is the central Java class of the contrib. It is a SOLR search component, 
 configured in solrconfig.xml and included in one or more SOLR request 
 handlers. There is one XJoin search component per external source, and each 
 has two main responsibilities:
 * Before the SOLR search, it connects to the external source and retrieves 
 results, storing them in the SOLR request context
 * After the SOLR search, it matches SOLR document in the results set and 
 external results via the join field, adding attributes from the external 
 results to documents in the SOLR results set
 It takes the following initialisation parameters:
 * factoryClass - this specifies the user-supplied class implementing 
 XJoinResultsFactory, used to generate external results
 * joinField - this specifies the attribute on which to join between SOLR 
 documents and external results
 * external - this parameter set is passed to configure the 
 XJoinResultsFactory implementation
 For example, in solrconfig.xml:
 {code:xml}
 searchComponent name=xjoin_test 
 class=org.apache.solr.search.xjoin.XJoinSearchComponent
   str name=factoryClasstest.TestXJoinResultsFactory/str
   str name=joinFieldid/str
   lst name=external
 str name=values1,2,3/str
   /lst
 /searchComponent
 {code}
 Here, the search component instantiates a new TextXJoinResultsFactory during 
 initialisation, and passes it the values parameter (1, 2, 3) to configure 
 it. To properly use the XJoinSearchComponent in a request handler, it must be 
 included at the start and end of the component list, and may be configured 
 with the following query parameters:
 * results - a comma-separated list of attributes from the XJoinResults 
 implementation (created by the factory at search time) to

[jira] [Commented] (SOLR-7500) Remove pathPrefix from SolrDispatchFilter as Solr no longer runs as a part of a bigger webapp


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

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

Commit 1678090 from [~anshumg] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1678090 ]

SOLR-7500: Remove pathPrefix from SolrDispatchFilter as Solr no longer runs as 
a part of a bigger webapp.(merge from trunk)

 Remove pathPrefix from SolrDispatchFilter as Solr no longer runs as a part of 
 a bigger webapp
 -

 Key: SOLR-7500
 URL: https://issues.apache.org/jira/browse/SOLR-7500
 Project: Solr
  Issue Type: Improvement
Reporter: Anshum Gupta
Assignee: Anshum Gupta
Priority: Minor
 Attachments: SOLR-7500.patch


 SolrDispatchFilter has support for Solr running as part of a bigger webapp 
 but as we've moved away from that concept, it makes sense to clean up the 
 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-7500) Remove pathPrefix from SolrDispatchFilter as Solr no longer runs as a part of a bigger webapp

2015-05-06 Thread Anshum Gupta (JIRA)


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

Anshum Gupta updated SOLR-7500:
---
Fix Version/s: 5.2

 Remove pathPrefix from SolrDispatchFilter as Solr no longer runs as a part of 
 a bigger webapp
 -

 Key: SOLR-7500
 URL: https://issues.apache.org/jira/browse/SOLR-7500
 Project: Solr
  Issue Type: Improvement
Reporter: Anshum Gupta
Assignee: Anshum Gupta
Priority: Minor
 Fix For: 5.2

 Attachments: SOLR-7500.patch


 SolrDispatchFilter has support for Solr running as part of a bigger webapp 
 but as we've moved away from that concept, it makes sense to clean up the 
 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-6350) switch TermsQuery to prefixcodedterms

2015-05-06 Thread Michael McCandless (JIRA)


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

Michael McCandless commented on LUCENE-6350:


+1, thanks [~jpountz]!

 switch TermsQuery to prefixcodedterms
 -

 Key: LUCENE-6350
 URL: https://issues.apache.org/jira/browse/LUCENE-6350
 Project: Lucene - Core
  Issue Type: Task
Reporter: Robert Muir
 Attachments: LUCENE-6350.patch, LUCENE-6350.patch, LUCENE-6350.patch


 This will save ram and cleanup a lot of the code.
 Unfortunately the code is still a mess, it has a custom iterator api, and 
 prefixcodedterms has yet another custom iterator api (seriously, maybe the 
 worst one ever). 



--
This message was sent by Atlassian 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-6463) Share more logic between our approximated queries


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

Adrien Grand commented on LUCENE-6463:
--

bq. I’ve seen at least a few cases where we start from a DocIdSet and then 
check for null, then grab the DISI from it then check for null, and then 
finally return the constant scorer.

I agree this is horrible to deal with LUCENE-5117 (but complicated to fix). 
Hopefully moving to filters is going to make it less of an issue as we will not 
have to deal as much with DocIdSet as we had in the past.

Thanks for fixing TermsQuery too, it looks good! I'll commit the patch tomorrow 
if nobody has objections.

 Share more logic between our approximated queries
 -

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


 We have several queries that support approximations, and in particular the 
 ones based on random-access (doc values terms/range, FieldValueFilter, ...) 
 duplicate some logic.



--
This message was sent by Atlassian 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 # 3073 - Still Failing

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

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

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

Error Message:
Captured an uncaught exception in thread: Thread[id=3730, name=Thread-962, 
state=RUNNABLE, group=TGRP-TestCloudManagedSchemaConcurrent]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=3730, name=Thread-962, state=RUNNABLE, 
group=TGRP-TestCloudManagedSchemaConcurrent]
Caused by: java.lang.AssertionError: QUERY FAILED: 
xpath=/response/lst[@name='responseHeader']/int[@name='status'][.='0']  
request=/schema/fieldtypes/newfieldtypePutThread3?wt=xml  response=?xml 
version=1.0 encoding=UTF-8?
response

lst name=responseHeader
  int name=status500/int
  int name=QTime99/int
/lst
lst name=error
  str name=msgjava.io.IOException: Error opening 
/configs/conf1/protwords.txt/str
  str name=traceorg.apache.solr.common.SolrException: java.io.IOException: 
Error opening /configs/conf1/protwords.txt
at 
org.apache.solr.schema.ManagedIndexSchema.informResourceLoaderAwareObjectsInChain(ManagedIndexSchema.java:1298)
at 
org.apache.solr.schema.ManagedIndexSchema.informResourceLoaderAwareObjectsForFieldType(ManagedIndexSchema.java:1146)
at 
org.apache.solr.schema.ManagedIndexSchema.postReadInform(ManagedIndexSchema.java:1131)
at 
org.apache.solr.schema.ManagedIndexSchema.addFieldTypes(ManagedIndexSchema.java:935)
at 
org.apache.solr.rest.schema.BaseFieldTypeResource.addNewFieldTypes(BaseFieldTypeResource.java:73)
at 
org.apache.solr.rest.schema.FieldTypeResource.addOrUpdateFieldType(FieldTypeResource.java:167)
at 
org.apache.solr.rest.schema.FieldTypeResource.put(FieldTypeResource.java:154)
at org.restlet.resource.ServerResource.doHandle(ServerResource.java:447)
at 
org.restlet.resource.ServerResource.doConditionalHandle(ServerResource.java:359)
at org.restlet.resource.ServerResource.handle(ServerResource.java:1044)
at org.restlet.resource.Finder.handle(Finder.java:236)
at org.restlet.routing.Filter.doHandle(Filter.java:150)
at org.restlet.routing.Filter.handle(Filter.java:197)
at org.restlet.routing.Router.doHandle(Router.java:422)
at org.restlet.routing.Router.handle(Router.java:639)
at org.restlet.routing.Filter.doHandle(Filter.java:150)
at org.restlet.routing.Filter.handle(Filter.java:197)
at org.restlet.routing.Filter.doHandle(Filter.java:150)
at org.restlet.routing.Filter.handle(Filter.java:197)
at org.restlet.routing.Filter.doHandle(Filter.java:150)
at 
org.restlet.engine.application.StatusFilter.doHandle(StatusFilter.java:140)
at org.restlet.routing.Filter.handle(Filter.java:197)
at org.restlet.routing.Filter.doHandle(Filter.java:150)
at org.restlet.routing.Filter.handle(Filter.java:197)
at org.restlet.engine.CompositeHelper.handle(CompositeHelper.java:202)
at 
org.restlet.engine.application.ApplicationHelper.handle(ApplicationHelper.java:75)
at org.restlet.Application.handle(Application.java:385)
at org.restlet.routing.Filter.doHandle(Filter.java:150)
at org.restlet.routing.Filter.handle(Filter.java:197)
at org.restlet.routing.Router.doHandle(Router.java:422)
at org.restlet.routing.Router.handle(Router.java:639)
at org.restlet.routing.Filter.doHandle(Filter.java:150)
at org.restlet.routing.Filter.handle(Filter.java:197)
at org.restlet.routing.Router.doHandle(Router.java:422)
at org.restlet.routing.Router.handle(Router.java:639)
at org.restlet.routing.Filter.doHandle(Filter.java:150)
at org.restlet.routing.Filter.handle(Filter.java:197)
at org.restlet.engine.CompositeHelper.handle(CompositeHelper.java:202)
at org.restlet.Component.handle(Component.java:408)
at org.restlet.Server.handle(Server.java:507)
at 
org.restlet.engine.connector.ServerHelper.handle(ServerHelper.java:63)
at 
org.restlet.engine.adapter.HttpServerHelper.handle(HttpServerHelper.java:143)
at 
org.restlet.ext.servlet.ServerServlet.service(ServerServlet.java:1117)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at 
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:808)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)

[jira] [Commented] (LUCENE-6196) Include geo3d package, along with Lucene integration to make it useful


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

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

Commit 1678059 from [~dsmiley] in branch 'dev/trunk'
[ https://svn.apache.org/r1678059 ]

LUCENE-6196: Fix RandomizedShapeTestCase.randomPointIn(Shape)

 Include geo3d package, along with Lucene integration to make it useful
 --

 Key: LUCENE-6196
 URL: https://issues.apache.org/jira/browse/LUCENE-6196
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/spatial
Reporter: Karl Wright
Assignee: David Smiley
 Fix For: 5.2

 Attachments: LUCENE-6196-additions.patch, LUCENE-6196-fixes.patch, 
 LUCENE-6196_Geo3d.patch, ShapeImpl.java, geo3d-tests.zip, geo3d.zip


 I would like to explore contributing a geo3d package to Lucene.  This can be 
 used in conjunction with Lucene search, both for generating geohashes (via 
 spatial4j) for complex geographic shapes, as well as limiting results 
 resulting from those queries to those results within the exact shape in 
 highly performant ways.
 The package uses 3d planar geometry to do its magic, which basically limits 
 computation necessary to determine membership (once a shape has been 
 initialized, of course) to only multiplications and additions, which makes it 
 feasible to construct a performant BoostSource-based filter for geographic 
 shapes.  The math is somewhat more involved when generating geohashes, but is 
 still more than fast enough to do a good job.



--
This message was sent by Atlassian 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-7484) Refactor SolrDispatchFilter to move all Solr specific implementation to another class

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


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

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

Commit 1678073 from [~anshumg] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1678073 ]

SOLR-7484: Cleaning up redundant switch cases from the code (merge from trunk)

 Refactor SolrDispatchFilter to move all Solr specific implementation to 
 another class
 -

 Key: SOLR-7484
 URL: https://issues.apache.org/jira/browse/SOLR-7484
 Project: Solr
  Issue Type: Improvement
Reporter: Anshum Gupta
Assignee: Anshum Gupta
 Fix For: 5.2

 Attachments: SOLR-7484.patch, SOLR-7484.patch, SOLR-7484.patch, 
 SOLR-7484.patch, SOLR-7484.patch, SOLR-7484.patch, SOLR-7484.patch, 
 SOLR-7484.patch, SOLR-7484.patch


 Currently almost everything that's done in SDF.doFilter() is sequential. We 
 should refactor it to clean up the code and make things easier to manage.



--
This message was sent by Atlassian 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 # 3072 - Still Failing

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

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

Error Message:
shard1 is not consistent.  Got 256 from 
http://127.0.0.1:15248/collection1lastClient and got 246 from 
http://127.0.0.1:15258/collection1

Stack Trace:
java.lang.AssertionError: shard1 is not consistent.  Got 256 from 
http://127.0.0.1:15248/collection1lastClient and got 246 from 
http://127.0.0.1:15258/collection1
at 
__randomizedtesting.SeedInfo.seed([7D593A25BD730DE9:F50D05FF138F6011]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1293)
at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:240)
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:960)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
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

[jira] [Commented] (SOLR-7484) Refactor SolrDispatchFilter to move all Solr specific implementation to another class

2015-05-06 Thread Anshum Gupta (JIRA)


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

Anshum Gupta commented on SOLR-7484:


Sure, I'll commit that patch. Thanks.

 Refactor SolrDispatchFilter to move all Solr specific implementation to 
 another class
 -

 Key: SOLR-7484
 URL: https://issues.apache.org/jira/browse/SOLR-7484
 Project: Solr
  Issue Type: Improvement
Reporter: Anshum Gupta
Assignee: Anshum Gupta
 Fix For: 5.2

 Attachments: SOLR-7484.patch, SOLR-7484.patch, SOLR-7484.patch, 
 SOLR-7484.patch, SOLR-7484.patch, SOLR-7484.patch, SOLR-7484.patch, 
 SOLR-7484.patch, SOLR-7484.patch


 Currently almost everything that's done in SDF.doFilter() is sequential. We 
 should refactor it to clean up the code and make things easier to manage.



--
This message was sent by Atlassian 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-MacOSX (64bit/jdk1.8.0) - Build # 2225 - Failure!

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

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/2225/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

2 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPIAsyncDistributedZkTest.testSolrJAPICalls

Error Message:
Shard split did not complete. Last recorded state: running 
expected:[completed] but was:[running]

Stack Trace:
org.junit.ComparisonFailure: Shard split did not complete. Last recorded state: 
running expected:[completed] but was:[running]
at 
__randomizedtesting.SeedInfo.seed([A2E796DC560CA659:FA831ABD50660E8D]:0)
at org.junit.Assert.assertEquals(Assert.java:125)
at 
org.apache.solr.cloud.CollectionsAPIAsyncDistributedZkTest.testSolrJAPICalls(CollectionsAPIAsyncDistributedZkTest.java:101)
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:960)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
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

[jira] [Updated] (SOLR-7377) SOLR Streaming Expressions

2015-05-06 Thread Joel Bernstein (JIRA)


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

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

New patch with precommit passing.

 SOLR Streaming Expressions
 --

 Key: SOLR-7377
 URL: https://issues.apache.org/jira/browse/SOLR-7377
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Reporter: Dennis Gove
Priority: Minor
 Fix For: Trunk

 Attachments: SOLR-7377.patch, SOLR-7377.patch, SOLR-7377.patch, 
 SOLR-7377.patch, SOLR-7377.patch, SOLR-7377.patch, SOLR-7377.patch, 
 SOLR-7377.patch, SOLR-7377.patch, SOLR-7377.patch


 It would be beneficial to add an expression-based interface to Streaming API 
 described in SOLR-7082. Right now that API requires streaming requests to 
 come in from clients as serialized bytecode of the streaming classes. The 
 suggestion here is to support string expressions which describe the streaming 
 operations the client wishes to perform. 
 {code:java}
 search(collection1, q=*:*, fl=id,fieldA,fieldB, sort=fieldA asc)
 {code}
 With this syntax in mind, one can now express arbitrarily complex stream 
 queries with a single string.
 {code:java}
 // merge two distinct searches together on common fields
 merge(
   search(collection1, q=id:(0 3 4), fl=id,a_s,a_i,a_f, sort=a_f asc, a_s 
 asc),
   search(collection2, q=id:(1 2), fl=id,a_s,a_i,a_f, sort=a_f asc, a_s 
 asc),
   on=a_f asc, a_s asc)
 // find top 20 unique records of a search
 top(
   n=20,
   unique(
 search(collection1, q=*:*, fl=id,a_s,a_i,a_f, sort=a_f desc),
 over=a_f desc),
   sort=a_f desc)
 {code}
 The syntax would support
 1. Configurable expression names (eg. via solrconfig.xml one can map unique 
 to a class implementing a Unique stream class) This allows users to build 
 their own streams and use as they wish.
 2. Named parameters (of both simple and expression types)
 3. Unnamed, type-matched parameters (to support requiring N streams as 
 arguments to another stream)
 4. Positional parameters
 The main goal here is to make streaming as accessible as possible and define 
 a syntax for running complex queries across large distributed systems.



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

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

Re: [JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2270 - Failure!

2015-05-06 Thread david.w.smi...@gmail.com

This turned out to be a bug in the test infrastructure that Geo3d uses,
copied from Spatial4j: Permalink
https://issues.apache.org/jira/browse/LUCENE-6196?focusedCommentId=14531165page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14531165
  I’m fixing.

On Wed, May 6, 2015 at 1:06 PM Policeman Jenkins Server jenk...@thetaphi.de
wrote:

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

 1 tests failed.
 FAILED:
 org.apache.lucene.spatial.spatial4j.Geo3dShapeRectRelationTest.testGeoBBoxRect

 Error Message:
 Rect(minX=-48.0,maxX=4.0,minY=-90.0,maxY=-74.0) intersect
 Pt(x=36.3684088252,y=-89.97395823916177)

 Stack Trace:
 java.lang.AssertionError: Rect(minX=-48.0,maxX=4.0,minY=-90.0,maxY=-74.0)
 intersect Pt(x=36.3684088252,y=-89.97395823916177)
 at
 __randomizedtesting.SeedInfo.seed([EE73D5405F7BB152:CAD67D787B48CF0C]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at org.junit.Assert.assertTrue(Assert.java:43)
 at
 org.apache.lucene.spatial.spatial4j.RandomizedShapeTestCase._assertIntersect(RandomizedShapeTestCase.java:168)
 at
 org.apache.lucene.spatial.spatial4j.RandomizedShapeTestCase.assertRelation(RandomizedShapeTestCase.java:153)
 at
 org.apache.lucene.spatial.spatial4j.RectIntersectionTestHelper.testRelateWithRectangle(RectIntersectionTestHelper.java:136)
 at
 org.apache.lucene.spatial.spatial4j.Geo3dShapeRectRelationTest.testGeoBBoxRect(Geo3dShapeRectRelationTest.java:166)
 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.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 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.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl$2.evaluate(ThreadLeakControl.java:401)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:651)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner.access$200(RandomizedRunner.java:138)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$1.run(RandomizedRunner.java:568)




 Build Log:
 [...truncated 8159 lines...]
[junit4] Suite:
 org.apache.lucene.spatial.spatial4j.Geo3dShapeRectRelationTest
[junit4]   1 S-R Rel: {}, Shape {}, Rectangle {} [WITHIN,
 Geo3dShape{GeoRectangle: {toplat=-1.5168556919397584(-86.90942927854432),
 bottomlat=-1.5706704561465907(-89.9927881430875),
 leftlon=-0.018526106616054788(-1.0614677199093308),
 rightlon=0.06206550121582512(3.5560912730308587)}},
 Rect(minX=-48.0,maxX=4.0,minY=-90.0,maxY=-74.0)](no slf4j subst; sorry)
[junit4] FAILURE 3.57s J1 | Geo3dShapeRectRelationTest.testGeoBBoxRect
 
[junit4] Throwable #1: java.lang.AssertionError:
 Rect(minX=-48.0,maxX=4.0,minY=-90.0,maxY=-74.0) intersect
 Pt(x=36.3684088252,y=-89.97395823916177)
[junit4]at
 __randomizedtesting.SeedInfo.seed([EE73D5405F7BB152:CAD67D787B48CF0C]:0)
[junit4]at
 org.apache.lucene.spatial.spatial4j.RandomizedShapeTestCase._assertIntersect(RandomizedShapeTestCase.java:168)
[junit4]at
 org.apache.lucene.spatial.spatial4j.RandomizedShapeTestCase.assertRelation(RandomizedShapeTestCase.java:153)
[junit4]at

[jira] [Commented] (LUCENE-6196) Include geo3d package, along with Lucene integration to make it useful

2015-05-06 Thread David Smiley (JIRA)


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

David Smiley commented on LUCENE-6196:
--

Regarding the test failure earlier today: 
http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2270/  this is a bug in 
RandomizedShapeTestCase, not Geo3d.  (RSTC in turn was copied from Spatial4j 
and is here temporarily while Geo3d is).  The randomPointIn method should be 
testing if the random point is in the shape, not the bbox.  But I'm concerned 
especially skinny shapes may loop forever... so I think I should address this 
somehow, like returning null so that the caller can give up.  I'll do that.

 Include geo3d package, along with Lucene integration to make it useful
 --

 Key: LUCENE-6196
 URL: https://issues.apache.org/jira/browse/LUCENE-6196
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/spatial
Reporter: Karl Wright
Assignee: David Smiley
 Fix For: 5.2

 Attachments: LUCENE-6196-additions.patch, LUCENE-6196-fixes.patch, 
 LUCENE-6196_Geo3d.patch, ShapeImpl.java, geo3d-tests.zip, geo3d.zip


 I would like to explore contributing a geo3d package to Lucene.  This can be 
 used in conjunction with Lucene search, both for generating geohashes (via 
 spatial4j) for complex geographic shapes, as well as limiting results 
 resulting from those queries to those results within the exact shape in 
 highly performant ways.
 The package uses 3d planar geometry to do its magic, which basically limits 
 computation necessary to determine membership (once a shape has been 
 initialized, of course) to only multiplications and additions, which makes it 
 feasible to construct a performant BoostSource-based filter for geographic 
 shapes.  The math is somewhat more involved when generating geohashes, but is 
 still more than fast enough to do a good job.



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

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

Re: [JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2270 - Failure!

2015-05-06 Thread Karl Wright

Ok, let me know if there still seems to be a problem after that.
Karl

On Wed, May 6, 2015 at 2:43 PM, david.w.smi...@gmail.com 
david.w.smi...@gmail.com wrote:

 This turned out to be a bug in the test infrastructure that Geo3d uses,
 copied from Spatial4j: Permalink
 https://issues.apache.org/jira/browse/LUCENE-6196?focusedCommentId=14531165page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14531165
   I’m fixing.

 On Wed, May 6, 2015 at 1:06 PM Policeman Jenkins Server 
 jenk...@thetaphi.de wrote:

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

 1 tests failed.
 FAILED:
 org.apache.lucene.spatial.spatial4j.Geo3dShapeRectRelationTest.testGeoBBoxRect

 Error Message:
 Rect(minX=-48.0,maxX=4.0,minY=-90.0,maxY=-74.0) intersect
 Pt(x=36.3684088252,y=-89.97395823916177)

 Stack Trace:
 java.lang.AssertionError: Rect(minX=-48.0,maxX=4.0,minY=-90.0,maxY=-74.0)
 intersect Pt(x=36.3684088252,y=-89.97395823916177)
 at
 __randomizedtesting.SeedInfo.seed([EE73D5405F7BB152:CAD67D787B48CF0C]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at org.junit.Assert.assertTrue(Assert.java:43)
 at
 org.apache.lucene.spatial.spatial4j.RandomizedShapeTestCase._assertIntersect(RandomizedShapeTestCase.java:168)
 at
 org.apache.lucene.spatial.spatial4j.RandomizedShapeTestCase.assertRelation(RandomizedShapeTestCase.java:153)
 at
 org.apache.lucene.spatial.spatial4j.RectIntersectionTestHelper.testRelateWithRectangle(RectIntersectionTestHelper.java:136)
 at
 org.apache.lucene.spatial.spatial4j.Geo3dShapeRectRelationTest.testGeoBBoxRect(Geo3dShapeRectRelationTest.java:166)
 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.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 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.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl$2.evaluate(ThreadLeakControl.java:401)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:651)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner.access$200(RandomizedRunner.java:138)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$1.run(RandomizedRunner.java:568)




 Build Log:
 [...truncated 8159 lines...]
[junit4] Suite:
 org.apache.lucene.spatial.spatial4j.Geo3dShapeRectRelationTest
[junit4]   1 S-R Rel: {}, Shape {}, Rectangle {} [WITHIN,
 Geo3dShape{GeoRectangle: {toplat=-1.5168556919397584(-86.90942927854432),
 bottomlat=-1.5706704561465907(-89.9927881430875),
 leftlon=-0.018526106616054788(-1.0614677199093308),
 rightlon=0.06206550121582512(3.5560912730308587)}},
 Rect(minX=-48.0,maxX=4.0,minY=-90.0,maxY=-74.0)](no slf4j subst; sorry)
[junit4] FAILURE 3.57s J1 | Geo3dShapeRectRelationTest.testGeoBBoxRect
 
[junit4] Throwable #1: java.lang.AssertionError:
 Rect(minX=-48.0,maxX=4.0,minY=-90.0,maxY=-74.0) intersect
 Pt(x=36.3684088252,y=-89.97395823916177)
[junit4]at
 __randomizedtesting.SeedInfo.seed([EE73D5405F7BB152:CAD67D787B48CF0C]:0)
[junit4]at
 org.apache.lucene.spatial.spatial4j.RandomizedShapeTestCase._assertIntersect(RandomizedShapeTestCase.java:168)
[junit4]at

[jira] [Commented] (SOLR-7500) Remove pathPrefix from SolrDispatchFilter as Solr no longer runs as a part of a bigger webapp


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

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

Commit 1678082 from [~anshumg] in branch 'dev/trunk'
[ https://svn.apache.org/r1678082 ]

SOLR-7500: Remove pathPrefix from SolrDispatchFilter as Solr no longer runs as 
a part of a bigger webapp.

 Remove pathPrefix from SolrDispatchFilter as Solr no longer runs as a part of 
 a bigger webapp
 -

 Key: SOLR-7500
 URL: https://issues.apache.org/jira/browse/SOLR-7500
 Project: Solr
  Issue Type: Improvement
Reporter: Anshum Gupta
Assignee: Anshum Gupta
Priority: Minor
 Attachments: SOLR-7500.patch


 SolrDispatchFilter has support for Solr running as part of a bigger webapp 
 but as we've moved away from that concept, it makes sense to clean up the 
 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-6196) Include geo3d package, along with Lucene integration to make it useful

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


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

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

Commit 1678060 from [~dsmiley] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1678060 ]

LUCENE-6196: Fix RandomizedShapeTestCase.randomPointIn(Shape)

 Include geo3d package, along with Lucene integration to make it useful
 --

 Key: LUCENE-6196
 URL: https://issues.apache.org/jira/browse/LUCENE-6196
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/spatial
Reporter: Karl Wright
Assignee: David Smiley
 Fix For: 5.2

 Attachments: LUCENE-6196-additions.patch, LUCENE-6196-fixes.patch, 
 LUCENE-6196_Geo3d.patch, ShapeImpl.java, geo3d-tests.zip, geo3d.zip


 I would like to explore contributing a geo3d package to Lucene.  This can be 
 used in conjunction with Lucene search, both for generating geohashes (via 
 spatial4j) for complex geographic shapes, as well as limiting results 
 resulting from those queries to those results within the exact shape in 
 highly performant ways.
 The package uses 3d planar geometry to do its magic, which basically limits 
 computation necessary to determine membership (once a shape has been 
 initialized, of course) to only multiplications and additions, which makes it 
 feasible to construct a performant BoostSource-based filter for geographic 
 shapes.  The math is somewhat more involved when generating geohashes, but is 
 still more than fast enough to do a good job.



--
This message was sent by Atlassian 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-7484) Refactor SolrDispatchFilter to move all Solr specific implementation to another class

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


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

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

Commit 1678071 from [~anshumg] in branch 'dev/trunk'
[ https://svn.apache.org/r1678071 ]

SOLR-7484: Cleaning up redundant switch cases from the code

 Refactor SolrDispatchFilter to move all Solr specific implementation to 
 another class
 -

 Key: SOLR-7484
 URL: https://issues.apache.org/jira/browse/SOLR-7484
 Project: Solr
  Issue Type: Improvement
Reporter: Anshum Gupta
Assignee: Anshum Gupta
 Fix For: 5.2

 Attachments: SOLR-7484.patch, SOLR-7484.patch, SOLR-7484.patch, 
 SOLR-7484.patch, SOLR-7484.patch, SOLR-7484.patch, SOLR-7484.patch, 
 SOLR-7484.patch, SOLR-7484.patch


 Currently almost everything that's done in SDF.doFilter() is sequential. We 
 should refactor it to clean up the code and make things easier to manage.



--
This message was sent by Atlassian 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 # 2270 - Failure!

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

1 tests failed.
FAILED:  
org.apache.lucene.spatial.spatial4j.Geo3dShapeRectRelationTest.testGeoBBoxRect

Error Message:
Rect(minX=-48.0,maxX=4.0,minY=-90.0,maxY=-74.0) intersect 
Pt(x=36.3684088252,y=-89.97395823916177)

Stack Trace:
java.lang.AssertionError: Rect(minX=-48.0,maxX=4.0,minY=-90.0,maxY=-74.0) 
intersect Pt(x=36.3684088252,y=-89.97395823916177)
at 
__randomizedtesting.SeedInfo.seed([EE73D5405F7BB152:CAD67D787B48CF0C]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.lucene.spatial.spatial4j.RandomizedShapeTestCase._assertIntersect(RandomizedShapeTestCase.java:168)
at 
org.apache.lucene.spatial.spatial4j.RandomizedShapeTestCase.assertRelation(RandomizedShapeTestCase.java:153)
at 
org.apache.lucene.spatial.spatial4j.RectIntersectionTestHelper.testRelateWithRectangle(RectIntersectionTestHelper.java:136)
at 
org.apache.lucene.spatial.spatial4j.Geo3dShapeRectRelationTest.testGeoBBoxRect(Geo3dShapeRectRelationTest.java:166)
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.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
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.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$2.evaluate(ThreadLeakControl.java:401)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:651)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$200(RandomizedRunner.java:138)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$1.run(RandomizedRunner.java:568)




Build Log:
[...truncated 8159 lines...]
   [junit4] Suite: 
org.apache.lucene.spatial.spatial4j.Geo3dShapeRectRelationTest
   [junit4]   1 S-R Rel: {}, Shape {}, Rectangle {} [WITHIN, 
Geo3dShape{GeoRectangle: {toplat=-1.5168556919397584(-86.90942927854432), 
bottomlat=-1.5706704561465907(-89.9927881430875), 
leftlon=-0.018526106616054788(-1.0614677199093308), 
rightlon=0.06206550121582512(3.5560912730308587)}}, 
Rect(minX=-48.0,maxX=4.0,minY=-90.0,maxY=-74.0)](no slf4j subst; sorry)
   [junit4] FAILURE 3.57s J1 | Geo3dShapeRectRelationTest.testGeoBBoxRect 
   [junit4] Throwable #1: java.lang.AssertionError: 
Rect(minX=-48.0,maxX=4.0,minY=-90.0,maxY=-74.0) intersect 
Pt(x=36.3684088252,y=-89.97395823916177)
   [junit4]at 
__randomizedtesting.SeedInfo.seed([EE73D5405F7BB152:CAD67D787B48CF0C]:0)
   [junit4]at 
org.apache.lucene.spatial.spatial4j.RandomizedShapeTestCase._assertIntersect(RandomizedShapeTestCase.java:168)
   [junit4]at 
org.apache.lucene.spatial.spatial4j.RandomizedShapeTestCase.assertRelation(RandomizedShapeTestCase.java:153)
   [junit4]at 
org.apache.lucene.spatial.spatial4j.RectIntersectionTestHelper.testRelateWithRectangle(RectIntersectionTestHelper.java:136)
   [junit4]at 
org.apache.lucene.spatial.spatial4j.Geo3dShapeRectRelationTest.testGeoBBoxRect(Geo3dShapeRectRelationTest.java:166)
   [junit4]   1 Laps: 3608 CWIDbD: 935,6,1621,581,465
   [junit4]   1 Laps: 50181 CWIDbD: 25578,110,12637,3982,7874
   [junit4]   1 Laps: 3750 CWIDbD: 384,6,1398,844,1118
   [junit4] Completed

[jira] [Created] (LUCENE-6468) Empty kuromoji user dictionary - NPE

2015-05-06 Thread Robert Muir (JIRA)

Robert Muir created LUCENE-6468:
---

 Summary: Empty kuromoji user dictionary - NPE
 Key: LUCENE-6468
 URL: https://issues.apache.org/jira/browse/LUCENE-6468
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir


Kuromoji user dictionary takes Reader and allows for comments and other lines 
to be ignored. But if its empty in the sense of no actual entries, the 
returned FST will be null, and it will throw a confusing NPE.

JapaneseTokenizer and JapaneseAnalyzer apis already treat null UserDictionary 
as having none at all, so I think the best fix is to fix the UserDictionary api 
from UserDictionary(Reader) to UserDictionary.open(Reader) or similar, and 
return null if the FST is empty.



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

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

[JENKINS] Lucene-Solr-NightlyTests-5.x - Build # 839 - Still Failing

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/839/

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

Error Message:
shard1 is not consistent.  Got 764 from 
http://127.0.0.1:32491/collection1lastClient and got 201 from 
http://127.0.0.1:32494/collection1

Stack Trace:
java.lang.AssertionError: shard1 is not consistent.  Got 764 from 
http://127.0.0.1:32491/collection1lastClient and got 201 from 
http://127.0.0.1:32494/collection1
at 
__randomizedtesting.SeedInfo.seed([39CE5DED7053ED5D:B19A6237DEAF80A5]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.apache.solr.cloud.RecoveryZkTest.test(RecoveryZkTest.java:123)
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:960)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
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

[jira] [Updated] (LUCENE-6459) [suggest] Query Interface for suggest API

2015-05-06 Thread Areek Zillur (JIRA)


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

Areek Zillur updated LUCENE-6459:
-
Attachment: LUCENE-6459.patch

Updated Patch:
 - added documentation
 - minor cleanup
 - added more tests

 [suggest] Query Interface for suggest API
 -

 Key: LUCENE-6459
 URL: https://issues.apache.org/jira/browse/LUCENE-6459
 Project: Lucene - Core
  Issue Type: New Feature
  Components: core/search
Affects Versions: 5.1
Reporter: Areek Zillur
Assignee: Areek Zillur
 Fix For: Trunk, 5.x, 5.1

 Attachments: LUCENE-6459.patch, LUCENE-6459.patch


 Related Issue: 
 [NRTSuggester|https://issues.apache.org/jira/browse/LUCENE-6339]
 h3. Suggest API:
 {code}
 SuggestIndexSearcher searcher = new SuggestIndexSearcher(reader);
 CompletionQuery query = ...
 TopSuggestDocs suggest = searcher.suggest(query, num);
 {code}
 h3. Query Interface
 h4. PrefixCompletionQuery
 Return documents with values that match the prefix of an analyzed term text 
 Documents are sorted according to their suggest field weight. 
 {code}
 PrefixCompletionQuery(Analyzer analyzer, Term term)
 {code}
 h4. RegexCompletionQuery
 Return documents with values that match the prefix of a regular expression
 Documents are sorted according to their suggest field weight.
 {code}
 RegexCompletionQuery(Term term)
 {code}
 h4. FuzzyCompletionQuery
 Return documents with values that has prefixes within a specified edit 
 distance of an analyzed term text.
 Documents are ‘boosted’ by the number of matching prefix letters of the 
 suggestion with respect to the original term text.
 {code}
 FuzzyCompletionQuery(Analyzer analyzer, Term term)
 {code}
 h5. Scoring
 {{suggestion_weight + (global_maximum_weight * boost)}}
 where {{suggestion_weight}}, {{global_maximum_weight}} and {{boost}} are all 
 integers. 
 {{boost = # of prefix characters matched}}
 h4. ContextQuery
 Return documents that match a {{CompletionQuery}} filtered and/or boosted by 
 provided context(s). 
 {code}
 ContextQuery(CompletionQuery query)
 contextQuery.addContext(CharSequence context, int boost, boolean exact)
 {code}
 *NOTE:* {{ContextQuery}} should be used with {{ContextSuggestField}} to query 
 suggestions boosted and/or filtered by contexts
 h5. Scoring
 {{suggestion_weight + (global_maximum_weight * context_boost)}}
 where {{suggestion_weight}}, {{global_maximum_weight}} and {{context_boost}} 
 are all integers
 When used with {{FuzzyCompletionQuery}},
 {{suggestion_weight + (global_maximum_weight * (context_boost + 
 fuzzy_boost))}}
 h3. Context Suggest Field
 To use {{ContextQuery}}, use {{ContextSuggestField}} instead of 
 {{SuggestField}}. Any {{CompletionQuery}} can be used with 
 {{ContextSuggestField}}, the default behaviour is to return suggestions from 
 *all* contexts. {{Context}} for every completion hit can be accessed through 
 {{SuggestScoreDoc#context}}.
 {code}
 ContextSuggestField(String name, CollectionCharSequence contexts, String 
 value, int weight) 
 {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-7484) Refactor SolrDispatchFilter to move all Solr specific implementation to another class

2015-05-06 Thread Noble Paul (JIRA)


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

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

should you not remove those redundant cases in switch ?

 Refactor SolrDispatchFilter to move all Solr specific implementation to 
 another class
 -

 Key: SOLR-7484
 URL: https://issues.apache.org/jira/browse/SOLR-7484
 Project: Solr
  Issue Type: Improvement
Reporter: Anshum Gupta
Assignee: Anshum Gupta
 Fix For: 5.2

 Attachments: SOLR-7484.patch, SOLR-7484.patch, SOLR-7484.patch, 
 SOLR-7484.patch, SOLR-7484.patch, SOLR-7484.patch, SOLR-7484.patch, 
 SOLR-7484.patch, SOLR-7484.patch


 Currently almost everything that's done in SDF.doFilter() is sequential. We 
 should refactor it to clean up the code and make things easier to manage.



--
This message was sent by Atlassian 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 # 2272 - Failure!

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

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

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.cloud.ZkControllerTest: 
1) Thread[id=1965, 
name=OverseerStateUpdate-93780041537945603-127.0.0.1:8983_solr-n_00, 
state=TIMED_WAITING, group=Overseer state updater.] at 
java.lang.Object.wait(Native Method) at 
org.apache.solr.cloud.DistributedQueue$LatchWatcher.await(DistributedQueue.java:276)
 at 
org.apache.solr.cloud.DistributedQueue.getChildren(DistributedQueue.java:320)   
  at org.apache.solr.cloud.DistributedQueue.peek(DistributedQueue.java:594) 
at 
org.apache.solr.cloud.DistributedQueue.peek(DistributedQueue.java:572) 
at org.apache.solr.cloud.Overseer$ClusterStateUpdater.run(Overseer.java:189)
 at java.lang.Thread.run(Thread.java:745)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.cloud.ZkControllerTest: 
   1) Thread[id=1965, 
name=OverseerStateUpdate-93780041537945603-127.0.0.1:8983_solr-n_00, 
state=TIMED_WAITING, group=Overseer state updater.]
at java.lang.Object.wait(Native Method)
at 
org.apache.solr.cloud.DistributedQueue$LatchWatcher.await(DistributedQueue.java:276)
at 
org.apache.solr.cloud.DistributedQueue.getChildren(DistributedQueue.java:320)
at 
org.apache.solr.cloud.DistributedQueue.peek(DistributedQueue.java:594)
at 
org.apache.solr.cloud.DistributedQueue.peek(DistributedQueue.java:572)
at 
org.apache.solr.cloud.Overseer$ClusterStateUpdater.run(Overseer.java:189)
at java.lang.Thread.run(Thread.java:745)
at __randomizedtesting.SeedInfo.seed([DA1FC76991DE93B1]:0)




Build Log:
[...truncated 9550 lines...]
   [junit4] Suite: org.apache.solr.cloud.ZkControllerTest
   [junit4]   2 Creating dataDir: 
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-core/test/J0/temp/solr.cloud.ZkControllerTest
 DA1FC76991DE93B1-001/init-core-data-001
   [junit4]   2 429350 T1911 oas.SolrTestCaseJ4.buildSSLConfig Randomized ssl 
(false) and clientAuth (false)
   [junit4]   2 429354 T1911 oas.SolrTestCaseJ4.setUp ###Starting 
testEnsureReplicaInLeaderInitiatedRecovery
   [junit4]   2 429355 T1911 oasc.ZkTestServer.run STARTING ZK TEST SERVER
   [junit4]   2 429359 T1912 oasc.ZkTestServer$2$1.setClientPort client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2 429359 T1912 oasc.ZkTestServer$ZKServerMain.runFromConfig 
Starting server
   [junit4]   2 429461 T1911 oasc.ZkTestServer.run start zk server on 
port:57830
   [junit4]   2 429461 T1911 
oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default 
ZkCredentialsProvider
   [junit4]   2 429478 T1911 oascc.ConnectionManager.waitForConnected Waiting 
for client to connect to ZooKeeper
   [junit4]   2 429498 T1919 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@74cef15f 
name:ZooKeeperConnection Watcher:127.0.0.1:57830 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2 429511 T1911 oascc.ConnectionManager.waitForConnected Client 
is connected to ZooKeeper
   [junit4]   2 429512 T1911 oascc.SolrZkClient.createZkACLProvider Using 
default ZkACLProvider
   [junit4]   2 429554 T1911 
oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default 
ZkCredentialsProvider
   [junit4]   2 429556 T1911 oascc.ConnectionManager.waitForConnected Waiting 
for client to connect to ZooKeeper
   [junit4]   2 429563 T1922 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@4991b56c 
name:ZooKeeperConnection Watcher:127.0.0.1:57830 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2 429564 T1911 oascc.ConnectionManager.waitForConnected Client 
is connected to ZooKeeper
   [junit4]   2 429565 T1911 oascc.SolrZkClient.createZkACLProvider Using 
default ZkACLProvider
   [junit4]   2 429565 T1911 oascc.SolrZkClient.makePath makePath: /solr
   [junit4]   2 429629 T1913 oazs.NIOServerCnxn.doIO WARN caught end of stream 
exception EndOfStreamException: Unable to read additional data from client 
sessionid 0x14d2c73503c0001, likely client has closed socket
   [junit4]   2at 
org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:228)
   [junit4]   2at 
org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:208)
   [junit4]   2at java.lang.Thread.run(Thread.java:745)
   [junit4]   2 
   [junit4]   2 429630 T1911 oasc.CoreContainer.init New CoreContainer 
418117706
   [junit4]   2 429637 T1911 n:127.0.0.1:8983_solr 
oascc.ConnectionManager.waitForConnected Waiting for client to connect to 
ZooKeeper
   [junit4]   2 429652 T1925

[jira] [Updated] (SOLR-6968) add hyperloglog in statscomponent as an approximate count

2015-05-06 Thread Hoss Man (JIRA)


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

Hoss Man updated SOLR-6968:
---
Attachment: SOLR-6968.patch

Updated patch now includes a TestDistributedStatsComponentCardinality -- which 
does randomized docs  tunning options with asserts about relative error and 
consistnecy with prehashed values.

i think this is pretty much good to go -- we can open a distinct issue for 
adding an UpdateProcessor to support index time murmur3 hashing.

 add hyperloglog in statscomponent as an approximate count
 -

 Key: SOLR-6968
 URL: https://issues.apache.org/jira/browse/SOLR-6968
 Project: Solr
  Issue Type: Sub-task
Reporter: Hoss Man
 Attachments: SOLR-6968.patch, SOLR-6968.patch, SOLR-6968.patch, 
 SOLR-6968.patch, SOLR-6968.patch, SOLR-6968.patch


 stats component currently supports calcDistinct but it's terribly 
 inefficient -- especially in distib mode.
 we should add support for using hyperloglog to compute an approximate count 
 of distinct values (using localparams via SOLR-6349 to control the precision 
 of the approximation)



--
This message was sent by Atlassian 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 (32bit/jdk1.8.0_45) - Build # 4657 - Failure!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4657/
Java: 32bit/jdk1.8.0_45 -server -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.embedded.LargeVolumeJettyTest

Error Message:
Some resources were not closed, shutdown, or released.

Stack Trace:
java.lang.AssertionError: Some resources were not closed, shutdown, or released.
at __randomizedtesting.SeedInfo.seed([5AEA969D5ED84A9C]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:234)
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$5.evaluate(RandomizedRunner.java:799)
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 java.lang.Thread.run(Thread.java:745)


FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.embedded.LargeVolumeJettyTest

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-solrj\test\J1\temp\solr.client.solrj.embedded.LargeVolumeJettyTest
 
5AEA969D5ED84A9C-001\tempDir-001\collection1\data\tlog\tlog.002:
 java.nio.file.FileSystemException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-solrj\test\J1\temp\solr.client.solrj.embedded.LargeVolumeJettyTest
 
5AEA969D5ED84A9C-001\tempDir-001\collection1\data\tlog\tlog.002:
 The process cannot access the file because it is being used by another 
process. 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-solrj\test\J1\temp\solr.client.solrj.embedded.LargeVolumeJettyTest
 5AEA969D5ED84A9C-001\tempDir-001\collection1\data\tlog: 
java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-solrj\test\J1\temp\solr.client.solrj.embedded.LargeVolumeJettyTest
 5AEA969D5ED84A9C-001\tempDir-001\collection1\data\tlog
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-solrj\test\J1\temp\solr.client.solrj.embedded.LargeVolumeJettyTest
 5AEA969D5ED84A9C-001\tempDir-001\collection1\data: 
java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-solrj\test\J1\temp\solr.client.solrj.embedded.LargeVolumeJettyTest
 5AEA969D5ED84A9C-001\tempDir-001\collection1\data
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-solrj\test\J1\temp\solr.client.solrj.embedded.LargeVolumeJettyTest
 5AEA969D5ED84A9C-001\tempDir-001\collection1: 
java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-solrj\test\J1\temp\solr.client.solrj.embedded.LargeVolumeJettyTest

[jira] [Updated] (SOLR-4392) DIH - Need to externalize or encrypt username/password stored within data-config.xml

2015-05-06 Thread Noble Paul (JIRA)


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

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

Use aes-128 to encrypt password

 DIH - Need to externalize or encrypt username/password stored within 
 data-config.xml
 

 Key: SOLR-4392
 URL: https://issues.apache.org/jira/browse/SOLR-4392
 Project: Solr
  Issue Type: New Feature
  Components: contrib - DataImportHandler
Affects Versions: 4.0, 4.1
Reporter: Senthuran Sivananthan
 Attachments: SOLR-4392.patch, SOLR-4392.patch


 Today, the connection (database or otherwise) credentials is wide open in 
 data-config.xml.  Not really an issue until someone sends out the config file 
 outside of the server.
 We should look into externalizing the database lookup or providing a way to 
 encrypt the username and password.
 The needs are:
 1/  Some projects want to enable multi-tenancy where data for each core is 
 situated in different database servers w/ their own credentials.  We need a 
 way to expose hooks that will allow implementations to be plugged in.  It can 
 be done though the type attribute on the dataSource, but providing a 
 factory might work better.
 2/  Most orgs are very protective of their credentials and weary of 
 plain-text settings.



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

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

[jira] [Closed] (LUCENE-5766) bug in rewrite function of boolean query


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

Adrien Grand closed LUCENE-5766.

Resolution: Cannot Reproduce

I don't understand why not cloning is an issue and I could not reproduce the 
issue:

{code}
  private static BooleanQuery should(Query q) {
BooleanQuery bq = new BooleanQuery();
bq.add(q, Occur.SHOULD);
return bq;
  }
  
  public static void main(String[] args) throws Exception {
try (Directory dir = new RAMDirectory();
 IndexWriter w = new IndexWriter(dir, new IndexWriterConfig(new 
WhitespaceAnalyzer( {
  Document doc = new Document();
  doc.add(new TextField(title, at, Store.NO));
  w.addDocument(doc);
  w.commit();
  try (DirectoryReader reader = DirectoryReader.open(dir)) {
FuzzyQuery fuzzyQuery = new FuzzyQuery(new Term(title, at), 1);
Query query = fuzzyQuery;
query = should(query);
query.setBoost(2);
query = should(query);
query = should(query);
query.setBoost(4.5f);
System.out.println(query);
Query rewritten = query.rewrite(reader);
System.out.println(rewritten);
  }
}
  }
{code}

which prints

{code}
title:at~1)^2.0)))^4.5
(title:at)^9.0
{code}

Closing it for now, please reopen if you can still reproduce and share what 
query parser you are using.

 bug in rewrite function of boolean query
 

 Key: LUCENE-5766
 URL: https://issues.apache.org/jira/browse/LUCENE-5766
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Wang Han

 when optimize boolean query. When the only query sub clause has a boost with 
 1.0, it should be cloned too. 
 if (minNrShouldMatch == 0  clauses.size() == 1) {// 
 optimize 1-clause queries
   BooleanClause c = clauses.get(0);
   if (!c.isProhibited()) {  // just return clause
 Query query = c.getQuery().rewrite(reader);// rewrite first
 if (getBoost() != 1.0f) { // incorporate boost
   if (query == c.getQuery()) {   // if rewrite was 
 no-op
 query = query.clone(); // then clone before boost
   }
   // Since the BooleanQuery only has 1 clause, the BooleanQuery will 
 be
   // written out. Therefore the rewritten Query's boost must 
 incorporate both
   // the clause's boost, and the boost of the BooleanQuery itself
   query.setBoost(getBoost() * query.getBoost());
 }
 return query;
   }
 }
 when boolean query nested in a disjunction query, rewrite function return the 
 original term query without clone and may cause bad boost value in upper 
 queries. Delete the if statement and always do
  if (query == c.getQuery()) {   // if rewrite was no-op
 query = query.clone(); // then clone before boost
   }
 can fix this bug.
 sample query may cause this bug: ((+((title:at)~1^2.0)))^4.5   after rewrite 
 the query will be changed to  ((+((title:at)~1^9.0)))^4.5 and Query.clone() 
 won't work for this problem because your lazy clone strategy.



--
This message was sent by Atlassian 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-Windows (32bit/jdk1.8.0_45) - Build # 4776 - Failure!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4776/
Java: 32bit/jdk1.8.0_45 -server -XX:+UseParallelGC

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

Error Message:
ERROR: SolrIndexSearcher opens=51 closes=50

Stack Trace:
java.lang.AssertionError: ERROR: SolrIndexSearcher opens=51 closes=50
at __randomizedtesting.SeedInfo.seed([5F98718ED18ACCF9]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:496)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:232)
at sun.reflect.GeneratedMethodAccessor39.invoke(Unknown Source)
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$5.evaluate(RandomizedRunner.java:799)
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 java.lang.Thread.run(Thread.java:745)


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

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

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


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

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=8153,

[jira] [Issue Comment Deleted] (SOLR-7341) xjoin - join data from external sources